Re: User-level Authentication Mechanisms for IPsec

[Roy Pereira <royp@xxxxxxxxx>]

Scott,

>                          <-- REQUEST(TYPE=GENERIC NAME=""
>                                      PASSWORD="")
>      REPLY(TYPE=GENERIC NAME="joe"
>                PASSWORD="foobar") -->
>                          <-- REQUEST(TYPE=GENERIC
>                                      MESSAGE="Enter your password
>                                      followed by your pin number"
>                                      NAME="" PASSWORD="")
> Look at all the ASCII TEXT here. As you know, this is all included in
> the exchange, and in a very predictable location within the packet.

XAUTH, nor IKECFG stipulates the order of attributes, nor the specific
contents of them.  The message text can be anything and even empty. 
Thus I don't think that known plaintext is an issue.  The REQUEST/REPLY
IDs do have to be there, but that is only one byte.

> ISACFG may not seem very complicated yet, but take a look at dhcp, ppp,
> pptp, l2tp. Provisioning of remote clients is not simple. I have argued
> for some time that isacfg and xauth should separated, since they each
> raise a very different set of concerns. The draft simply points out that
> as it currently stands, isacfg and xauth are a package, further
> complicating the task of analyzing the security implications of
> implementing them.

IKECFG doesn't try and replace DHCP or any other configuration
protocol.  It is required to mainly bootstrap the VPN client with
essential information.  The draft states this.  The type of information
being exchanged is crucial to the client before a phase 2 SA is set up,
and thus this is why IKECFG is at phase 1.5.

IKECFG and XAUTH are not joined at the hip.  XAUTH does use the same
mechanisms that IKECFG uses, but this just makes it easier to
implement.  You don't have to use IKECFG is you only need XAUTH.  Please
remember that these protocols have been published for well over a year
now and have gone through many revisions because of discussion on the
mailing lists.  Having XAUTH use the existing mechanisms in IKECFG was
deamed better than building yet another protocol.  IKE provides a great
base that is secure and flexible enough to support extensions. 

> The draft doesn't say they are necessarily complicated to implement,
> though isacfg will certainly become more complex as people come to
> understand the requirments of remote access client configuration.

Again, this draft has been around for a long time and has been discussed
by people who have been interested in IPSec remote acccess.  Just
because the core IPSec specification is now done and everyone now has
more time to look at other requirements doesn't mean that some people
havent been looking at this for awhile now.  There are many released
products that use these protocols and I haven't heard of any limitations
within them that prevented the products from solving the customer's
problems.

> Rather, it says they add unecessary complexity to the key exchange.

I know of more than half-a-dozen vendors who have implemented either
XAUTH and/or IKECFG and complexity wasn't mentioned.  Besides, they
actually don't add complexity to the "Key exchange".  In fact they were
designed to not touch the "key exchange".  They are a separate exchange,
thus the main/aggressive modes that we all use are not touched. (Except
Hybrid-XAUTH that does alter the phase 1 mode)

When I speak to customers they want these protocols.  Some want to use
only their SecurID cards and no certificates, while others want to use
mutual certification authentication plus SecurID cards.  We must be able
to solve their problems.


But let me state again, that the actual protocol isn't the important
piece here and I'm happy to see a lot of people understanding the
requirements that we are here to solve.  Our protocol(s) must be secure,
but they also have to allow the marketplace to do what they want and
like a few people have stated those requirements can range from no
certificates with legacy authentication to mutual certificates with
legacy authentication.  Our goal is to find something that solves that
problem.