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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 8 Aug 2019 10:30:39 +0300

Dear ipsecme,

I am writing this message on behalf of the CFRG chairs.

Currently there is an ongoing PAKE selection process in the CFRG.
According to the plan of the PAKE selection process, the CFRG chairs have
selected a number of PAKE-related topics that require independent reviews
from experts deeply involved in several particular areas of IETF work: TLS
and IPsec protocols, constrained environments and privacy.

The chairs would like to announce the call for reviewers, who will be asked
to prepare their reviews regarding one or more of the following topics
about the nominated PAKEs:
- Convenience for usage within/together with TLS 1.3 Handshake.
*- Convenience for usage within/together with IKEv2.*
- Convenience for usage in M2M/IoT protocols (i.e., with corresponding
constrains on hardware).
- Privacy considerations (e.g., recommendations to prevent user
enumeration).

The experts who would like to volunteer to do such a review are kindly
asked to choose:
1) which topics from the provided list will be considered by them;
2) whether they could prepare their reviews for
- all four balanced PAKEs,
- all four augmented PAKEs or
- all eight candidate PAKEs.

We ask each of the expert to prepare reviews for all PAKEs (or at least all
balanced/all augmented ones) to be sure that each of the PAKEs will be
studied from the same points of view.

*The call for reviewers will last until the 15th of August. Please send a
message to [email-masked] <[email-masked]> or [email-masked]
<[email-masked]>, if you could help. *
Deadline for the reviews is 15th of September.

The reviews will later be provided to Crypto Review Panel experts, who will
prepare their overall reviews during Stage 5.

Best regards,
Stanislav Smyshlyaev,
CFRG Secretary

---

From: Dan Harkins <[email-masked]>
Date: Thu, 29 Aug 2019 15:48:08 -0700

Hello,

   I had some discussions with several people in Montreal on the subject of
using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is
quite cumbersome. I was told I should bring it up on the IPsec list so
here goes (copying CFRG since that's where the PAKE work is being done).

   First of all this suggestion is for a particular PAKE and I'm not
suggesting that any of the other candidates would slide in so effortlessly.
In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
where either side can initiate. The PAKE I'm describing here is SPEKE,
a balance PAKE.

   SPEKE does a simple Diffie-Hellman but uses a secret generator that is
deterministically obtained from the password. This technique is basically
one of the hash-to-curve functions from the CFRG's hash-to-curve I-D
or a simple hashing and exponentiation for MODP groups. All this happens
at password provisioning time prior to IKE being run.

   Then when IKE is run the secret generator for the negotiated group is
used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The
result is, if they both have the same generator (which means they had the
same password), an authenticated shared secret. This secret is verified in
the IKE_AUTH exchange.

   This would require a new Auth Method defined for SPEKE/PAKE to indicate
that the SPEKE shared secret is used. And that should be all that's needed.
It should be that simple. The protocol shouldn't have to change, no new
messages, no new payloads, no new nuthin. If I'm missing something please
let me know.

   regards,

   Dan.

On 8/8/19 12:30 AM, Stanislav V. Smyshlyaev wrote:
> According to the plan of the PAKE selection process, the CFRG chairs 
> have selected a number of PAKE-related topics that require independent 
> reviews from experts deeply involved in several particular areas of 
> IETF work: TLS and IPsec protocols, constrained environments and privacy.
>
> The chairs would like to announce the call for reviewers, who will be 
> asked to prepare their reviews regarding one or more of the following 
> topics about the nominated PAKEs:
> We ask each of the expert to prepare reviews for all PAKEs (or at 
> least all balanced/all augmented ones) to be sure that each of the 
> PAKEs will be studied from the same points of view.
>
> *The call for reviewers will last until the 15th of August. Please 
> send a message to [email-masked] <mailto:[email-masked]> or 
> [email-masked] <mailto:[email-masked]>, if you could help. *
> The reviews will later be provided to Crypto Review Panel experts, who 
> will prepare their overall reviews during Stage 5.
>
> Best regards,
> Stanislav Smyshlyaev,
> CFRG Secretary
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Aug 2019 03:11:26 +0300

[removed cfrg from CC, as I do not think this issue really belongs
there as we are discussing IKE signaling here].

> same password), an authenticated shared secret. This secret is verified in

