Subject: RE: IKEv2: active user identity protection

From: [email-masked]
Date: Fri, 27 Jun 2003 14:53:05 -0700

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.

Regards,

Jim

> -----Original Message-----
> From: Knospe, Heiko [mailto:[email-masked]]
> Sent: Friday, June 27, 2003 7:25 AM
> To: [email-masked]
> Subject: IKEv2: active user identity protection 
> 
> 
> Dear all,
> 
> I would also strongly support active user identity 
> confidentiality protection for the initiator within IKEv2. 
> The issue was recently raised by several people. We analysed 
> the topic in the SHAMAN project and considered it a 
> significant security requirement. It seems particularly 
> important for wireless connections where attacks can easily 
> be launched.
> 
> Best wishes,
> Heiko Knospe
> 
> T-Systems
> ITC Security
> Am Kavalleriesand 3
> D 64295 Darmstadt
> Germany
> 
> Tel. ++49 6151 832033 
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 28 Jun 2003 10:43:27 +0300

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Jun 2003 15:13:57 +0300

Jesse Alpert writes:
> 2. The polling attack mentioned below is of little concern in an EAP (remote
> access) scenario - the server is usually well known and the client should
> not
> respond to EAP phase 1 exchanges.

Not all of the server addresses are globally well known. Some people
for example do not put security gateways address to dns, and configure
those so that they do not reply to anything than valid requests etc,
so it makes harder for attackers to find those (i.e security by
obscurity). This does not offer real security, but some people do want
to have that kind of features. They do not like the idea that they
need to give out proof that this is roadwarrior-sgw.company.com to all
connections. 

> 3. Most importantly - exchanges which were used in IKEv1 DID support this
> requirement. For example XAUTH requires the server to prove his
> identity first and the client's identity is protected against active
> attacks.
> So protection which is around for current clients using IKEv1 will not be
> there
> after migrating to IKEv2.

XAUTH is not part of IKEv1. So this feature was not in the IKEv1. Also
the original XAUTH versions I looked at did the normal IKEv1 exchange
and only then started the XAUTH. This meant that the client still
needed to proof its identity before starting XAUTH. If people were
using group pre shared keys, then anybody with the key (i.e anybody
with the group) could by active attack get the identities (and
if basic password authentication was used also the password).

Anyways you can still use the ID_KEY_ID (changing every time) as a
identity in those EAP cases, and have very small program in the sgw
end that will convert that ID_KEY_ID to the real EAP identity. This
will offer completele protection to the initiators identity, without
any change to the IKEv2 protocol, and with very minor changes to those
implementations that actually require this. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 30 Jun 2003 11:14:49 -0700

Hi Tero,

Tero Kivinen wrote:
| Jesse Alpert writes:
|
|>2. The polling attack mentioned below is of little concern in an EAP
(remote
|>access) scenario - the server is usually well known and the client should
|>not
|>respond to EAP phase 1 exchanges.
|
|
| Not all of the server addresses are globally well known. Some people
| for example do not put security gateways address to dns, and configure
| those so that they do not reply to anything than valid requests etc,
| so it makes harder for attackers to find those (i.e security by
| obscurity). This does not offer real security, but some people do want
| to have that kind of features. They do not like the idea that they
| need to give out proof that this is roadwarrior-sgw.company.com to all
| connections.

For mainstream remote access scenarios, and certainly for wireless
scenarios, the sgw is well known to its users, at least by IP address. I
can understand the desire to mitigate damage due to polling attacks
under some circumstances, but that risk does not outweigh the threat
posed by easy discovery of user identities in wlan scenarios. We really
should provide a method for concealing user identities in these scenarios.

|>3. Most importantly - exchanges which were used in IKEv1 DID support this
|>requirement. For example XAUTH requires the server to prove his
|>identity first and the client's identity is protected against active
|>attacks.
|>So protection which is around for current clients using IKEv1 will not be
|>there
|>after migrating to IKEv2.
|
|
| XAUTH is not part of IKEv1. So this feature was not in the IKEv1. Also
| the original XAUTH versions I looked at did the normal IKEv1 exchange
| and only then started the XAUTH. This meant that the client still
| needed to proof its identity before starting XAUTH. If people were
| using group pre shared keys, then anybody with the key (i.e anybody
| with the group) could by active attack get the identities (and
| if basic password authentication was used also the password).

XAUTH is not officially part of IKE, but it is the de facto IKEv1 remote
access solution. Hybrid-mode implementations are the most secure
embodiment of XAUTH, and these do require the client to prove its
identity prior to establishment of a secure channel. The fact that most
XAUTH deployments are susceptible to a MiM attack resulting from their
use of group preshared keys does not render Jesse's argument less valid.
We need identity protection for the initiator in remote access scenarios.

| Anyways you can still use the ID_KEY_ID (changing every time) as a
| identity in those EAP cases, and have very small program in the sgw
| end that will convert that ID_KEY_ID to the real EAP identity. This
| will offer completele protection to the initiators identity, without
| any change to the IKEv2 protocol, and with very minor changes to those
| implementations that actually require this.

