Re: Secure legacy authentication for IKEv2

[Derrell Piper <ddp@electric-loft.org>]

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