rfc9382v6.txt   rfc9382.txt 
skipping to change at line 22 skipping to change at line 22
that share a password to derive a strong shared key without that share a password to derive a strong shared key without
disclosing the password. This method is compatible with any group, disclosing the password. This method is compatible with any group,
is computationally efficient, and has a security proof. This is computationally efficient, and has a security proof. This
document predated the Crypto Forum Research Group (CFRG) password- document predated the Crypto Forum Research Group (CFRG) password-
authenticated key exchange (PAKE) competition, and it was not authenticated key exchange (PAKE) competition, and it was not
selected; however, given existing use of variants in Kerberos and selected; however, given existing use of variants in Kerberos and
other applications, it was felt that publication was beneficial. other applications, it was felt that publication was beneficial.
Applications that need a symmetric PAKE, but are unable to hash onto Applications that need a symmetric PAKE, but are unable to hash onto
an elliptic curve at execution time, can use SPAKE2. This document an elliptic curve at execution time, can use SPAKE2. This document
is a product of the Crypto Forum Research Group in the Internet is a product of the Crypto Forum Research Group in the Internet
Researach Task Force (IRTF). Research Task Force (IRTF).
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Research Task Force This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related research (IRTF). The IRTF publishes the results of Internet-related research
and development activities. These results might not be suitable for and development activities. These results might not be suitable for
deployment. This RFC represents the individual opinion(s) of one or deployment. This RFC represents the individual opinion(s) of one or
skipping to change at line 246 skipping to change at line 246
TT = len(A) || A TT = len(A) || A
|| len(B) || B || len(B) || B
|| len(pA) || pA || len(pA) || pA
|| len(pB) || pB || len(pB) || pB
|| len(K) || K || len(K) || K
|| len(w) || w || len(w) || w
Here, w is encoded as a big-endian number padded to the length of p. Here, w is encoded as a big-endian number padded to the length of p.
This representation prevents timing attacks that otherwise would This representation prevents timing attacks that otherwise would
reveal the length of w. len(w) is thus a constant. We include it for reveal the length of w. len(w) is thus a constant for a given group.
consistency. We include it for consistency.
If an identity is absent, it is encoded as a zero-length string. If an identity is absent, it is encoded as a zero-length string.
This MUST only be done for applications in which identities are This MUST only be done for applications in which identities are
implicit. Otherwise, the protocol risks unknown key-share attacks, implicit. Otherwise, the protocol risks unknown key-share attacks,
where both sides of a connection disagree over who is authenticated. where both sides of a connection disagree over who is authenticated.
Upon completion of this protocol, A and B compute shared secrets Ke, Upon completion of this protocol, A and B compute shared secrets Ke,
KcA, and KcB, as specified in Section 4. A MUST send B a key KcA, and KcB, as specified in Section 4. A MUST send B a key
confirmation message so that both parties agree upon these shared confirmation message so that both parties agree upon these shared
secrets. Confirmation message cA is computed as a MAC over the secrets. The confirmation message cA is computed as a MAC over the
protocol transcript TT, using KcA as follows: cA = MAC(KcA, TT). protocol transcript TT, using KcA as follows: cA = MAC(KcA, TT).
Similarly, B MUST send A a confirmation message using a MAC that is Similarly, B MUST send A a confirmation message using a MAC that is
computed equivalently, except with the use of KcB. Key confirmation computed equivalently, except with the use of KcB. Key confirmation
verification requires computing cB and checking for equality against verification requires computing cA (or cB, respectively) and checking
that which was received. for equality against that which was received.
4. Key Schedule and Key Confirmation 4. Key Schedule and Key Confirmation
The protocol transcript TT, as defined in Section 3.3, is unique and The protocol transcript TT, as defined in Section 3.3, is unique and
a secret to A and B. Both parties use TT to derive shared symmetric secret to A and B (though it contains some substrings that are not
secrets Ke and Ka as Ke || Ka = Hash(TT), with |Ke| = |Ka|. The secret). Both parties use TT to derive shared symmetric secrets Ke
length of each key is equal to half of the digest output, e.g., 128 and Ka as Ke || Ka = Hash(TT), with |Ke| = |Ka|. The length of each
bits for SHA-256. Keys MUST be at least 128 bits in length. key is equal to half of the digest output, e.g., 128 bits for SHA-
256. Keys MUST be at least 128 bits in length.
Both endpoints use Ka to derive subsequent MAC keys for key Both endpoints use Ka to derive subsequent MAC keys for key
confirmation messages. Specifically, let KcA and KcB be the MAC keys confirmation messages. Specifically, KcA and KcB are the MAC keys
used by A and B, respectively. A and B compute them as KcA || KcB = used by A and B, respectively. A and B compute them as KcA || KcB =
KDF(Ka, nil, "ConfirmationKeys" || AAD, L), where AAD is the KDF(Ka, nil, "ConfirmationKeys" || AAD, L), where AAD is the
associated data given to each endpoint or AAD is nil if none was associated data given to each endpoint or AAD is nil if none was
provided. The length of each of KcA and KcB is equal to half of the provided. The length of each of KcA and KcB is equal to half of the
underlying hash output length, e.g., |KcA| = |KcB| = 128 bits for underlying hash output length, e.g., |KcA| = |KcB| = 128 bits for
HKDF(SHA256), with L=256 bits. HKDF(SHA256), with L=256 bits.
The resulting key schedule for this protocol, given transcript TT and The resulting key schedule for this protocol, given transcript TT and
AAD, is as follows. AAD, is as follows.
skipping to change at line 305 skipping to change at line 306
M = hash_to_curve(Hash("M SPAKE2" || len(A) || A || len(B) || B)) M = hash_to_curve(Hash("M SPAKE2" || len(A) || A || len(B) || B))
N = hash_to_curve(Hash("N SPAKE2" || len(A) || A || len(B) || B)) N = hash_to_curve(Hash("N SPAKE2" || len(A) || A || len(B) || B))
There is also a symmetric variant where M=N. For this variant, we There is also a symmetric variant where M=N. For this variant, we
set: set:
M = hash_to_curve(Hash("M AND N SPAKE2")) M = hash_to_curve(Hash("M AND N SPAKE2"))
This variant MUST be used when it is not possible to determine This variant MUST be used when it is not possible to determine
whether A or B should use M or N, due to asymmetries in the protocol whether A or B should use M (or N), due to asymmetries in the
flows or the desire to use only a single shared secret with nil protocol flows or the desire to use only a single shared secret with
identities for authentication. The security of these variants is nil identities for authentication. The security of these variants is
examined in [MNVAR]. The variant with per-user M and N may not be examined in [MNVAR]. The variant with per-user M and N may not be
suitable for protocols that require the initial messages to be suitable for protocols that require the initial messages to be
generated by each party at the same time and that do not know the generated by each party at the same time and that do not know the
exact identity of the parties before the flow begins. exact identity of the parties before the flow begins.
6. Ciphersuites 6. Ciphersuites
This section documents SPAKE2 ciphersuite configurations. A This section documents SPAKE2 ciphersuite configurations. A
ciphersuite indicates a group, cryptographic hash function, and pair ciphersuite indicates a group, cryptographic hash function, and pair
of KDF and MAC functions, e.g., SPAKE2-P256-SHA256-HKDF-HMAC. This of KDF and MAC functions, e.g., SPAKE2-P256-SHA256-HKDF-HMAC. This
skipping to change at line 441 skipping to change at line 442
The choices of random numbers MUST be uniform. Randomly generated The choices of random numbers MUST be uniform. Randomly generated
values, e.g., x and y, MUST NOT be reused; such reuse violates the values, e.g., x and y, MUST NOT be reused; such reuse violates the
security assumptions of the protocol and results in significant security assumptions of the protocol and results in significant
insecurity. It is RECOMMENDED to generate these uniform numbers insecurity. It is RECOMMENDED to generate these uniform numbers
using rejection sampling. using rejection sampling.
Some implementations of elliptic curve multiplication may leak Some implementations of elliptic curve multiplication may leak
information about the length of the scalar. These MUST NOT be used. information about the length of the scalar. These MUST NOT be used.
All operations on elliptic curve points must take time independent of All operations on elliptic curve points must take time independent of
the inputs. Hashing of the transcript may take time, depending only the inputs. Hashing of the transcript may take time depending only
on the length of the transcript but not the contents. on the length of the transcript but not the contents.
SPAKE2 does not support augmentation. As a result, the server has to SPAKE2 does not support augmentation. As a result, the server has to
store a password equivalent. This is considered a significant store a password equivalent. This is considered a significant
drawback in some use cases. Applications that need augmented PAKEs drawback in some use cases. Applications that need augmented PAKEs
should use [CFRG-OPAQUE]. should use [CFRG-OPAQUE].
The HMAC keys in this document are shorter than recommended in The HMAC keys in this document are shorter than recommended in
[RFC8032]. This is appropriate, as the difficulty of the discrete [RFC8032]. This is appropriate, as the difficulty of the discrete
logarithm problem is comparable with the difficulty of brute forcing logarithm problem is comparable with the difficulty of brute forcing
 End of changes. 8 change blocks. 
15 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.48.