Subject: RE: IKEv2: active user identity protection

From: "Jesse Alpert" <[email-masked]>
Date: Tue, 1 Jul 2003 10:04:30 +0300

Hi,

From an implementers point of view it seems to me there are a lot of
(overlooked ?) problems in this ID_KEY_ID protocol.
- How does the SGW know the random ID_KEY_ID the first time?
- Does the SGW have to maintain it's own ID_KEY_ID to user database
  (apart from a RADIUS server etc. it may be using)?
- When does the SGW flush this data to the database - it can't be done
  for every exchange for performance reasons. On the other hand, if the
  SGW sends N(UPDATE-CONFIRMED) before the data is flushed it may go down
  before storing this data causing synchronization problems.
- Does the user always need to connect from the same machine? Otherwise how
  is the ID_KEY_ID transported between the machines? What if the user is
  connecting from an internet-cafe?
I know all of these questions probably have solutions, but this certainly
does
not look like "very minor changes to those implementations that actually
require this"

BTW doesn't the fact that the server and the client share a random secret
number (ID_KEY_ID) already prove the client's identity?

Again current solutions, used by many customers today (such as Hybrid+XAUTH)
do provide this protection. (Usually the first part of the exchange requires
the server to authenticate using a certificate, only then the client
authenticates).

If you look in the follow-ups section of the references you attached you
will notice
that some implementers (admittedly less than I remember) answered Hugo and
voted for
the change.

Jesse

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tero Kivinen
Sent: Monday, June 30, 2003 10:33 PM
To: Scott G. Kelly
Cc: Jesse Alpert; [email-masked]
Subject: Re: IKEv2: active user identity protection

Scott G. Kelly writes:
> | 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.

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: Tero Kivinen <[email-masked]>
Date: Tue, 1 Jul 2003 12:59:45 +0300

> - How does the SGW know the random ID_KEY_ID the first time?

Same way than it knows about the username and password, i.e by
configuration. 

>   (apart from a RADIUS server etc. it may be using)?

Depends on the implementation. If it is using RADIUS, it propably
needs to convert the ID_KEY_ID to username before sending it to
RADIUS, if it uses LDAP or similar, it can actually store the
information to LDAP etc.

On the other hand if we modify the protocol so that the server sends
the next ID_KEY_ID, then it can actually use symmetric crypto and send
SK{random-salt | username | counter-or-timestamp) to the client and
when it receives it back it can simply decrypt that and see the
username from there.

There are multiple ways to do the protocol, my example was simply one
of those. 

>   for every exchange for performance reasons. On the other hand, if the

Compared to the Diffie-Hellman I do not think it will be very costly
to flush the data to database. On the other hand if you use the
encrypted username scheme, there is no need to update anything, as it
can see the username from the message and the it is clients problem if
client uses the same ID_KEY_ID multiple times (attacker does not gain
anything by using it again). 

>   connecting from an internet-cafe?

Propably yes, unless he have some kind of token or something that
actually can store the ID_KEY_ID also. If person is concerned about
the security of his identity, is he really going to use machine from
internet-cafe? When he walked in to the internet-cafe, there already
propably was one web-cam or similar taking picture of him, and the
machine there is most likely going to have data logger storing all
keypresses anyways (i.e it will store the username anyways)... At
least it is much easier to install those to all internet-cafe machines
than to do active attack to get the identity.

I never use any of those machines in the internet-cafe, even if I am
not concerned about my identity leaking, but I do not trust those
machines in general at all. If I need to login from wierd places, I
will use my own laptop or if it is not possible, then I do not login.

> If you look in the follow-ups section of the references you attached
> you will notice that some implementers (admittedly less than I
> remember) answered Hugo and voted for the change.

I actually did read those complete threads through before sending the
email. This issue was also bring up even earlier, and I think some of
the people simply ignored the discussion as it was already repeated
issue at that point.

I think quite a lot of the implementators actually do care about this
issue, but they do not want to start modifying the IKEv2 now. We do
need something we can use now. Also as I said I think this can be done
later by using ID_KEY_ID, thus we can attack this problem after IKEv2
is out. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/