Re: Secure legacy authentication for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

> 
> 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 undertsanding of these
attacks, their independence from EAP, and applicabilty to SLA (in
particular, the fact that SLA requires server authentication does not
help against the attacks).

Hugo

> 
> So please say more...
> 
> Derrell
> 
> On Friday, December 20, 2002, at 03:48 PM, Bernard Aboba wrote:
> 
> > Isn't the current version of SLA vulnerable to the same attack? I 
> > don't see anywhere in the spec where a "binding" is carried out. In 
> > fact, this would not be possible with the methods you're supporting, 
> > because none of them generate keys.
> 
>