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

RE: IKEv2: active user identity protection



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: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tero Kivinen
Sent: Monday, June 30, 2003 10:33 PM
To: Scott G. Kelly
Cc: Jesse Alpert; ipsec@lists.tislabs.com
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
--
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/