RE: Secure legacy authentication for IKEv2

["Yaron Sheffer" <yaronf@gmx.net>]

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