Re: Secure legacy authentication for IKEv2
"Valery Smyslov" <svan@trustworks.com> Fri, 20 December 2002 12:31 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 gBKCV0o04147; Fri, 20 Dec 2002 04:31:00 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03140 Fri, 20 Dec 2002 07:04:48 -0500 (EST)
Message-ID: <0a5a01c2a820$416abfd0$640572d4@trustworks.com>
From: Valery Smyslov <svan@trustworks.com>
To: ipsec@lists.tislabs.com, Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
References: <p05200f4cba27b273c3d4@[165.227.249.18]>
Subject: Re: Secure legacy authentication for IKEv2
Date: Fri, 20 Dec 2002 15:06:40 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message ----- From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org> To: <ipsec@lists.tislabs.com> Sent: Thursday, December 19, 2002 8:30 PM Subject: Secure legacy authentication for IKEv2 > Greetings again. The following draft comes out of the meeting we had > after the IPsec WG meeting in Atlanta. It represents the thinking of > many folks about the cleanest way to do legacy authentication in > IKEv2. Please read it and comment here on the list. > > <http://www.ietf.org/internet-drafts/draft-hoffman-sla-00.txt> Hi, 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. 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 will provide an indication to client that legacy authentication process must be restarted according to new LAM type. For example: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, AUTH Client doesn't know yet what LAM type server will accept. So, she tries the first one she supports, for example - PASSWORD. HDR*, CHRE(LAM Type = SLA_PASSWORD), SAi2, TSi, TSr --> At this point server decides, that this particular user must be authenticated with OTP instead of PASSWORD. So, he changes LAM type to SLA_OTP and sends it back to client. <-- HDR*, CHRE(LAM Type = SLA_OTP) Client restarts authentication process with OTP. HDR*, CHRE(LAM Type = SLA_OTP) --> and an excahnge continues as described in the draft. As a side affect, it will also allow server to perform successive user authentication by multiple LAM (not sure if it is really useful). 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