Re: Secure legacy authentication for IKEv2
Dan Harkins <dharkins@tibernian.com> Sun, 29 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 gBTMalo19346; Sun, 29 Dec 2002 14:36:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27123 Sun, 29 Dec 2002 16:55:35 -0500 (EST)
Message-Id: <200212292156.gBTLuj0d000415@fatty.lounge.org>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: Re: Secure legacy authentication for IKEv2
In-Reply-To: Your message of "Sat, 21 Dec 2002 02:30:48 +0200." <Pine.GSO.4.21.0212210132510.3270-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <380.1041198800.1@tibernian.com>
Date: Sun, 29 Dec 2002 13:56:45 -0800
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hugo, The problem with using EAP (that SLA doesn't have) is that EAP all by itself is a perfectly legitimate way to do good, strong, mutual authentication and therefore it is easy to launch the authentication binding attack by inducing the client to speak that EAP method all by itself. Quite a few EAP methods-- EAP-SIM for instance-- provide mutual authentication (and key generation) and speaking EAP-SIM by itself is a perfectly legitimate thing to do. SIM cards are used in mobile phones and in wireless NIC cards today. They'll be used in more things tomorrow. The more they're used the more willing a client will be to speak EAP-SIM all by itself, and therefore the easier it will be for an attacker to tunnel it to a server who is only willing to speak a tunneled version of EAP-SIM. Ditto for EAP-TLS. (And yes, there are implementations today that do EAP-TLS-encapsulated EAP-TLS). But how could someone be induced into encapsulating its legacay authentication protocol in some format that is specific for SLA and thereby enable the authentication binding attack on it? It is not a legitimate authentication encapsulation all by itself. The authentication binding attack is possible on SLA only if the client is doing something that she should not be doing in the first place-- like providing her credentials to anyone who asks. It's possible for anything to be attacked if the client is doing something insecure! A password of "password", a PIN for a token card written on a the token card itself. In another email you wrote that in these attacks the attacker: "(a) impersonates the server to the client in the unprotected run (we are talking of legacy authentication methods that do NOT authenticate the server so this impersonation is possible)" Yes, it's possible. It's possible to write the PIN on the token card and leave it lying around and thereby leave one open to "attack". But we can't protect against things that are predicated on the client doing a patently insecure thing in the first place. It's possible to steal the contents of a locked car if the windows are down. Is that an "attack" against the lock, or does that, by itself, mean the lock is somehow ineffective? No, it means the owner did something stupid to eliminate the security afforded by other mechanisms. Dan. On Sat, 21 Dec 2002 02:30:48 +0200 you wrote > 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 t >o > 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. tha >t > the mitm atacks work against EAP and not SLA) then this whole conclusion need >s > 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