Re: Secure legacy authentication for IKEv2

[Derrell Piper <ddp@electric-loft.org>]

William,

I view using EAP within IKEv2's legacy authentication as problematic 
for several reasons, here's why...

First, an initial proposal for SLA did try to use EAP but it was 
pointed out that doing so opened up the protocol to a so-called 
authentication binding attack.  Fixing this is certainly possible, by 
mixing the keying derivations of EAP with IKEv2, but the cost is 
additional complexity and a somewhat gross laying violation.

Second, I think there's value to having legacy authentication be 
self-contained in the IKEv2 specification and not require IKEv2 
implementations to also have to take on EAP.  This adds a rather gnarly 
dependency with respect to security assurance.  Any multi-headed 
authentication protocol is clearly more complex than a self-contained 
protocol.  Given that the overriding goal for IKEv2 was eliminating 
complexity and ensuring interoperability, adding EAP to IKE solely for 
legacy authentication doesn't seem like a step in the right direction.

Regarding extensibility claims, SLA is intended to secure existing 
legacy authentication.  Arguments about future extensibility that you 
might get if you used EAP don't do much for me.  Many of the proposed 
EAP authentication extensions in fact have no relevance to legacy 
authentication for VPN's.  I don't anticipate having to add to the 
defined LAM types.  The four defined types have been fleshed out over 
several years of real world VPN demand.

A third reason is that EAP (as I understand it) does not allow for the 
client (initiator) to send either a username/password or 
username/pin-code combo in message three.  Instead, EAP requires that 
only the username be sent in message three.  This adds an extra message 
for what many of us consider the common case: where the LAM type is 
password or SecurID.  The SLA protocol instead allows the client to 
send them together.

Regards,

Derrell

On Friday, December 20, 2002, at 01:52 PM, William Dixon wrote:

> Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC
> ?  It seems you are re-inventing EAP types here.  For every new or
> different auth method type, you'd have to define a new one in the IKEv2
> spec.
>
> -----Original Message-----
> From: Valery Smyslov [mailto:svan@trustworks.com]
> Sent: Friday, December 20, 2002 10:03 AM
> To: ipsec@lists.tislabs.com; Paul Hoffman / VPNC
> Subject: Re: Secure legacy authentication for IKEv2
>
>
> ----- Original Message -----
> From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
> To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
> Sent: Friday, December 20, 2002 7:39 PM
> Subject: Re: Secure legacy authentication for IKEv2
>
>
>> At 3:06 PM +0300 12/20/02, Valery Smyslov wrote:
>>> draft suggests that no negotiation of LAM type is possible between
>>> client and server: server can just accept or reject LAM type that
>>> client proposed, and he
> has
>>> no means
>>> to indicate to client which LAM type he is willing to do. This can
>>> lead
> to
>>> situation,
>>> when client will have to perform up to 4 connection attempts with
> different
>>> LAM types.
>>> Not only will it delay the connection setup, but also it will put an
>>> unnecessary load to server - for each attempt he will have to do both
>
>>> DH and RSA/DSA.
>>
>> Er, do you really think that the client and server haven't agreed out
>> of band which legacy auth mechanism they will do? In the real world,
>> companies tell their users which auth mechanism they will use, and the
>
>> information needed to do it.
>
> I've been thinking of situation when company upgrades its legathy auth
> from one type to another (i.e. from passwords to SecurID). This will 
> not
> happen overnight, so a transition period will take place. During such
> period both types will be in use.
>
>>> I think better way to handle this situation is to allow server to
>>> change
> LAM
>>> type
>>> if he doesn't like what client proposed.
>>
>> This adds a lot of complexity for a usage model that no one seems to
>> have. Am I wrong here? Do any of the VPN makers out there have
>> customers who want to do legacy auth negotiation?
>
> It will add some complexity to the protocol, but it will reduce client
> configuration complexity. Currently, both XAUTH and Hybrid are designed
> so, that client plays a passive role in legacy auth process (with an
> exception that she must indicate to server that she can and will do
> legacy auth). It is server who decides what type of legacy auth will
> take place and what attributes are needed. Client just displays
> corresponding prompts to user and sends back reply to server. This 
> allow
> client to be configurationless with this regard. In your proposal 
> client
> plays more active role in the process. Therefore, either client needs 
> to
> be preconfigured, or should use "try-and-catch" technique. The first
> alternative adds configuration complexity (espeshially during 
> transition
> period), the second delays connection setup and puts an extra load to
> server. Anyway, I'm not very happy with both.
>
>> --Paul Hoffman, Director
>> --VPN Consortium
>
> Regards,
> Valery Smyslov.
>