ID_KEY_ID style user identity protection

[Tero Kivinen <kivinen@ssh.fi>]

Jesse Alpert writes:
> 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?

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

> - 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)?

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. 

> - 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

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). 

>   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?

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