The second use case does not require any anonymity:
o Two peers without any trust relationship want to get some level of
security in their communications. Without trust relationship they
cannot prevent active Man-in-the-Middle attacks, but it is still
possible to prevent passive eavesdropping with opportunistic
encryption. In this case they have to perform unauthenticated key
exchange.
Actually even the first use case, having non-authenticated identity
would still be useful in some cases. For example if I will protect my
home server with null-authenticated IPsec, people most likely will
still want to verify my servers authentication, and they might want to
provide meaningful unauthenticated ID, even when it is not needed. The
meaningful ID might be something that is not meaningful in global
context, but it might be meaningful for me, i.e. just nickname or
similar.
If they want to do something where I would require them to do
authentication then I would most likely still use my (self signed)
certificate based authentication for server (with certificate pinning
and TLSA records in DNSSEC signed zone), and they would use similar
locally meaningful ID and raw public key to authenticate themselves to
my server.
I.e. I will see the upgrade path from null-auth -> raw public keys
very logical in small private use setups.
And once we start using raw public keys (or self signed certs), we can
use out-of-band means to upgrade the identity from "claimed but
unauthenticated" to "authenticated". This is what we're proposing in
AutoVPN.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
