Re: Secure legacy authentication for IKEv2
Derrell Piper <ddp@electric-loft.org> Fri, 20 December 2002 22:36 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKMa8o13313; Fri, 20 Dec 2002 14:36:08 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09185 Fri, 20 Dec 2002 17:07:05 -0500 (EST)
Date: Fri, 20 Dec 2002 15:09:33 -0700
Subject: Re: Secure legacy authentication for IKEv2
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v548)
Cc: Valery Smyslov <svan@trustworks.com>, ipsec@lists.tislabs.com, Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, Bernard Aboba <bernarda@windows.microsoft.com>
To: William Dixon <wdixon@windows.microsoft.com>
From: Derrell Piper <ddp@electric-loft.org>
In-Reply-To: <C9588551DE135A41AA2626CB6453093738EEFA@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Message-Id: <B819EE18-1467-11D7-9081-000393CDFD1A@electric-loft.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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. >
- Secure legacy authentication for IKEv2 Paul Hoffman / VPNC
- Re: Secure legacy authentication for IKEv2 David Jablon
- Re: Secure legacy authentication for IKEv2 Valery Smyslov
- Re: Secure legacy authentication for IKEv2 Paul Hoffman / VPNC
- Re: Secure legacy authentication for IKEv2 Valery Smyslov
- RE: Secure legacy authentication for IKEv2 William Dixon
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- RE: Secure legacy authentication for IKEv2 Paul Hoffman / VPNC
- Re: Secure legacy authentication for IKEv2 Stephen Kent
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- RE: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Steve Dispensa
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- RE: Secure legacy authentication for IKEv2 Yaron Sheffer
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- RE: Secure legacy authentication for IKEv2 William Dixon
- RE: Secure legacy authentication for IKEv2 Bernard Aboba
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 David Jablon
- Re: Secure legacy authentication for IKEv2 Paul Hoffman / VPNC
- Re: Secure legacy authentication for IKEv2 Stephen Kent
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 David Jablon
- Re: Secure legacy authentication for IKEv2 Dan Harkins
- Re: Secure legacy authentication for IKEv2 David Jablon
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Dan Harkins
- Re: Secure legacy authentication for IKEv2 Andrew Krywaniuk
- Re: Secure legacy authentication for IKEv2 Dan Harkins
- Re: Secure legacy authentication for IKEv2 Michael Richardson
- Re: Secure legacy authentication for IKEv2 Charlie_Kaufman
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 Charlie_Kaufman
- Re: Secure legacy authentication for IKEv2 Stephen Kent
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Hugo Krawczyk
- Re: Secure legacy authentication for IKEv2 Michael Richardson
- Re: Secure legacy authentication for IKEv2 Andrew Krywaniuk
- Re: Secure legacy authentication for IKEv2 Charlie_Kaufman
- Re: Secure legacy authentication for IKEv2 Derrell Piper
- Re: Secure legacy authentication for IKEv2 Uri Blumenthal
- Re: Secure legacy authentication for IKEv2 Derek Atkins