Valery Smyslov writes: > CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But > CREATE_CHILD_SA doesn’t allow to exchange identities. So, if > pseudonyms were used in IKE_AUTH, how are you going to exchange real > identities?
Real IDs are never exchanged over wire. The server sees pseudonym ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from its table and finds a mapping from there to [email protected]. From then on it uses [email protected] as authenticated identifier, and verifies that the raw public key, or shared key used to authenticate the user actually matches the one configured to the [email protected]. Using certificates in this case would leak out the identity anyways, so they cannot be used, or at least transmitted over wire. Even if using raw public keys, the actual public keys must not be sent over wire, it needs to be taken from the configuration. > And the peers must also somehow prove their real identities, so AUTH > payloads must also be included, and we end up with something like > full IKE_AUTH exchange... This all is done in the server, i.e. instead of using the ID sent over the wire, the server uses the ID sent over wire as handle to the table, and fetches the real ID to be used for policy decisions and authentication from the that table. Then psedonym update protocol is run later, after we have done IKEv2 SA rekey to gain QR for IKEv2 SA too, and that would say update the ID_KEY_ID from \x1c747c060d209a223d1f9f51b0351b54 to \x7ca765c1972372cecf78184d1a628d05, and next time client comes in he does not use the ID_KEYID of \x1c747c060d209a223d1f9f51b0351b54, but he uses the new ID_KEY_ID \x7ca765c1972372cecf78184d1a628d05 instead. Note, again that how those pseudonyms are generated and what kind of format they have is outside the scope of this protocol. Of course the pseudonum protocol most likely would need some kind of safe guards against getting out of sync in client and server, for example client could send 10 next pseudonyms, and server could allow any one of them to be used. > So, I think that the problem of protecting anonymity cannot be > easily solved now without substantial complicating of the protocol > (unless I misunderstood something very obvious). My vote is for > follow-up draft (if it happen to appear at all) or > for going back to original QR proposal. I disagree on, that but that does not matter, as we do not need to specify it now. I am convinced that we can do it separately provided we have a way to making IKEv2 SA also protected against QR attacks somehow (i.e., make IKEv2 SA rekey to provide IKEv2 SA QR properties). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