How does the responder know which of the one million username password
pairs to pick to generate the generator when calculating D-H in the
IKE_SA_INIT? The actual identity of the user is only sent in the
encrypted IKE_AUTH message. 

I.e., I think this has exactly same problem than IKEv1 has with
pre-shared keys for main mode. You must know the initiator identity
based on the IP-addresses, thus makes this completely unusable for
non static VPN cases.

-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Aug 2019 22:55:09 -0400

> quite cumbersome. I was told I should bring it up on the IPsec list so

Understood, but could you say, despite that, why it's worth it for SPEKE?
Afterall, we adopted EAP, which could also be said to be quite cumbersome
rather than build all sorts of username/password and 3GPP/SIM integrations..

    > where either side can initiate. The PAKE I'm describing here is SPEKE,

Got it.

    > messages, no new payloads, no new nuthin. If I'm missing something please

As I understand you, it's basically PSK authentication, but the PSK is
no longer directly shared.  Would the QM "augmentation" of PSK have any value
here?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Aug 2019 00:11:28 -0700

> based on the IP-addresses, thus makes this completely unusable for

   HA! I did miss something :-)

   Yes, I guess a new payload is needed to express the username. This can
be added to the IKE_SA_INIT message. Or maybe it can be a special type of
NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this
should not involve an extra Auth exchange (as the framework PAKEs do)
since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE
is.

   regards,

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Aug 2019 01:13:33 -0700

> rather than build all sorts of username/password and 3GPP/SIM integrations..

   The "PAKE framework" is complicated and unnecessary. Around the time 
that I
was proposing a PAKE for IKE, "EAP-only" IKE was also being proposed. As it
turns out the only reason to use EAP-only IKE was with a PAKE-- server-side
cert was taken care of by normal EAP-IKE and if both sides have a cert then
just do plain jane IKE. But the chairs at the time had a vested interest in
doing EAP-only and in making PAKE, the alternative to EAP-only, be as
cumbersome as possible. And so we got this mess that no one implements.

   SPEKE can just fall straight into the IKE_SA_INIT exchange (with a 
username
indicator as Tero pointed out) and it is authenticated with the IKE_AUTH
exchange. There is no additional framework messaging and there is no EAP
messaging and overhead. It's clean.

> no longer directly shared.  Would the QM "augmentation" of PSK have any value

   Yes, that's a way of thinking of it. The PSK is not shared and no 
PSK-derived
data is shared. Both sides prove they know the secret without exposing it.

   regards,

   Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Aug 2019 12:27:50 +0300

> since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE

We had similar discussion in the postquantum preshared keys case,
i.e., we needed to know the identity of the other end to pick the PPK,
but the identity is only transmitted in the IKE_AUTH, and IKE_AUTH is
encrypted with the key which is generated in IKE_SA_INIT. We solved
this issue in qr-ikev2 by making so that encryption of the IKE_AUTH
does not need the PPK, but uses only normal Diffie-Hellman and PPK is
only added to the actual IPsec trafic keys.

The problem is that if we add the identity to the IKE_SA_INIT, then we
loose the identity protection part of the IKEv2, as we then cannot
encrypt the identity.

Current solutions have been trying to keep the identity protection
part as good as it is without those extensions, i.e., qr-ikev2 still
provides same identity protection than what normal IKEv2 does, and
then provides extended protection for the actual trafic keys. Attacker
who can break Diffie-Hellman can see the identities, but will not see
the actual trafic protected by PPK.

With PAKEs, I think it is important to do the same, i.e., keep the
identity protection parts of the IKEv2 at least as good as they are
now, and that usually needs we need to do normal IKEv2 Diffie-Hellman
first to protect identities, and then inside that when we know
identities do the actual authentication using PAKE.

Hybrid qske does things bit differently as it adds IKE_INTERMEDIATE
exchanges between IKE_SA_INIT and IKE_AUTH but all of those
IKE_INTERMEDIATE exchanges are anonymous, i.e., the identity of the
other end is not yet known, the authentication is done in the end with
IKE_AUTH, and only then the identity of the other end is known, and we
can use per user information like shared keys or password etc.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Aug 2019 10:40:42 -0400 (EDT)

