[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Secure legacy authentication for IKEv2

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@xxxxxxxxxxxxxx]
Sent: Friday, December 20, 2002 10:03 AM
To: ipsec@xxxxxxxxxxxxxxxxx; Paul Hoffman / VPNC
Subject: Re: Secure legacy authentication for IKEv2


----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@xxxxxxxx>
To: "Valery Smyslov" <svan@xxxxxxxxxxxxxx>; <ipsec@xxxxxxxxxxxxxxxxx>
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.