On 8/30/19 9:16 AM, Paul Wouters wrote:
On Fri, 30 Aug 2019, Dan Harkins wrote:
Sure we can. We could do the thing that was done in TLS-pwd. When the
client registers his username and password she gets a static DH public
key of the server (TLS-pwd made this be a p256 curve for its compact
representation and adequate strength for the purpose of identity
protection). The scheme then is if the client wants to protect its
identity it uses the server's DH public key and does a static-ephemeral
exchange, gets a secret, encrypts its identity and sends its ephemeral
DH key (in compact representation, it's 33 octets) plus the encrypted
identity in one "identity payload". If it doesn't care about identity
protection it just sends its identity.
EAPTLS already uses like 8 round trips. So anything that has PAKE using
less than 8 seems like a win already :P So I am fine adding a few
roundtrips for whatever PAKE we come up with if that avoids all of this
extra complexity. Especially if this complexity is something that is
added
to the client provisioning.
Remember this PAKE stuff is meant for those scenarios where we have an
enduser with _only_ a username/password. If this requires installing
additional client configuration, those clients might as well go to
X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method
supporting OTPs.
Doing EAPTLS seems pointless. If your "additional client configuration"
involved a new trust anchor and an EST exchange and an X.509 certificate
then why not just use IKE?
EAP is an abomination. It includes an identity request/response roundtrip
that generates an identity that the EAP RFC says is unsuitable for any
authentication purpose. Imagine that, an "authentication" protocol that
wastes a roundtrip getting a useless identity and then punts off the job
of getting a usable identity to another authentication protocol that has
to wrap itself in an EAP encapsulation. Putting EAP into IKE was a bad idea
and it seems doubly bad to put a PAKE (or PSK or OTP) into EAP inside IKE.
Administrators doing site-to-site VPNs are better of using a true random
strong PSK instead of a weaker PAKE.
Well how many administrators generate a nice string of 256-bits of "true
random strong PSK"? Seriously, if administrators followed such advice then
we would not continually adding another "die" on the "die die die IKEv1"
routine we seem to do every 9 months. How many "dies" are we up to now?
Management of such "true random strong PSKs" is a pain which is why
administrators use PSKs that are shorter, easier to remember, and easier to
enter with a high probability of being correct. So a PAKE is just a robust
solution for administrators that will do what we know they're gonna do
anyway.
They're not weak.
For a site-to-site VPN something like "identity protection" might not be
that big of a deal so there need not be any client provisioning. A simple
phone call between the 2 parties could suffice. If identity protection is
needed, then there's a provisioning step or we do an additional roundtrip.
regards,
Dan.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
