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

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,

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:

Area Directors comments:

Working group chairs comments:
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/