Hi Tero, as far as I understand, this proposal is not tied up with QR problem and can be used independently. So I suggest not to mix it with the proposed QR solution in one document.
Regards, Valery. > > 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
