RE: IKEv2: active user identity protection

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

Tero,

you can say that it is too late for changes, or that the 
discussions in Feb/March (and even before) on this issue (roughly)
showed that not enough people cared about the subject's issue,
but please do not represent this as anything that was rejected on clear
technical grounds or because ikev1 did not do it right, or because
post-ikev2 solutions will work as fine.

The (candidate) solutions in the setting of ikev2 are simple, they do not
add (contrary to what you say below) any new mode of authentication (they
slightly modify the EAP mode whichby itself is new and not implemented).

I agree that a "pseudonym" solution as you suggest is better than nothing
given the fact that ikev2 did not include this privacy defense. But it 
adds much more complexity than any of the solutions that we could
accomdate in ikev2, and achieves significantly less; for example it 
ties your login to a single machine, something I doubt it is the desire 
of most organizations. I can certainly see much stronger arguments against
the psedonym approach than arguments in favor of avoiding polling attacks
on remote-access servers...

But until someone appeals to a higher instance (God?) to the decision-making 
process in ikev2's last call I see this issue as closed.

Hugo


On Sat, 28 Jun 2003, Tero Kivinen wrote:

> jknowles@SonicWALL.com writes:
> > I also support Hugo's suggested changes to provide this
> > protection.  I think many end-user scenarios demand it.
> > Aggressive mode failed to protect identities and is
> > criticized for this (I heard today this exact criticism
> > from a customer).  We still have a chance to fix this
> > without unnecessary delay.
> 
> The IKEv2 will protect the identities for passive attacks. In the
> IKEv1 aggressive mode there was no protection for the passive attacks
> at all (execpt in RSA encryption mode, and there you also needed to
> send the certificate to be used, so actually you always gave out your
> identity...). Also note, that IKEv1 DID NOT protect initiators
> identity in the main mode from the active attacks when using
> signatures either. Also the preshared keys in main mode didn't offer
> any real protection of the identity, because the responder needed to
> know before decrypting the packet which key to use (i.e it needed to
> know the who the other end based on the IP address).
> 
> To make it simple list:
> 
>    1) Current draft do protect identities from the passive attacks
>       always.
> 
>    2) For the active attacks there is no way to protect both ends for
>       the identity (either one of them must first proof who they are).
>       (Ok, you could use one time identities stuff exchange inside the
>       encrypted exchange, and you actually can already use them in the
>       EAP cases without any changes to the protocol if you want to). 
> 
>    3) The question is who proofs the identity first, in the IKEv1 it
>       was always the initiator, for IKEv2 it is always the initiator
>       (i.e no change here).
> 
>    4) Hugos proposal was to add new mode that would change the
>       protocol so that the responder would proof its identity first in
>       case of EAP is used, this opens attack called polling attack,
>       which allows active attacker to get proof who everybody is in
>       the internet if the other end is willing to talk EAP.
> 
>    5) The current draft protects the identities better in real cases
>       than IKEv1 (in the IKEv1 in RSA encryption mode and in the
>       preshared keys active attacker couldn't go spoof the other end,
>       but on the other hand the real responder couldn't either go
>       forward before it know who the other end already was (i.e from
>       the IP address or if there was only one client). If the real
>       responder needed to know this based on the IP then the attacker
>       would learn that also quite quickly).
> 
> So, I suggest that those who really have requirement that the
> initiators identity must be protected against active attack use one
> time identities (ID_KEY_ID), i.e the server have list of identities
> for each client, and every time the client connects the client uses
> the next one on the list. I.e the client never uses same identity,
> thus giving the identity protection on the initiator even for active
> attacks.
> -- 
> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>