Michael Richardson writes: > > 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. > > Wow, this is indeed complex, yet I actually think this might matter to > systems that have the various (not-standardardized, alas), ad-hoc VPN > mechanisms, such that gateways without static IPs can be found. > > I think that we can leave it out of scope for now, but perhaps we don't > really need to say a lot about it, except what you just wrote.
Yep. Leaving it out of scope for that future draft is fine for me... > > 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. > > Previously, in the typical large scale road warrior case, where a client has > a certificate signed by a private CA, and the policy is essentially that any > client with a valid certificate (modified by OCSP and CRLs, etc.), which is > also provided in-band in a CERT payload, and any such client can connect > and gets the same policy, I wonder if we can somehow dispense with the IDi > completely, or use a constant value. > > Now, with a Quantum Resistant mechnanism, we are mixing per-host-pair PSK > into the > resulting IPsec (and perhaps IKE PARENT SA) sessions keys, but I'm unclear if > we'd still be using RSA/ECDSA/EdDSA certificates at all. I know that there > are QM resistant asymmetric mechanism envisioned, but I know so little about > them. If you really care about the identity protection, you cannot transmit certificates or raw public keys in-band, as those will immediately reveal your identity (or at least the fact that you are same user than last time). You might even reveal this to passive attacker, who might be able to know that this is [email protected] and this other one is [email protected] by just looking that the length of the IKE_AUTH payload... So with identity protection you want to keep all that authentication information local, and when the server receives the random pseudonym, it can map that to the PAD entry and PAD entry then has either shared-key, certificate or raw public key associated with it and that is used for autentication. > > I.e., the lookup would go like follows: > > > IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54 > > I think that this is a random string you made up, not a constant value. Yep, and it can be changed at any time by using some mechanism we have not yet defined, but which will be run over the IKE SA after we have made it so that it gains resistance against quantum attackers. > > 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. > > Is it reasonable to describe this Pseudonum update mechanism seperately, or > do you think it is too heavily connected to the quantum resistance I do not think it is in any way connected to the quantum resistance, so I think it is better to describe it as separate document. Note, that we even could simply make simple IPsec SA to the web server in the SGW and then use the rest API over http over that IPsec SA and change the pseudonym in that way. The way I described was just one way we can do it, and the actual draft that will define this protocol, needs to decide how it is actually going to work. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
