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

RE: IKEv2: active user identity protection

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

   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
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/