> the actual trafic protected by PPK.

And libreswan added a method where you can migrate from "no PPK" to
"PPK" by sending two AUTH payloads in the IKE_AUTH. The other end
can then pick which they want to use. Perhaps with PAKE's, it too
could send another AUTH payload in a notify so it does not have to
be sent in IKE_SA_INIT, yet does not incur another round trip if
both parties support the same PAKE.

Paul

---

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Aug 2019 08:35:45 -0700

> loose the identity protection part of the IKEv2, as we then cannot

   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.

> can use per user information like shared keys or password etc.

Yes, we can do a PAKE exchange after IKE_SA_INIT and use that to do
identity protection. It just does add another round trip and I was trying
to point out how we can get a PAKE mode of IKE without any additional
round trips or things like that. SPEKE is just a Diffie-Hellman and IKE
already does a Diffie-Hellman. With the identity protection scheme I
described above we're doing a 2nd Diffie-Hellman so work-wise it's a
wash but from a protocol standpoint I think it's cleaner.

The qr-ikev2 stuff is done that way but that's because we want to augment
the qr exchange with a traditional D-H. That's the design. There is no
reason to force PAKEs to do the same thing, which isn't to say we can't
just that we don't have to.

   regards,

   Dan.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Aug 2019 12:16:46 -0400 (EDT)

> 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.

Administrators doing site-to-site VPNs are better of using a true random
strong PSK instead of a weaker PAKE.

Paul

---

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Aug 2019 09:48:14 -0700

> X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method

   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.

> 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.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Aug 2019 13:51:10 -0400 (EDT)

> then why not just use IKE?

Because "just use IKE" with Machine Certificates on Windows requires
Administrator priviledge, while using the exact same certificates for
EAPTLS only requires the user priviledges.

Is that worth 8 roundtrips? Our opinion does not matter, but Microsoft
thinks it does :(

>   EAP is an abomination.

I'll drink to that!

> routine we seem to do every 9 months. How many "dies" are we up to now?

I did not add killing PSKs to that draft, precisely because some
objected because strong PSK's are stronger than PAKEs.

> solution for administrators that will do what we know they're gonna do 

Fair enough. Although people configuring Cisco's will use PSK for the
next 20 years even if we got an RFC tomorrow. I still regularly see
modp1024 flying by - in fact more so now because libreswan stopped
supporting it so people upgrading are finally finding out they have
a 15+ year old weak configuration.

> needed, then there's a provisioning step or we do an additional roundtrip.

True as well,

Paul

---

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Aug 2019 13:01:58 -0700

> objected because strong PSK's are stronger than PAKEs.

   Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added
protection of resistance to dictionary attack against the symmetric 
credential
(which could, in fact, be a PSK).

   The definition of dictionary attack is one in which the adversary 
gains an
advantage through computation and not interaction. So even with a strong PSK
you are still susceptible to a dictionary attack since it is the 
protocol that
is susceptible to attack and not the credential. With a strong PSK it just
makes the dictionary attack use much more time to be successful (and yes the
"true random strong PSK" that's 256 bits could make the attack 
computationally
infeasible but then managing such a credential is similarly infeasible).

   Think of it this way, if your strong PSK has 64 bits of good randomness
it will take around 2^32 offline computations after A SINGLE ACTIVE 
ATTACK to
get a probability of 0.5 of success while if you used that same thing with a
PAKE it would take around 2^32 ACTIVE ATTACKS to get a probability of 0.5.

   What a PAKE allows you to do is retain security even in the presence of a
not-so strong PSK. It does not mean the PAKE is weak. We should not be
standardizing a weak PAKE and I don't think any of the candidates that CFRG
is considering are weak.

   If you can manage a "strong PSK" then using it with a PAKE makes it 
stronger.
If you can't manage a "strong PSK" then a PAKE still increases security. 
There's
really no reason to use a PSK exchange susceptible to dictionary attack when
something like SPEKE is available.

   regards,

   Dan.