Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins <[e-mail]>]

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.