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

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:
> 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] <mailto:[email-masked]> or 
> [email-masked] <mailto:[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
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

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