RE: Secure legacy authentication for IKEv2
"Yaron Sheffer" <yaronf@gmx.net> Sat, 21 December 2002 18:19 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 gBLIJvo05223; Sat, 21 Dec 2002 10:19:57 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20948 Sat, 21 Dec 2002 12:55:58 -0500 (EST)
From: Yaron Sheffer <yaronf@gmx.net>
To: Derrell Piper <ddp@electric-loft.org>, Hugo Krawczyk <hugo@ee.technion.ac.il>
Cc: Bernard Aboba <bernarda@windows.microsoft.com>, William Dixon <wdixon@windows.microsoft.com>, Valery Smyslov <svan@trustworks.com>, ipsec@lists.tislabs.com, Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: Secure legacy authentication for IKEv2
Date: Sat, 21 Dec 2002 19:56:01 +0200
Message-ID: <KEEJJAMGJBNOAGEANEIJOEJGCDAA.yaronf@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <C080C6C5-14FF-11D7-9FFC-000393CDFD1A@electric-loft.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Derrell, the original reason why EAP was implicated in this attack in the context of PIC is that people are using EAP to authenticate to wireless-LAN hot spots (access points) outside the corporate boundary, e.g. in airports. And people are using the same password there as they do inside the corporate boundary, even though everybody tells them not to. Also, I'd like to request that you reconsider using EAP for SLA. EAP is probably already more widely deployed than XAUTH, and I don't think this is about to change. And it's a very lightweight protocol, too. Regards, Yaron -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper Sent: Saturday, December 21, 2002 6:18 PM To: Hugo Krawczyk Cc: Bernard Aboba; William Dixon; Valery Smyslov; ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 On Friday, December 20, 2002, at 05:42 PM, Hugo Krawczyk wrote: >> For the binding attack (as I understand it) to be viable, an active >> attacker would have to bring up the SLA IKE tunnel through message two >> and then somehow induce someone to speak one of the legacy >> authentication methods to it. But for that to happen, the attacker >> would have to complete the first two messages with the intended victim >> and in doing so, the client would learn that the attacker wasn't >> trusted. (We were not concerned with trusted gateways impersonating >> each other.) > > 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) > > (b) impersonates the client to the server in the protected run (SLA, > PIC, etc) using the responses that it gets from the client in the > impersonated unprotected run (a). > > But again see the mentioned documents for a full understanding of these > attacks, their independence from EAP, and applicability to SLA (in > particular, the fact that SLA requires server authentication does not > help against the attacks). > > Hugo Hugo, Thanks for the pointer to the NRC paper. Between it and <http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding- 01.txt> I now have a good understanding of the particular MitM attack we're discussing. Further I now see that the distinction between using EAP vs. SLA (with its CHRE) is irrelevant with respect to this. We agree that this attack requires that: 1) the authentication protocol that's run in the tunnel also be run outside of the tunnel (i.e. unprotected) 2) an attacker is somehow able to lure clients into running the unprotected legacy authentication against him For SLA, we assumed that the legacy authentication methods that we're talking about tunneling are in use only back on the corporate network, not across the Internet. We assumed that the corporate network is appropriately isolated (behind a firewall) from the Internet and blocks nearly everything. It's our belief that that's the usual configuration for deployed IPSec VPN gateways today, which are increasingly hosted on (or built into) the firewall itself. Given these assumptions, clients aren't running the legacy authentication protocols anywhere outside of SLA because there's nothing to talk to (it's all blocked at the firewall). Perhaps the salient point is that these assumptions and their implications on the security of the protocol do need to be clearly stated. I'm guessing you might agree with this because in another later email you wrote: "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)." If we're on the same page, then it seems to me what's interesting to talk about as a group is whether or not these assumptions are realistic for our to-be-deployed IPSec remote client protocol. If we are indeed worried that the legacy authentication methods are today in use across the Internet then we've got more work to do. Derrell
- 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