[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Secure legacy authentication for IKEv2



Derrell, we can't assume IKEv2 is just for VPN purposes, or has the
protections you describe.  It should solve generalized end-to-end IP
scenarios, e.g. protect end-to-end TCP and UDP, across a hostile
network.

Re: CHRE vs. EAP: I see no need to re-invent individual auth methods
when an existing IETF RFC framework exists for authentication in EAP,
which is a better (more flexible) solution in the long-term, and one
that leverages established code bases for implementers (EAP for PPP,
802.1x, PIC, EAP-TLS, etc), as well as one that plugs into existing
customer infrastructures.

-----Original Message-----
From: Derrell Piper [mailto:ddp@electric-loft.org] 
Sent: Saturday, December 21, 2002 8:18 AM
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