This might meet some user's needs, but it does not scale well. It
requires synchronization between the sgw and the remote access clients,
and new lists of IDs must be provided to both on an ongoing basis. It is
not a good general solution.

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 30 Jun 2003 11:59:22 -0700

Correction below...

Scott G. Kelly wrote:
| XAUTH is not officially part of IKE, but it is the de facto IKEv1 remote
| access solution. Hybrid-mode implementations are the most secure
| embodiment of XAUTH, and these do require the client to prove its

...Should have said "do require the SERVER to prove its"

| identity prior to establishment of a secure channel. The fact that most
| XAUTH deployments are susceptible to a MiM attack resulting from their
| use of group preshared keys does not render Jesse's argument less valid.
| We need identity protection for the initiator in remote access scenarios.
|
| | Anyways you can still use the ID_KEY_ID (changing every time) as a
| | identity in those EAP cases, and have very small program in the sgw
| | end that will convert that ID_KEY_ID to the real EAP identity. This
| | will offer completele protection to the initiators identity, without
| | any change to the IKEv2 protocol, and with very minor changes to those
| | implementations that actually require this.
|
| This might meet some user's needs, but it does not scale well. It
| requires synchronization between the sgw and the remote access clients,
| and new lists of IDs must be provided to both on an ongoing basis. It is
| not a good general solution.
|
| Scott

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 30 Jun 2003 22:32:53 +0300

> not a good general solution.

I would more likely think about protocol like this:

       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni         -->

                                  <--    HDR, SAr1, KEr, Nr, [CERTREQ]

       HDR, SK {IDi(ID_KEY_ID=<random>, [CERTREQ,] [IDr,]
                SAi2, TSi, TSr}   -->

                                  <--    HDR, SK {IDr, [CERT,] AUTH,
                                                EAP }

       HDR, SK {EAP, [AUTH], N(UPDATE-ID-KEY-ID=<new random>)
			    }     -->

                                  <--    HDR, SK {EAP, [AUTH],
                                                  SAr2, TSi, TSr,
						  N(UPDATE-CONFIRMED)}

And then next time the client will use <new random> as ID_KEY_ID. If
the connection breaks down before the client gets UPDATE-CONFIRMED
notification it will use the old ID_KEY_ID next time too, and
responder would need to keep two ID's, i.e the old and the new (the
client will use the old, if it didn't get the last UPDATE-CONFIRMED
message, or new if it did actually get the message). When ever server
sees the <new random> as ID_KEY_ID it can move the <new random> to be
old, and it will get new random very soon...

I think this can be solved as separate extension to IKEv2, there is no
need to put it in the IKEv2 base document. We MUST say "no more
features" to IKEv2 some day, and that day has already gone.

Also as this issue was already discussed earlier on the mailing list
and the decision about was made that this will not make the IKEv2
document, I do not think it is usefull to continue this discussion on
this issue now. 

The original discussion and decision about this can be found from:

Hugo's original email:
http://www.vpnc.org/ietf-ipsec/mail-archive/msg03639.html

Area Directors comments:
http://www.vpnc.org/ietf-ipsec/mail-archive/msg03653.html

Working group chairs comments:
http://www.vpnc.org/ietf-ipsec/mail-archive/msg03809.html
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 30 Jun 2003 13:31:08 -0700

Tero Kivinen wrote:
<trimmed...>

| I think this can be solved as separate extension to IKEv2, there is no
| need to put it in the IKEv2 base document. We MUST say "no more
| features" to IKEv2 some day, and that day has already gone.
|
|
| Also as this issue was already discussed earlier on the mailing list
| and the decision about was made that this will not make the IKEv2
| document, I do not think it is usefull to continue this discussion on
| this issue now.

I appreciate the desire to contain discussions, but let's be very clear
about this: this issue was raised as part of last call for IKEv2, and a
significant number of folks have offered support for the notion that
this is a significant shortcoming in the current spec. It is
inappropriate to simply quash the discussion because you don't like the
idea.

If last call has degenerated to a symbolic gesture which is not intended
to really flush out final issues, then I guess you are within your
rights. Otherwise, what is the resolution process when issues such as
these are raised? I'm not sure what the appropriate procedure is here,
but this is important. Do we need to take it to the IESG, or can we
solve it here?

Scott

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Mon, 30 Jun 2003 17:37:48 -0400

>but this is important. Do we need to take it to the IESG, or can we

There is, however, a need to avoid resurrecting the same issue over and over;
Tero gave three URLs in the WG list archives that point back to the same topic
(as Hugo raised it, first URL below). Given the lack of much discussion, Russ'
comments (see second URL below, copied from Tero's message), and Ted and
Barbara's decision (third URL) two months ago, it would seem to me that the
issue is closed. I personally agree that active identity protection is
important, but I think this discussion is going around in circles.

I also like Tero's suggestion --- it's not perfect, but it's good enough for
most purposes, and it won't block the IKEv2 document from moving forward.
Cheers,
-Angelos

Hugo's original email:

Area Directors comments: