RE: Secure legacy authentication for IKEv2
Hugo Krawczyk <hugo@ee.technion.ac.il> Sat, 21 December 2002 00:57 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 gBL0vLo21125; Fri, 20 Dec 2002 16:57:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10781 Fri, 20 Dec 2002 19:29:20 -0500 (EST)
Date: Sat, 21 Dec 2002 02:30:48 +0200
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
cc: ipsec@lists.tislabs.com
Subject: RE: Secure legacy authentication for IKEv2
In-Reply-To: <p05200f06ba29464c91d1@[165.227.249.18]>
Message-ID: <Pine.GSO.4.21.0212210132510.3270-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul, What you wrote below regarding the man-in-the-middle attacks is incorrect. SLA with the use of "proprietary" payloads is susceptible to these attacks exactly as if it used EAP payloads. It is actually the other way around: these attacks may be a good reason to use EAP. See more specific coments below. On Fri, 20 Dec 2002, Paul Hoffman / VPNC wrote: > At 12:52 PM -0800 12/20/02, 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. > > If we used EAP, we would be susceptible to the man-in-the-middle > attack described at > <http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt>. These attacks have nothing to do with EAP but with a mixed use of SAME authentication credentials in unprotected and tunnel-protected runs (such as the IKE-based tunnel that SLA would provide). I am not going to explain the attacks here but I want to point out that they are NOT due to EAP encapsulation. In particular, the CHRE encapsulation in SLA would be susceptible to the SAME attacks. In these attacks the attacker uses the unprotected run of the authentication to obtain from the user responses to server-generated challenges. Once the attacker obtains these responses from the legitimate user it can go on and encapsulate these responses in CHRE payloads and complete his man-in-the-middle atack against SLA. For those interested in this type of attacks see the above mentioned draft and also the paper "Man-in-the-Middle in Tunnelled Authentication Protocols" by N. Asokan and Valtteri Niemi and Kaisa Nyberg http://eprint.iacr.org/2002/163/ > The "EAP and EAP-like problem" is being discussed in many places, and > is one of the things that is holding up PIC as well. If that is a reason to hold up PIC then for the same reason you'll have to hold up SLA. I suggest not to hold up any of these protocols on the basis of these attacks (rather have clear language regarding the reasons for these attacks and the essentially-limited scope of possible solutions). It is up to the "legacy authentication" community to come up with solutions to these problems (which arise from the essentially-insecure use of credentials in mixed protected/unprotected environments). Moreover, if you support EAP exchanges and the EAP community comes up with measures to alleviate these attacks in the context of EAP then you get the benefits of this solution automatically. If you do CHRE then you don't. That's a good reason to support EAP in SLA. And it is not the only benefit: There is a lot of deployment of EAP and the definition of authentication mechanisms over EAP can be (and is) done independently of IKE. In my view, it is better to leave these definitions in the hands of people (such as the EAP WG) that specifically care about transport of client authentication. If you rely on EAP then all you have to care about is to build a sound tunneling mechanism for EAP in the context of IKEv2 (rather than bulding profiles that depend on the specifics of secure-id, radius, etc.) And, as said, the EAP guys are better suited to take care of problems in the "legacy authentication" world such as the above "man in the middle attacks" against tunneled authentication that have been a concern lately in this community. And adopting EAP into SLA is easy, just copy PIC. > > Dan and Derrell decided that the danger of mis-use of EAP was more > worrisome than the need for automatic extensibility. Note that SLA > already covers all of the methods that are covered by XAUTH, and > there haven't been any calls in a quite a while for new XAUTH methods. SInce this decision is justified on the basis of a wrong assumption (i.e. that the mitm atacks work against EAP and not SLA) then this whole conclusion needs to be revised as suggested above. Hugo > > --Paul Hoffman, Director > --VPN Consortium >
- 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