Valery Smyslov writes: > Hi Tero, > > > > 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 > > Then what is the content of IDi and IDr in IKE_AUTH in this case?
As I said the IDi would be ID_KEY_D with value of \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the normal server side identity, as hiding server identity is usually not useful as server must have static IP so clients can know where to connect. If server side identity protection is also needed, then server side IDr would also be similar pseudonym, but that would require server to keep track of which IDr was given to which client, and pick suitable IDr based on the IDi coming in. > > 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. > > Again, what role the usual authentication (in IKE_AUTH) and > usual IKE Identities play in this scenario? They would play their normal role, i.e. they would be used to authenticate the connection. The only difference is that the IDi on the wire would not be the real identity but the a random pseudonym, and that pseudonym is then used by the server to fetch the real identity which would then be used for policy purposes. To provide full identity protection, even the server should not use any long term identity like [email protected], but instead just use some kind of user id and map that user id to the actual policy. I.e., the lookup would go like follows: IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54 -> In server look that id from the known pseudonyms, find entry saying: Pseudonym_ID = \x1c747c060d209a223d1f9f51b0351b54 User_ID = KeyId(\x1234) -> Use User_ID to search PAD for entry to verify authentication and find the related SPD Then when the user changes their pseudonym using the protocol defined later the first list of known pseudonyms would be updated to say: Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af User_ID = KeyId(\x1234) where the Pseudonym_ID is new random pseudonym to be used after that for future exchanges. The User_ID stays same, but it is just internal information inside the server, and is never transmitted over the wire. Of course the User_ID could also be RFC822([email protected]) instead of that kind of random number, but then hacking in to the server could reveal the real user identities for the clients and their next pseudonyms, so that would be bad idea if full protection is needed. Server does not really need to know who is in the other end, he just needs to know how the other end is going to authenticate himself (i.e., which PAD entry to use), and what kind of policy is allowed for that user (i.e., which SPD entries are used). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
