Tero Kivinen <[email protected]> wrote: > 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.
While I think that the client IDs might be a local implementation issue,
if we go down this route, I'd like us the standardize the representation of
how they IDs are presented, such that, in theory, a user could type them
in. Or, come up with a JSON format for presenting the ID+gateway information.
[ I know that many vertically integrated "solutions" have single file solutions
like the ".pcf" file from Cisco. I'm suggesting standardizing such a thing]
The client ID could well be the real client ID encrypted by the server with a
locally kept key. That would eliminate the database lookup for some systems,
but that might be important. Again: a local implementation issue.
> 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.
> 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.
> 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.
> 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
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
