SPAKE2, a Password-Authenticated Key Exchange
draft-irtf-cfrg-spake2-26

Received changes through RFC Editor sync (created alias RFC 9382, changed title to 'SPAKE2, a Password-Authenticated Key Exchange', changed abstract to 'This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password.  This method is compatible with any group, is computationally efficient, and has a security proof.  This document predated the Crypto Forum Research Group (CFRG) password-authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial.  Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2.  This document is a product of the Crypto Forum Research Group in the Internet Research Task Force (IRTF).', changed standardization level to Informational, changed state to RFC, added RFC published event at 2023-09-30, changed IRTF state to Published RFC)

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-irtf-cfrg-spake2-25 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
IANA Operations Manager

[Ballot comment]
I found this text in the Introduction to be helpful.

“SPAKE2 was not selected as the result of the CFRG PAKE selection competition. However, given existing use of variants in Kerberos and other applications it was felt publication was beneficial.”

Perhaps it’s worth including in the Abstract as well, because it does explain why the document is being published in a way that’s not clear from the Abstract now.

If that makes sense, perhaps it’s worth including the second sentence in this text from the Introduction, in the Abstract as well.

“Many of these applications predated methods to hash to elliptic curves being available or predated the publication of the PAKEs that were chosen as an outcome of the PAKE selection competition. In cases where a symmetric PAKE is needed, and hashing onto an elliptic curve at protocol execution time is not available, SPAKE2 is useful.”

I’m obviously not a CFRG guy, so I don’t know what crypto people need to see first, but I’m surprised that section 3.2 doesn’t come before section 3.1. It does an excellent job of explaining how SPAKE2 works as a protocol at a higher level than 3.1.

One nit in 3.2 - I see

"If this assignment of roles is not possible a symmetric variant described later MUST be used."

With no pointer for “later”. I scanned the document for the string “symmetric”, and I THINK I know where this text is pointing, but I’m guessing.

While scanning, I noted this text:

"In addition M and N may be equal to have a symmetric variant."

This might be clearer as

"If M and N are equal, this provides a symmetric variant."

Do the right thing, of course!

Technical Summary

This document describes a PAKE (password-authenticated key agreement) protocol SPAKE2 which allows two parties sharing a password to establish a shared key.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Working Group Summary

The document was adopted back in 2015. It predated the CFRG PAKE competition, it was one of the candidates (both in rounds 1 and 2) and it was not selected. Nevertheless, the chairs decided to publish the document with the corresponding disclaimer because KITTEN WG intends to use SPAKE2 .
There was a Research Group Last Call for the draft in October 2020. There was a concern about establishing the identities in-flow from Feng Hao and a possible implementation-security issue from Bjoern Haase. The first question is related to using the protocol in real-world applications and was  earlier discussed during the PAKE selection process. There was no major support of the concern from the implementers of the protocol. The second question was addressed in the updated version of the draft; Bjoern Haase confirmed that he does not have any further remarks about the document.
There were several reviews (regarding both security issues and applicability) during the PAKE selection process: by Scott Fluhrer, Valery Smyslov, Yoav Nir, Brian Warner, Karthik Bhargavan, Thyla van der Merwe, Stanislav Smyshlyaev, David Gotrik, Bjoern Tackmann, Russ Housley, Julia Hesse and Yaron Sheffer. Later in 2020 Liliya Akhmetzyanova and Scott Fluhrer (on behalf of Crypto Review Panel) did reviews for the draft before the Last Call. Comments from the reviewers have been addressed.
There is a related IPR submitted by Björn Haase to the datatracker.

Document Quality

There are at least two implementations with a different key derivation mechanism: for MIT krb5 and for the Magic Wormhole; there is at least one implementation for IoT by Davide Pesavento, which is not currently public, test vectors verified.
The draft has been thoroughly studied during the PAKE Selection Process (https://github.com/cfrg/pake-selection).
The construction is used in KITTEN WG for one of Kerberos documents.

Personnel

Stanislav Smyshlyaev is the Document Shepherd.
Colin Perkins is the IRTF Chair.