rfc9588.original.xml   rfc9588.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc compact="yes"?> <!-- draft submitted in xml v3 -->
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc autobreaks="yes"?>
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" <!DOCTYPE rfc [
category="std" docName="draft-ietf-kitten-krb-spake-preauth-13" <!ENTITY nbsp "&#160;">
consensus="true" ipr="trust200902" xml:lang="en" version="3"> <!ENTITY zwsp "&#8203;">
<front> <!ENTITY nbhy "&#8209;">
<title>Kerberos SPAKE Pre-Authentication</title> <!ENTITY wj "&#8288;">
<seriesInfo name="Internet-Draft" ]>
value="draft-ietf-kitten-krb-spake-preauth-13"/>
<seriesInfo name="std" value=""/>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
std" docName="draft-ietf-kitten-krb-spake-preauth-13" number="9588" consensus="t
rue" ipr="trust200902" obsoletes="" updates="" tocInclude="true" symRefs="true"
sortRefs="true" xml:lang="en" version="3">
<front>
<title abbrev="Kerberos SPAKE Pre-authentication">Kerberos Simple Password-A
uthenticated Key Exchange (SPAKE) Pre-authentication</title>
<seriesInfo name="RFC" value="9588"/>
<author fullname="Nathaniel McCallum" initials="N." surname="McCallum"> <author fullname="Nathaniel McCallum" initials="N." surname="McCallum">
<organization>Red Hat, Inc.</organization> <organization>Red Hat, Inc.</organization>
<address><email>nathaniel@mccallum.life</email></address> <address><email>nathaniel@mccallum.life</email></address>
</author> </author>
<author fullname="Simo Sorce" initials="S." surname="Sorce"> <author fullname="Simo Sorce" initials="S." surname="Sorce">
<organization>Red Hat, Inc.</organization> <organization>Red Hat, Inc.</organization>
<address><email>ssorce@redhat.com</email></address> <address><email>ssorce@redhat.com</email></address>
</author> </author>
<author fullname="Robbie Harwood" initials="R." surname="Harwood"> <author fullname="Robbie Harwood" initials="R." surname="Harwood">
<organization>Red Hat, Inc.</organization> <organization>Red Hat, Inc.</organization>
<address><email>rharwood@pm.me</email></address> <address><email>rharwood@pm.me</email></address>
</author> </author>
<author fullname="Greg Hudson" initials="G." surname="Hudson"> <author fullname="Greg Hudson" initials="G." surname="Hudson">
<organization>MIT</organization> <organization>MIT</organization>
<address><email>ghudson@mit.edu</email></address> <address><email>ghudson@mit.edu</email></address>
</author> </author>
<date day="08" month="February" year="2024" /> <date month="August" year="2024"/>
<area>Security</area> <area>SEC</area>
<workgroup>kitten</workgroup>
<workgroup>Internet Engineering Task Force</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t>This document defines a new pre-authentication mechanism for <t>This document defines a new pre-authentication mechanism for
the Kerberos protocol. The mechanism uses a the Kerberos protocol. The mechanism uses a
password-authenticated key exchange to prevent brute-force password-authenticated key exchange (PAKE) to prevent brute-force
password attacks, and may optionally incorporate a second factor. password attacks, and it may incorporate a second factor.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section><name>Introduction</name> <section><name>Introduction</name>
<t>The Kerberos protocol <xref target="RFC4120"/> commonly uses <t>The Kerberos protocol <xref target="RFC4120"/> commonly uses
password-derived long-term keys to secure the initial authentication password-derived long-term keys to secure the initial authentication
exchange between a Kerberos client and a Key Distribution Center (KDC). exchange between a Kerberos client and a Key Distribution Center (KDC).
As noted in Section 10 of <xref target="RFC4120"/>, an attacker can As noted in <xref target="RFC4120" section="10" sectionFormat="of"/>, an a
perform an offline dictionary attack against the password, either by ttacker can
perform an offline dictionary attack against the password; this is perform
ed either by
initiating an authentication exchange to a principal for which the KDC initiating an authentication exchange to a principal for which the KDC
does not require pre-authentication, or after eavesdropping on a does not require pre-authentication or after eavesdropping on a
legitimate authentication exchange that uses encrypted timestamp legitimate authentication exchange that uses encrypted timestamp
pre-authentication (Section 5.2.7.2 of <xref target="RFC4120"/>).</t> pre-authentication (<xref target="RFC4120" section="5.2.7.2" sectionFormat ="of"/>).</t>
<t>This document defines a pre-authentication mechanism that <t>This document defines a pre-authentication mechanism that
authenticates using long-term keys but is resistant to offline dictionary authenticates using long-term keys but is resistant to offline dictionary
attacks. The mechanism additionally enables the use of second factor attacks. The mechanism additionally enables the use of second-factor
authentication without the need for a separately-established secure authentication without the need for a separately established secure
channel, by leveraging the trust relationship established by the shared channel, by leveraging the trust relationship established by the shared
long-term key.</t> long-term key.</t>
<section><name>Properties of PAKE</name> <section><name>Properties of PAKE</name>
<t>Password authenticated key exchange (PAKE) algorithms <xref <t>Password-authenticated key exchange (PAKE) algorithms <xref
target="RFC8125"/> provide several properties which defend against target="RFC8125"/> provide several properties that defend against
offline dictionary attacks and make them ideal for use in a Kerberos offline dictionary attacks and make them ideal for use in a Kerberos
pre-authentication mechanism. pre-authentication mechanism.
</t> </t>
<ol> <ol>
<li>Each side of the exchange contributes entropy.</li> <li>Each side of the exchange contributes entropy.</li>
<li>Passive attackers cannot determine the shared key.</li> <li>Passive attackers cannot determine the shared key.</li>
<li>Active attackers cannot perform a machine-in-the-middle <li>Active attackers cannot perform a machine-in-the-middle
attack.</li> attack.</li>
</ol> </ol>
<t>These properties of PAKE allow us to establish high-entropy <t>These properties of PAKE allow us to establish high-entropy
encryption keys resistant to offline brute force attack, even when encryption keys resistant to offline brute-force attacks, even when
the passwords used are weak (low-entropy).</t> the passwords used are weak (low entropy).</t>
</section> </section>
<section><name>PAKE Algorithm Selection</name> <section><name>PAKE Algorithm Selection</name>
<t>The SPAKE algorithm (defined in <xref target="SPAKE"/>) works by <t>The SPAKE algorithm (defined in <xref target="SPAKE"/>) works by
encrypting the public keys of a Diffie-Hellman key exchange with a encrypting the public keys of a Diffie-Hellman (DH) key exchange with a
shared secret. SPAKE is selected for this pre-authentication mechanism shared secret. SPAKE is selected for this pre-authentication mechanism
for the following properties: for the following properties:
</t> </t>
<ol> <ol>
<li>Because SPAKE's encryption method ensures that the result is a <li>SPAKE's encryption method ensures that the result is a
member of the underlying group, it can be used with elliptic curve member of the underlying group, so it can be used with elliptic curve
cryptography, which is believed to provide equivalent security levels cryptography, which is believed to provide equivalent security levels
to finite-field DH key exchange at much smaller key sizes.</li> to finite-field DH key exchange at much smaller key sizes.</li>
<li>It can compute the shared key after just one message from each <li>It can compute the shared key after just one message from each
party, minimizing the need for additional round trips and state.</li> party, minimizing the need for additional round trips and state.</li>
<li>It requires a small number of group operations, and can therefore <li>It requires a small number of group operations; therefore, it can
be implemented simply and efficiently.</li> be implemented simply and efficiently.</li>
</ol> </ol>
</section> </section>
<section><name>PAKE and Two-Factor Authentication</name> <section><name>PAKE and Two-Factor Authentication</name>
<t>Using PAKE in a pre-authentication mechanism also has another <t>Using PAKE in a pre-authentication mechanism also has another
benefit when used as a component of two-factor authentication (2FA). benefit when used as a component of two-factor authentication (2FA).
2FA methods often require the secure transfer of plaintext material to 2FA methods often require the secure transfer of plaintext material to
the KDC for verification. This includes one-time passwords, the KDC for verification. This includes one-time passwords,
challenge/response signatures and biometric data. Encrypting this data challenge/response signatures, and biometric data. Encrypting this data
using the long-term secret results in packets that are vulnerable to using the long-term secret results in packets that are vulnerable to
offline brute-force attack on the password, using either an offline brute-force attacks on the password, using either an
authentication tag or statistical properties of the 2FA credentials to authentication tag or statistical properties of the 2FA credentials to
determine whether a password guess is correct.</t> determine whether a password guess is correct.</t>
<t>In the One-Time Password pre-authentication <xref target="RFC6560"/> <t>In "One-Time Password (OTP) Pre-Authentication"
specification, this problem is mitigated by using flexible <xref target="RFC6560"/>, this problem is mitigated
authentication secure tunneling (FAST) (Section 5.4 of <xref using flexible authentication secure tunneling (FAST) (<xref
target="RFC6113"/>), which uses a secondary trust relationship to target="RFC6113" section="5.4" sectionFormat="of"/>), which uses a
create a secure encryption channel within which pre-authentication data secondary trust relationship to create a secure encryption channel
can be sent. However, the requirement for a secondary trust within which pre-authentication data can be sent. However, the
relationship has proven to be cumbersome to deploy and often introduces requirement for a secondary trust relationship has proven to be
third parties into the trust chain (such as certification cumbersome to deploy and often introduces third parties into the trust
authorities). These requirements make it difficult to enable FAST chain (such as certification authorities). These requirements make it
without manual configuration of client hosts. SPAKE pre-authentication, difficult to enable FAST without manual configuration of client
in contrast, can create a secure encryption channel implicitly, using hosts. In contrast, SPAKE pre-authentication, can create a secure
the key exchange to negotiate a high-entropy encryption key. This key encryption channel implicitly, using the key exchange to negotiate a
can then be used to securely encrypt 2FA plaintext data without the high-entropy encryption key. This key can then be used to securely
need for a secondary trust relationship. Further, if the second factor encrypt 2FA plaintext data without the need for a secondary trust
verifiers are sent at the same time as the first factor verifier, and relationship. Further, if the second-factor verifiers are sent at the
the KDC is careful to prevent timing attacks, then an online same time as the first-factor verifier, and the KDC is careful to
brute-force attack cannot be used to attack the factors separately.</t> prevent timing attacks, then an online brute-force attack cannot be
used to attack the factors separately.</t>
<t>For these reasons, this document departs from the advice given in <t>For these reasons, this document departs from the advice given in
Section 1 of <xref target="RFC6113">RFC 6113</xref> which states that <xref target="RFC6113" section="1" sectionFormat="of"/>, which states:
"Mechanism designers should design FAST factors, instead of new "Mechanism designers should design FAST factors, instead of new
pre-authentication mechanisms outside of FAST." However, the SPAKE pre-authentication mechanisms outside of FAST." However, the SPAKE
pre-authentication mechanism does not intend to replace FAST, and may pre-authentication mechanism does not intend to replace FAST and may
be used with it to further conceal the metadata of the Kerberos be used with it to further conceal the metadata of the Kerberos
messages.</t> messages.</t>
</section> </section>
<section><name>SPAKE Overview</name> <section><name>SPAKE Overview</name>
<t>The SPAKE algorithm can be broadly described in a series of four <t>The SPAKE algorithm can be broadly described in a series of four
steps:</t> steps:</t>
<ol> <ol>
<li>Calculation and exchange of the public key</li> <li>Calculation and exchange of the public key</li>
<li>Calculation of the shared secret (K)</li> <li>Calculation of the shared secret (K)</li>
<li>Derivation of an encryption key (K')</li> <li>Derivation of an encryption key (K')</li>
<li>Verification of the derived encryption key (K')</li> <li>Verification of the derived encryption key (K')</li>
</ol> </ol>
<t>In this mechanism, key verification happens implicitly by a <t>In this mechanism, key verification happens implicitly by a
successful decryption of the 2FA data, or of a placeholder value when successful decryption of the 2FA data or of a placeholder value when
no second factor is required. This mechanism uses a tailored method of no second factor is required. This mechanism uses a tailored method of
deriving encryption keys from the calculated shared secret K, for deriving encryption keys from the calculated shared secret K, for
several reasons: to fit within the framework of <xref several reasons:</t>
target="RFC3961"/>, to ensure negotiation integrity using a transcript <ul>
hash, to derive different keys for each use, and to bind the <li>to fit within the framework of <xref
KDC-REQ-BODY to the pre-authentication exchange.</t> target="RFC3961"/>,</li>
<li>to ensure negotiation integrity using a transcript
hash,</li>
<li>to derive different keys for each use, and</li>
<li>to bind the KDC-REQ-BODY to the pre-authentication exchange.</li>
</ul>
</section> </section>
</section> </section>
<section anchor="conventions"><name>Document Conventions</name> <section anchor="conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Document Conventions</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
they appear in all capitals, as shown here.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document refers to numerous terms and protocol messages defined <t>This document refers to numerous terms and protocol messages defined
in <xref target="RFC4120"/>.</t> in <xref target="RFC4120"/>.</t>
<t>The terms "encryption type", "key generation seed length", and <t>The terms "encryption type", "key generation seed length", and
"random-to-key" are defined in <xref target="RFC3961"/>.</t> "random-to-key" are defined in <xref target="RFC3961"/>.</t>
<t>The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", <t>The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED",
"KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED",
"pre-authentication facility", and "authentication set" are defined in "pre-authentication facility", and "authentication set" are defined in
<xref target="RFC6113"/>.</t> <xref target="RFC6113"/>.</t>
<t>The <xref target="SPAKE"/> paper defines SPAKE as a family of two key <t><xref target="SPAKE"/> defines SPAKE as a family of two key-exchange al
exchange algorithms differing only in derivation of the final key. This gorithms differing only in derivation of the final key. This
mechanism uses a derivation similar to the second algorithm (SPAKE2). For mechanism uses a derivation similar to the second algorithm (SPAKE2). For
simplicity, this document refers to the algorithm as "SPAKE".</t> simplicity, this document refers to the algorithm as "SPAKE".</t>
<t>The terms "ASN.1" and "DER" are defined in <xref <t>The terms "Abstract Syntax Notation One (ASN.1)" and "Distinguished Enc
target="CCITT.X680.2002"/> and <xref target="CCITT.X690.2002"/> oding Rules (DER)" are defined in <xref
target="ITU-T.X680.2021"/> and <xref target="ITU-T.X690.2021"/>,
respectively.</t> respectively.</t>
<t>When discussing operations within algebraic groups, this document uses <t>When discussing operations within algebraic groups, this document
additive notation (as described in Section 2.2 of <xref uses additive notation (as described in <xref target="RFC6090"
target="RFC6090"/>). Group elements are denoted with uppercase letters, section="2.2" sectionFormat="of"/>). Group elements are denoted with
while scalar multiplier values are denoted with lowercase letters.</t> uppercase letters, while scalar multiplier values are denoted with
lowercase letters.</t>
</section> </section>
<section><name>Prerequisites</name> <section><name>Prerequisites</name>
<section><name>PA-ETYPE-INFO2</name> <section><name>PA-ETYPE-INFO2</name>
<t>This mechanism requires the initial KDC pre-authentication state to <t>This mechanism requires the initial KDC pre-authentication state to
contain a singular reply key. Therefore, a KDC which offers SPAKE contain a singular reply key. Therefore, a KDC that offers SPAKE
pre-authentication as a stand-alone mechanism MUST supply a pre-authentication as a stand-alone mechanism <bcp14>MUST</bcp14>
PA-ETYPE-INFO2 value containing a single ETYPE-INFO2-ENTRY, following supply a PA-ETYPE-INFO2 value containing a single ETYPE-INFO2-ENTRY,
the guidance in Section 2.1 of <xref target="RFC6113"/>. PA-ETYPE-INFO2 following the guidance in <xref target="RFC6113" section="2.1"
is specified in Section 5.2.7.5 of <xref target="RFC4120"/>.</t> sectionFormat="of"/>. PA-ETYPE-INFO2 is specified in <xref
target="RFC4120" section="5.2.7.5" sectionFormat="of"/>.</t>
</section> </section>
<section><name>Cookie Support</name> <section><name>Cookie Support</name>
<t>KDCs which implement SPAKE pre-authentication MUST have some secure <t>KDCs that implement SPAKE pre-authentication <bcp14>MUST</bcp14>
mechanism for retaining state between AS-REQs. For stateless KDC have some secure mechanism for retaining state between authentication se
implementations, this method will most commonly be an encrypted rvice requests (AS-REQs). For
PA-FX-COOKIE. Clients which implement SPAKE pre-authentication MUST stateless KDC implementations, this method will most commonly be an
support PA-FX-COOKIE, as described in Section 5.2 of <xref encrypted PA-FX-COOKIE. Clients that implement SPAKE
target="RFC6113"/>.</t> pre-authentication <bcp14>MUST</bcp14> support PA-FX-COOKIE, as
described in <xref target="RFC6113" section="5.2"
sectionFormat="of"/>.</t>
</section> </section>
<section><name>More Pre-Authentication Data Required</name> <section><name>More Pre-authentication Data Required</name>
<t>Both KDCs and clients which implement SPAKE pre-authentication MUST <t>Both KDCs and clients that implement SPAKE pre-authentication <bcp14>
MUST</bcp14>
support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described in support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described in
Section 5.2 of <xref target="RFC6113"/>.</t> <xref target="RFC6113" section="5.2" sectionFormat="of"/>.</t>
</section> </section>
</section> </section>
<section><name>SPAKE Pre-Authentication Message Protocol</name> <section><name>SPAKE Pre-authentication Message Protocol</name>
<t>This mechanism uses the reply key and provides the Client <t>This mechanism uses the reply key and provides the client
Authentication and Strengthening Reply Key pre-authentication facilities authentication and strengthening reply key pre-authentication facilities
(Section 3 of <xref target="RFC6113"/>). When the mechanism completes (<xref target="RFC6113" section="3" sectionFormat="of"/>). When the mechan
ism completes
successfully, the client will have proved knowledge of the original successfully, the client will have proved knowledge of the original
reply key and possibly a second factor, and the reply key will be reply key and possibly a second factor, and the reply key will be
strengthened to a more uniform distribution based on the PAKE strengthened to a more uniform distribution based on the PAKE
exchange. This mechanism also ensures the integrity of the KDC-REQ-BODY exchange. This mechanism also ensures the integrity of the KDC-REQ-BODY
contents. This mechanism can be used in an authentication set; no contents. This mechanism can be used in an authentication set; no
pa-hint value is required or defined.</t> pa-hint value is required or defined.</t>
<t>This mechanism negotiates a choice of group for the SPAKE algorithm. <t>This mechanism negotiates a choice of group for the SPAKE algorithm.
Groups are defined in the IANA "Kerberos SPAKE Groups" registry created Groups are defined in the "Kerberos SPAKE Groups" registry created
by this document. Each group definition specifies an associated hash by this document (see <xref target="SPAKE-Groups"/>). Each group definitio
n specifies an associated hash
function, which will be used for transcript protection and key function, which will be used for transcript protection and key
derivation. Clients and KDCs MUST implement the edwards25519 group, but derivation. Clients and KDCs <bcp14>MUST</bcp14> implement the edwards2551
MAY choose not to offer or accept it by default.</t> 9 group, but they
<bcp14>MAY</bcp14> choose not to offer or accept it by default.</t>
<t>This section will describe the flow of messages when performing SPAKE <t>The subsections that follow will describe the flow of messages when per forming SPAKE
pre-authentication. We will begin by explaining the most verbose version pre-authentication. We will begin by explaining the most verbose version
of the protocol which all implementations MUST support. Then we will of the protocol, which all implementations <bcp14>MUST</bcp14> support. Th
describe several optional optimizations to reduce round-trips.</t> en, we will
describe several optional optimizations to reduce round trips.</t>
<t>Mechanism messages are communicated using PA-DATA elements within the <t>Mechanism messages are communicated using PA-DATA elements within the
padata field of KDC-REQ messages or within the METHOD-DATA in the e-data padata field of KDC-REQ messages or within the METHOD-DATA in the e-data
field of KRB-ERROR messages. All PA-DATA elements for this mechanism field of KRB-ERROR messages. All PA-DATA elements for this mechanism
MUST use the following padata-type: <bcp14>MUST</bcp14> use the following padata-type:
</t> </t>
<dl><dt>PA-SPAKE</dt><dd>151</dd></dl> <dl><dt>PA-SPAKE</dt><dd>151</dd></dl>
<t> <t>
The padata-value for all PA-SPAKE PA-DATA values MUST be empty or The padata-value for all PA-SPAKE PA-DATA values <bcp14>MUST</bcp14> be em pty or
contain a DER encoding for the ASN.1 type PA-SPAKE.</t> contain a DER encoding for the ASN.1 type PA-SPAKE.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
PA-SPAKE ::= CHOICE { PA-SPAKE ::= CHOICE {
support [0] SPAKESupport, support [0] SPAKESupport,
challenge [1] SPAKEChallenge, challenge [1] SPAKEChallenge,
response [2] SPAKEResponse, response [2] SPAKEResponse,
encdata [3] EncryptedData, encdata [3] EncryptedData,
... ...
} }
]]></sourcecode> ]]></sourcecode>
<section><name>First Pass</name> <section><name>First Pass</name>
<t>The SPAKE pre-authentication exchange begins when the client sends <t>The SPAKE pre-authentication exchange begins when the client sends
an initial authentication service request (AS-REQ) without an initial authentication service request (AS-REQ) without
pre-authentication data. Upon receipt of this AS-REQ, a KDC which pre-authentication data. Upon receipt of this AS-REQ, a KDC that
requires pre-authentication and supports SPAKE SHOULD (unless requires pre-authentication and supports SPAKE <bcp14>SHOULD</bcp14>
configuration indicates otherwise) reply with a (unless configuration indicates otherwise) reply with a
KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty
PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA
elements). This message indicates to the client that the KDC supports elements). This message indicates to the client that the KDC supports
SPAKE pre-authentication.</t> SPAKE pre-authentication.</t>
</section> </section>
<section><name>Second Pass</name> <section><name>Second Pass</name>
<t>Once the client knows that the KDC supports SPAKE pre-authentication <t>Once the client knows that the KDC supports SPAKE pre-authentication
and the client desires to use it, the client will generate a new and the client wants to use it, the client will generate a new
AS-REQ message containing a PA-SPAKE PA-DATA element using the support AS-REQ message containing a PA-SPAKE PA-DATA element using the support
choice. This message indicates to the KDC which groups the client choice. This message indicates to the KDC which groups the client
prefers for the SPAKE operation. The group numbers are defined in the IA prefers for the SPAKE operation. The group numbers are defined in the
NA "Kerberos SPAKE Groups" registry (see <xref target="SPAKE-Groups"/>). Th
"Kerberos SPAKE Groups" registry created by this document. The groups e group's
sequence is ordered from the most preferred group to the least preferred sequence is ordered from the most preferred group to the least preferred
group.</t> group.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
SPAKESupport ::= SEQUENCE { SPAKESupport ::= SEQUENCE {
groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
... ...
} }
]]></sourcecode> ]]></sourcecode>
<t>Upon receipt of the support message, the KDC will select a <t>Upon receipt of the support message, the KDC will select a
group. The KDC SHOULD choose a group from the groups provided by the group. The KDC <bcp14>SHOULD</bcp14> choose a group from the groups prov ided by the
support message. However, if the support message does not contain any support message. However, if the support message does not contain any
group that is supported by the KDC, the KDC MAY select another group in group that is supported by the KDC, the KDC <bcp14>MAY</bcp14> select an
hopes that the client might support it. Otherwise, the KDC MUST respond other group in
hopes that the client might support it. Otherwise, the KDC <bcp14>MUST</
bcp14> respond
with a KDC_ERR_PREAUTH_FAILED error.</t> with a KDC_ERR_PREAUTH_FAILED error.</t>
<t>The group selection determines the group order, which shall be a <t>The group selection determines the group order, which shall be a
large prime p multiplied by a small cofactor h (possibly 1), as well as large prime p multiplied by a small cofactor h (possibly 1),
a generator P of a prime-order subgroup and two masking points M and a generator P of a prime-order subgroup, and two masking points M and
N. The KDC selects a random integer x in the range 0 &lt;= x &lt; h*p, N. The KDC selects a random integer x in the range 0 &lt;= x &lt; h*p,
which MUST be divisible by h. The KDC computes a public key T=x*P+w*M, which <bcp14>MUST</bcp14> be divisible by h. The KDC computes a public k ey T=x*P+w*M,
where w is computed from the initial reply key according to <xref target ="spakeparams"/>.</t> where w is computed from the initial reply key according to <xref target ="spakeparams"/>.</t>
<t>The KDC will reply to the client with a <t>The KDC will reply to the client with a
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-DATA KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-DATA
element using the challenge choice.</t> element using the challenge choice.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
SPAKEChallenge ::= SEQUENCE { SPAKEChallenge ::= SEQUENCE {
group [0] Int32, group [0] Int32,
pubkey [1] OCTET STRING, pubkey [1] OCTET STRING,
factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor,
... ...
} }
]]></sourcecode> ]]></sourcecode>
<t>The group field indicates the KDC-selected group used for all SPAKE <t>The group field indicates the KDC-selected group
calculations as defined in the IANA "Kerberos SPAKE Groups" registry used for all SPAKE calculations as defined in the "Kerberos SPAKE
created by this document.</t> Groups" registry (see <xref target="SPAKE-Groups"/>).</t>
<t>The pubkey field indicates the KDC's public key T, serialized <t>The pubkey field indicates the KDC's public key T, serialized
according to <xref target="spakeparams"/>.</t> according to <xref target="spakeparams"/>.</t>
<t>The factors field contains an unordered list of second factors which <t>The factors field contains an unordered list of second factors,
can be used to complete the authentication. Each second factor is which can be used to complete the authentication. Each second factor
represented by a SPAKESecondFactor.</t> is represented by a SPAKESecondFactor.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
SPAKESecondFactor ::= SEQUENCE { SPAKESecondFactor ::= SEQUENCE {
type [0] Int32, type [0] Int32,
data [1] OCTET STRING OPTIONAL data [1] OCTET STRING OPTIONAL
} }
]]></sourcecode> ]]></sourcecode>
<t>The type field is a unique integer which identifies the second factor <t>The type field is a unique integer that identifies the second-factor
type. The factors field of SPAKEChallenge MUST NOT contain more than one type. The factors field of SPAKEChallenge <bcp14>MUST
SPAKESecondFactor with the same type value.</t> NOT</bcp14> contain more than one SPAKESecondFactor with the same type
value.</t>
<t>The data field contains optional challenge data. The contents in <t>The data field contains optional challenge data. The contents in
this field will depend upon the second factor type chosen. Note that this field will depend upon the second-factor type chosen. Note that
this challenge is initially transmitted as unauthenticated plaintext; this challenge is initially transmitted as unauthenticated plaintext;
see <xref target="unauthtext"/>.</t> see <xref target="unauthtext"/>.</t>
<t>The client and KDC will each initialize a transcript hash (<xref <t>The client and KDC will each initialize a transcript hash (<xref
target="transcript"/>) using the hash function associated with the target="transcript"/>) using the hash function associated with the
chosen group, and update it with the concatenation of the DER-encoded chosen group and update it with the concatenation of the DER-encoded
PA-SPAKE messages sent by the client and the KDC.</t> PA-SPAKE messages sent by the client and the KDC.</t>
</section> </section>
<section><name>Third Pass</name> <section><name>Third Pass</name>
<t>Upon receipt of the challenge message, the client observes which <t>Upon receipt of the challenge message, the client observes which
group was selected by the KDC and deserializes the KDC's public key group was selected by the KDC and deserializes the KDC's public key
T. The client selects a random integer y in the range 0 &lt;= x &lt; T. The client selects a random integer y in the range 0 &lt;= x &lt;
h*p, which MUST be divisible by h. The client computes a public key h*p, which <bcp14>MUST</bcp14> be divisible by h. The client computes a public key
S=y*P+w*N, where w is computed from the initial reply key according to S=y*P+w*N, where w is computed from the initial reply key according to
<xref target="spakeparams"/>. The client computes a shared group <xref target="spakeparams"/>. The client computes a shared group
element K=y*(T-w*M).</t> element K=y*(T-w*M).</t>
<t>The client will then choose one of the second factor types listed in <t>The client will then choose one of the second-factor types listed in
the factors field of the challenge message and gather whatever data is the factors field of the challenge message and gather whatever data is
required for the chosen second factor type, possibly using the required for the chosen second-factor type, possibly using the
associated challenge data. Finally, the client will send an AS-REQ associated challenge data. Finally, the client will send an AS-REQ
containing a PA-SPAKE PA-DATA element using the response choice.</t> containing a PA-SPAKE PA-DATA element using the response choice.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
SPAKEResponse ::= SEQUENCE { SPAKEResponse ::= SEQUENCE {
pubkey [0] OCTET STRING, pubkey [0] OCTET STRING,
factor [1] EncryptedData, -- SPAKESecondFactor factor [1] EncryptedData, -- SPAKESecondFactor
... ...
} }
]]></sourcecode> ]]></sourcecode>
<t>The client and KDC will update the transcript hash with the pubkey <t>The client and KDC will update the transcript hash with the pubkey
value, and use the resulting hash for all encryption key value and use the resulting hash for all encryption key
derivations.</t> derivations.</t>
<t>The pubkey field indicates the client's public key S, serialized <t>The pubkey field indicates the client's public key S, serialized
according to <xref target="spakeparams"/>.</t> according to <xref target="spakeparams"/>.</t>
<t>The factor field indicates the client's chosen second factor data. <t>The factor field indicates the client's chosen second-factor data.
The key for this field is K'[1] as specified in <xref The key for this field is K'[1] (specified in <xref
target="keyderiv"/>. The kvno field of the EncryptedData sequence is target="keyderiv"/>). The kvno field of the EncryptedData sequence is
omitted. The key usage number for the encryption is omitted. The key usage number for the encryption is
KEY_USAGE_SPAKE. The plain text inside the EncryptedData is an encoding KEY_USAGE_SPAKE. The plaintext inside the EncryptedData is an encoding
of SPAKESecondFactor. Once decoded, the SPAKESecondFactor contains the of the SPAKESecondFactor. Once decoded, the SPAKESecondFactor provides t
he
type of the second factor and any optional data used. The contents of type of the second factor and any optional data used. The contents of
the data field will depend on the second factor type chosen. The client the data field will depend on the second-factor type chosen. The client
MUST NOT send a response containing a second factor type which was not <bcp14>MUST NOT</bcp14> send a response containing a second-factor type
that was not
listed in the factors field of the challenge message.</t> listed in the factors field of the challenge message.</t>
<t>When the KDC receives the response message from the client, it <t>When the KDC receives the response message from the client, it
deserializes the client's public key S, and computes the shared group deserializes the client's public key S, and computes the shared group
element K=x*(S-w*N). The KDC derives K'[1] and decrypts the factors element K=x*(S-w*N). The KDC derives K'[1] and decrypts the factors
field. If decryption is successful, the first factor is successfully field. If decryption is successful, the first factor is successfully
validated. The KDC then validates the second factor. If either factor validated. The KDC then validates the second factor. If either factor
fails to validate, the KDC MUST respond with a KDC_ERR_PREAUTH_FAILED fails to validate, the KDC <bcp14>MUST</bcp14> respond with a KDC_ERR_PR EAUTH_FAILED
error.</t> error.</t>
<t>If validation of the second factor requires further round-trips, the <t>If validation of the second factor requires further round trips, the
KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED KDC <bcp14>MUST</bcp14> reply to the client with a KDC_ERR_MORE_PREAUTH_
DATA_REQUIRED error
containing a PA-SPAKE PA-DATA element using the encdata choice. The containing a PA-SPAKE PA-DATA element using the encdata choice. The
kvno field of the EncryptedData sequence is omitted. The key for the kvno field of the EncryptedData sequence is omitted. The key for the
EncryptedData value is K'[2] as specified in <xref target="keyderiv"/>, EncryptedData value is K'[2] (specified in <xref target="keyderiv"/>),
and the key usage number is KEY_USAGE_SPAKE. The plain text of this and the key usage number is KEY_USAGE_SPAKE. The plaintext of this
message contains a DER-encoded SPAKESecondFactor message. As before, message contains a DER-encoded SPAKESecondFactor message. As before,
the type field of this message will contain the second factor type, and the type field of this message will contain the second-factor type and
the data field will optionally contain second factor type specific the data field will, optionally, contain data specific to the second-fac
data.</t> tor type.</t>
</section> </section>
<section><name>Subsequent Passes</name> <section><name>Subsequent Passes</name>
<t>Any number of additional round trips may occur using the encdata <t>Any number of additional round trips may occur using the encdata
choice. The contents of the plaintexts are specific to the second choice. The contents of the plaintexts are specific to the second-factor
factor type. If a client receives a PA-SPAKE PA-DATA element using the type.
encdata choice from the KDC, it MUST reply with a subsequent AS-REQ
with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS If a client receives a PA-SPAKE PA-DATA element using the
encdata choice from the KDC, it <bcp14>MUST</bcp14> reply with a subsequ
ent AS-REQ
with a PA-SPAKE PA-DATA element using the encdata choice or abort the AS
exchange.</t> exchange.</t>
<t>The key for client-originated encdata messages in subsequent passes <t>The key for client-originated encdata messages in subsequent passes
is K'[3] as specified in <xref target="keyderiv"/> for the first is K'[3] (specified in <xref target="keyderiv"/>) for the first
subsequent pass, K'[5] for the second, and so on. The key for subsequent pass, K'[5] for the second, and so on. The key for
KDC-originated encdata messages is K'[4] for the first subsequent KDC-originated encdata messages is K'[4] for the first subsequent
pass, K'[6] for the second, and so on.</t> pass, K'[6] for the second, and so on.</t>
</section> </section>
<section><name>Reply Key Strengthening</name> <section><name>Reply Key Strengthening</name>
<t>When the KDC has successfully validated both factors, the reply key <t>When the KDC has successfully validated both factors, the reply key
is strengthened and the mechanism is complete. To strengthen the reply is strengthened and the mechanism is complete. The strengthening of
key, the client and KDC replace it with K'[0] as specified in <xref the reply key is accomplished by the client and KDC replacing it with
target="keyderiv"/>. The KDC then replies with a KDC-REP message, or K'[0] (as specified in <xref target="keyderiv"/>). The KDC then replies
continues on to the next mechanism in the authentication set. There is with a KDC-REP message or continues on to the next mechanism in the
no final PA-SPAKE PA-DATA message from the KDC to the client.</t> authentication set. There is no final PA-SPAKE PA-DATA message from
<t>Reply key strengthening occurs only once at the end of the the KDC to the client.</t>
exchange. The client and KDC MUST use the initial reply key as the
<t>Reply key strengthening occurs only once: at the end of the exchange.
The client and KDC <bcp14>MUST</bcp14> use the initial reply key as the
base key for all K'[n] derivations.</t> base key for all K'[n] derivations.</t>
</section> </section>
<section anchor="optimizations"><name>Optimizations</name> <section anchor="optimizations"><name>Optimizations</name>
<t>The full protocol has two possible optimizations.</t> <t>The full protocol has two possible optimizations.</t>
<t>First, the KDC MAY reply to the initial AS-REQ (containing no <t>First, the KDC <bcp14>MAY</bcp14> reply to the initial AS-REQ (contai ning no
pre-authentication data) with a PA-SPAKE PA-DATA element using the pre-authentication data) with a PA-SPAKE PA-DATA element using the
challenge choice, instead of an empty padata-value. In this case, the challenge choice instead of an empty padata-value. In this case, the
KDC optimistically selects a group which the client may not KDC optimistically selects a group that the client may not
support. If the group chosen by the challenge message is supported by support. If the group chosen by the challenge message is supported by
the client, the client MUST skip to the third pass by issuing an the client, the client <bcp14>MUST</bcp14> skip to the third pass by iss
AS-REQ with a PA-SPAKE message using the response choice. In this case uing an
AS-REQ with a PA-SPAKE message using the response choice. In this case,
no SPAKESupport message is sent by the client, so the first update to no SPAKESupport message is sent by the client, so the first update to
the transcript hash contains only the KDC's optimistic challenge. If the transcript hash contains only the KDC's optimistic challenge. If
the KDC's chosen group is not supported by the client, the client MUST the KDC's chosen group is not supported by the client, the client <bcp14
continue to the second pass. In this case both the client and KDC MUST >MUST</bcp14>
continue to the second pass. In this case, both the client and KDC <bcp1
4>MUST</bcp14>
reinitialize the transcript hash for the client's support message. reinitialize the transcript hash for the client's support message.
Clients MUST support this optimization.</t> Clients <bcp14>MUST</bcp14> support this optimization.</t>
<t>Second, clients MAY skip the first pass and send an AS-REQ with a <t>Second, clients <bcp14>MAY</bcp14> skip the first pass and send an AS -REQ with a
PA-SPAKE PA-DATA element using the support choice. If the KDC accepts PA-SPAKE PA-DATA element using the support choice. If the KDC accepts
the support message and generates a challenge, it MUST include a the support message and generates a challenge, it <bcp14>MUST</bcp14> in clude a
PA-ETYPE-INFO2 value within the METHOD-DATA of the PA-ETYPE-INFO2 value within the METHOD-DATA of the
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may
not otherwise be able to compute the initial reply key. If the KDC not otherwise be able to compute the initial reply key. If the KDC
cannot continue with SPAKE (either because initial reply key type is cannot continue with SPAKE (either because the initial reply key type is
incompatible with SPAKE or because it does not support any of the incompatible with SPAKE or because it does not support any of the
client's groups) but can offer other pre-authentication mechanisms, it client's groups) but can offer other pre-authentication mechanisms, the
MUST respond with a KDC_ERR_PREAUTH_FAILED error containing METHOD-DATA KDC
<bcp14>MUST</bcp14> respond with a KDC_ERR_PREAUTH_FAILED error containi
ng METHOD-DATA
for the available mechanisms. A client supporting this optimization for the available mechanisms. A client supporting this optimization
MUST continue after a KDC_ERR_PREAUTH_FAILED error as described in <bcp14>MUST</bcp14> continue after a KDC_ERR_PREAUTH_FAILED error as des
Section 2 of <xref target="RFC6113"/>. KDCs MUST support this cribed in
<xref target="RFC6113" section="2" sectionFormat="of"/>. KDCs <bcp14>MUS
T</bcp14> support this
optimization.</t> optimization.</t>
</section> </section>
</section> </section>
<section anchor="spakeparams"><name>SPAKE Parameters and Conversions</name> <section anchor="spakeparams"><name>SPAKE Parameters and Conversions</name>
<t>Group elements are converted to and from octet strings using the <t>Group elements are converted to and from octet strings using the
serialization method defined in the IANA "Kerberos SPAKE Groups" registry serialization method defined in the "Kerberos SPAKE Groups" registry
created by this document.</t> (see <xref target="SPAKE-Groups"/>).</t>
<t>The SPAKE algorithm requires constants M and N for each group. These <t>The SPAKE algorithm requires constants M and N for each group. These
constants are defined in the IANA "Kerberos SPAKE Groups" registry constants are defined in the "Kerberos SPAKE Groups" registry
created by this document.</t> (see <xref target="SPAKE-Groups"/>).</t>
<t>The SPAKE algorithm requires a shared secret input w to be used as a <t>The SPAKE algorithm requires a shared secret input w to be used as a
scalar multiplier. This value MUST be produced from the initial reply key scalar multiplier. This value <bcp14>MUST</bcp14> be produced from the ini tial reply key
as follows: as follows:
</t> </t>
<ol> <ol>
<li>Determine the length of the multiplier octet string as defined in <li>Determine the length of the multiplier octet string as defined in
the IANA "Kerberos SPAKE Groups" registry created by this the "Kerberos SPAKE Groups" registry (see <xref target="SPAKE-Groups"/>)
document.</li> .</li>
<li>Compose a pepper string by concatenating the string "SPAKEsecret" <li>Compose a pepper string by concatenating the string "SPAKEsecret"
and the group number as a big-endian four-byte two's complement binary and the group number as a big-endian four-byte two's complement binary
number.</li> number.</li>
<li>Produce an octet string of the required length using PRF+(K, <li>Produce an octet string of the required length using PRF+(K,
pepper), where K is the initial reply key and PRF+ is defined in pepper), where K is the initial reply key and PRF+ is as defined in
Section 5.1 of <xref target="RFC6113"/>.</li> <xref target="RFC6113" section="5.1" sectionFormat="of"/>.</li>
<li>Convert the octet string to a multiplier scalar using the <li>Convert the octet string to a multiplier scalar using the
multiplier conversion method defined in the IANA "Kerberos SPAKE multiplier conversion method defined in the "Kerberos SPAKE
Groups" registry created by this document.</li> Groups" registry (see <xref target="SPAKE-Groups"/>).</li>
</ol> </ol>
<t>The KDC chooses a secret scalar value x and the client chooses a <t>The KDC chooses a secret scalar value x and the client chooses a
secret scalar value y. As required by the SPAKE algorithm, these values secret scalar value y. As required by the SPAKE algorithm, these values
are chosen randomly and uniformly. The KDC and client MUST NOT reuse x are chosen randomly and uniformly. The KDC and client <bcp14>MUST NOT</bcp 14> reuse x
or y values for authentications involving different initial reply or y values for authentications involving different initial reply
keys (see <xref target="kdcstate"/>).</t> keys (see <xref target="kdcstate"/>).</t>
</section> </section>
<section anchor="transcript"><name>Transcript Hash</name> <section anchor="transcript"><name>Transcript Hash</name>
<t>The transcript hash is an octet string of length equal to the output <t>The transcript hash is an octet string of length equal to the output
length of the hash function associated with the selected group. The length of the hash function associated with the selected group. All bits a
initial value consists of all bits set to zero.</t> re set to zero in the initial value.</t>
<t>When the transcript hash is updated with an octet string input, the <t>When the transcript hash is updated with an octet string input, the
new value is the hash function computed over the concatenation of the new value is the hash function computed over the concatenation of the
old value and the input.</t> old value and the input.</t>
<t>In the normal message flow or with the second optimization described <t>In the normal message flow or with the second optimization described
in <xref target="optimizations"/>, the transcript hash is first updated in <xref target="optimizations"/>, the transcript hash is:</t>
<ol><li>updated
with the concatenation of the client's support message and the KDC's with the concatenation of the client's support message and the KDC's
challenge, and then updated a second time with the client's pubkey challenge, then</li>
value. It therefore incorporates the client's supported groups, the <li>updated a second time with the client's pubkey
value.</li></ol>
<t>Therefore, it incorporates the client's supported groups, the
KDC's chosen group, the KDC's initial second-factor messages, and the KDC's chosen group, the KDC's initial second-factor messages, and the
client and KDC public values. Once the transcript hash is finalized, it client and KDC public values. Once the transcript hash is finalized, it
is used without change for all key derivations (<xref is used without change for all key derivations (<xref
target="keyderiv"/>). In particular, encrypted second-factor messages are target="keyderiv"/>). In particular, encrypted second-factor messages are
not included in the transcript hash.</t> not included in the transcript hash.</t>
<t>If the first optimization described in <xref target="optimizations"/> <t>If the first optimization described in <xref target="optimizations"/>
is used successfully, the transcript hash is updated first with the is used successfully, the transcript hash is first updated with the
KDC's challenge message, and second with the client's pubkey value.</t> KDC's challenge message and updated a second time with the client's pubkey
value.</t>
<t>If first optimization is used unsuccessfully (i.e. the client does <t>If the first optimization is used unsuccessfully (i.e., the client does
not accept the KDC's selected group), the transcript hash is computed as not accept the KDC's selected group), the transcript hash is computed as
in the normal message flow, without including the KDC's optimistic in the normal message flow, without including the KDC's optimistic
challenge.</t> challenge.</t>
</section> </section>
<section anchor="keyderiv"><name>Key Derivation</name> <section anchor="keyderiv"><name>Key Derivation</name>
<t>Implementations MUST NOT use the shared group element (denoted by K) <t>Implementations <bcp14>MUST NOT</bcp14> use the shared group element (d enoted by K)
directly for any cryptographic operation. Instead, the SPAKE result is directly for any cryptographic operation. Instead, the SPAKE result is
used to derive keys K'[n] as defined in this section.</t> used to derive keys K'[n] (defined in this section).</t>
<t>First, compute the hash function associated with the selected group <t>First, compute the hash function associated with the selected group
over the concatenation of the following values:</t> over the concatenation of the following values:</t>
<ul> <ul>
<li>The fixed string "SPAKEkey".</li> <li>The fixed string "SPAKEkey".</li>
<li>The group number as a big-endian four-byte two's complement binary <li>The group number as a big-endian four-byte two's complement binary
number.</li> number.</li>
<li>The encryption type of the initial reply key as a big-endian <li>The encryption type of the initial reply key as a big-endian
four-byte two's complement binary number.</li> four-byte two's complement binary number.</li>
<li>The PRF+ output used to compute the initial secret input w as <li>The PRF+ output used to compute the initial secret input w (as speci
specified in <xref target="spakeparams"/>.</li> fied in <xref target="spakeparams"/>).</li>
<li>The SPAKE result K, converted to an octet string as specified in <li>The SPAKE result K, converted to an octet string (as specified in
<xref target="spakeparams"/>.</li> <xref target="spakeparams"/>).</li>
<li>The transcript hash.</li> <li>The transcript hash.</li>
<li>The KDC-REQ-BODY encoding for the request being sent or responded <li>The KDC-REQ-BODY encoding for the request being sent or responded
to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST be to. Within a FAST channel, the inner KDC-REQ-BODY encoding <bcp14>MUST</ bcp14> be
used.</li> used.</li>
<li>The value n as a big-endian four-byte unsigned binary number.</li> <li>The value n as a big-endian, four-byte, and unsigned binary number.<
<li>A single-byte block counter, with the initial value 0x01.</li> /li>
<li>A single-byte block counter with the initial value 0x01.</li>
</ul> </ul>
<t> <t>
If the hash output is too small for the encryption type's key generation If the hash output is too small for the encryption type's key generation
seed length, the block counter value is incremented and the hash seed length, the block counter value is incremented and the hash
function re-computed to produce as many blocks as are required. The function is recomputed to produce as many blocks as are required. The
result is truncated to the key generation seed length, and the result is truncated to the key generation seed length, and the
random-to-key function is used to produce an intermediate key with the random-to-key function is used to produce an intermediate key with the
same encryption type as the initial reply key.</t> same encryption type as the initial reply key.</t>
<t>The key K'[n] has the same encryption type as the initial reply key, <t>The key K'[n] has the same encryption type as the initial reply key,
and has the value KRB-FX-CF2(initial-reply-key, intermediate-key, and has the value KRB-FX-CF2(initial-reply-key, intermediate-key,
"SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in Section 5.1 of <xref "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in <xref target="RFC6113
target="RFC6113"/>.</t> " section="5.1" sectionFormat="of"/>.</t>
</section> </section>
<section><name>Second Factor Types</name> <section><name>Second-Factor Types</name>
<t>This document defines one second factor type:</t> <t>This document defines one second-factor type:</t>
<dl><dt>SF-NONE</dt><dd>1</dd></dl> <dl><dt>SF-NONE</dt><dd>1</dd></dl>
<t>This second factor type indicates that no second factor is used. <t>This second-factor type indicates that no second factor is used.
Whenever a SPAKESecondFactor is used with SF-NONE, the data field MUST be Whenever a SPAKESecondFactor is used with SF-NONE, the data field <bcp14>M
UST</bcp14> be
omitted. The SF-NONE second factor always successfully validates.</t> omitted. The SF-NONE second factor always successfully validates.</t>
</section> </section>
<section><name>Hint for Authentication Sets</name> <section><name>Hint for Authentication Sets</name>
<t>If a KDC offers SPAKE pre-authentication as part of an authentication <t>If a KDC offers SPAKE pre-authentication as part of an authentication
set (Section 5.3 of <xref target="RFC6113"/>), it SHOULD provide a set (<xref target="RFC6113" section="5.3" sectionFormat="of"/>), it <bcp14 >SHOULD</bcp14> provide a
pa-hint value containing the DER encoding of the ASN.1 type pa-hint value containing the DER encoding of the ASN.1 type
PA-SPAKE-HINT, to help the client determine whether SPAKE PA-SPAKE-HINT. This helps the client determine whether SPAKE
pre-authentication is likely to succeed if the authentication set is pre-authentication is likely to succeed if the authentication set is
chosen.</t> chosen.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
PA-SPAKE-HINT ::= SEQUENCE { PA-SPAKE-HINT ::= SEQUENCE {
groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor
} }
]]></sourcecode> ]]></sourcecode>
<t>The groups field indicates the KDC's supported groups. The factors <t>The groups field indicates the KDC's supported groups. The factors
field indicates the KDC's supported second factors. The KDC MAY omit the field indicates the KDC's supported second factors. The KDC <bcp14>MAY</bc p14> omit the
data field of values in the factors list.</t> data field of values in the factors list.</t>
<t>A KDC MUST NOT include a PA-SPAKE-HINT message directly in a pa-value <t>A KDC <bcp14>MUST NOT</bcp14> include a PA-SPAKE-HINT message directly in a pa-value
field; hints must only be provided within authentication sets. A KDC field; hints must only be provided within authentication sets. A KDC
SHOULD include a hint if SPAKE pre-authentication is offered as the <bcp14>SHOULD</bcp14> include a hint if SPAKE pre-authentication is offere d as the
second or later element of an authentication set.</t> second or later element of an authentication set.</t>
<t>The PA-SPAKE-HINT message is not part of the transcript, and does not <t>The PA-SPAKE-HINT message is not part of the transcript, and it does no t
replace any part of the SPAKE message flow.</t> replace any part of the SPAKE message flow.</t>
</section> </section>
<section><name>Security Considerations</name> <section><name>Security Considerations</name>
<section><name>SPAKE Computations</name> <section><name>SPAKE Computations</name>
<t>The deserialized public keys S and T MUST be verified to be elements <t>The deserialized public keys S and T <bcp14>MUST</bcp14> be verified
of the group, to prevent invalid curve attacks. It is not necessary to to be elements
verify that they are members of the prime-order subgroup, as the of the group to prevent invalid curve attacks. It is not necessary to
verify that they are members of the prime-order subgroup; the
computation of K by both parties involves a multiplication by the computation of K by both parties involves a multiplication by the
cofactor h.</t> cofactor h.</t>
<t>The aforementioned cofactor multiplication is accomplished by <t>The aforementioned cofactor multiplication is accomplished by
choosing private scalars x and y which are divisible by the choosing private scalars x and y, which are divisible by the
cofactor. If the client or KDC chooses a scalar which might not be cofactor. If the client or KDC chooses a scalar that might not be
divisible by the cofactor, an attacker might be able to coerce values divisible by the cofactor, an attacker might be able to coerce values
of K which are not members of the prime-order subgroup, and deduce a of K that are not members of the prime-order subgroup and deduce a
limited amount of information about w from the order of K.</t> limited amount of information about w from the order of K.</t>
<t>The scalars x and y MUST be chosen uniformly, and must not be reused
<t>The scalars x and y <bcp14>MUST</bcp14> be chosen uniformly. They <bc
p14>MUST NOT</bcp14> be reused
for different initial reply keys. If an x or y value is reused for for different initial reply keys. If an x or y value is reused for
pre-authentications involving two different initial reply keys, an pre-authentications involving two different initial reply keys, an
attacker who observes both authentications and knows one of the initial attacker who observes both authentications and knows one of the initial
reply keys can conduct an offline dictionary attack to recover the reply keys can conduct an offline dictionary attack to recover the
other one.</t> other one.</t>
<t>The M and N values for a group MUST NOT have known discrete logs. An <t>The M and N values for a group <bcp14>MUST NOT</bcp14> have known dis crete logs. An
attacker who knows the discrete log of M or N can perform an offline attacker who knows the discrete log of M or N can perform an offline
dictionary attack on passwords. It is therefore important to dictionary attack on passwords. Therefore, it is important to
demonstrate that the M and N values for each group were computed demonstrate that the M and N values for each group were computed
without multiplying a known value by the generator P.</t> without multiplying a known value by the generator P.</t>
</section> </section>
<section anchor="unauthtext"><name>Unauthenticated Plaintext</name> <section anchor="unauthtext"><name>Unauthenticated Plaintext</name>
<t>This mechanism includes unauthenticated plaintext in the support and <t>This mechanism includes unauthenticated plaintext in the support and
challenge messages. Beginning with the third pass, the integrity of challenge messages. Beginning with the third pass, the integrity of
this plaintext is ensured by incorporating the transcript hash into this plaintext is ensured by incorporating the transcript hash into
the derivation of the final reply key and second factor encryption the derivation of the final reply key and second-factor encryption
keys. Downgrade attacks on support and challenge messages will result keys. Downgrade attacks on support and challenge messages will result
in the client and KDC deriving different reply keys and EncryptedData in the client and KDC deriving different reply keys and EncryptedData
keys. The KDC-REQ-BODY contents are also incorporated into key keys. The KDC-REQ-BODY contents are also incorporated into key
derivation, ensuring their integrity. The unauthenticated plaintext in derivation, ensuring their integrity. The unauthenticated plaintext in
the KDC-REP message is not protected by this mechanism.</t> the KDC-REP message is not protected by this mechanism.</t>
<t>Unless FAST is used, the factors field of a challenge message is not <t>Unless FAST is used, the factors field of a challenge message is not
integrity-protected until the response is verified. Second factor types integrity protected until the response is verified. Second-factor types
MUST account for this when specifying the semantics of the data <bcp14>MUST</bcp14> account for this when specifying the semantics of th
field. In particular, second factor data in the challenge should not be e data
included in user prompts, as it could be modified by an attacker to field. In particular, second-factor data in the challenge should not be
included in user prompts: it could be modified by an attacker to
contain misleading or offensive information.</t> contain misleading or offensive information.</t>
<t>Unless FAST is used, the factors field of a challenge message is <t>Unless FAST is used, the factors field of a challenge message is
visible to an attacker, who can use it to determine whether a second visible to an attacker, who can use it to determine whether a second
factor is required for the client.</t> factor is required for the client.</t>
<t>Subsequent factor data, including the data in the response, are <t>Subsequent factor data, including the data in the response, are
encrypted in a derivative of the shared secret K. Therefore, it is not encrypted in a derivative of the shared secret K. Therefore, it is not
possible to exploit the untrustworthiness of the challenge to turn the possible to exploit the untrustworthiness of the challenge to turn the
client into an encryption or signing oracle for the second factor client into an encryption or signing oracle for the second-factor
credentials, unless the attacker knows the client's long-term key.</t> credentials, unless the attacker knows the client's long-term key.</t>
<t>Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE <t>Unless FAST is used, any PA-SPAKE-HINT messages are unauthenticated
is advertised in authentication sets are unauthenticated, and are not and are not protected by the transcript hash if they are included when
protected by the transcript hash. Since hints do not replace any part SPAKE is advertised in authentication sets. Since hints do not replace
of the message flow, manipulation of hint messages can only affect the any part of the message flow, manipulation of hint messages can only
client's decision to use or not use an authentication set, which could affect the client's decision to use or not use an authentication set,
more easily be accomplished by removing authentication sets which could more easily be accomplished by removing authentication
entirely.</t> sets entirely.</t>
</section> </section>
<section><name>Side Channels</name> <section><name>Side Channels</name>
<t>An implementation of the SPAKE pre-authentication mechanism can have <t>An implementation of the SPAKE pre-authentication mechanism can have
the property of indistinguishability, meaning that an attacker who the property of indistinguishability, meaning that an attacker who
guesses a long-term key and a second factor value cannot determine guesses a long-term key and a second-factor value cannot determine
whether one of the factors was correct unless both are whether one of the factors was correct unless both are
correct. Indistinguishability is only maintained if the second factor correct. Indistinguishability is only maintained if the second factor
can be validated solely based on the data in the response; the use of can be validated solely based on the data in the response; the use of
additional round trips will reveal to the attacker whether the additional round trips will reveal to the attacker whether the
long-term key is correct. Indistinguishability also requires that long-term key is correct. Indistinguishability also requires that
there are no side channels. When processing a response message, whether there are no side channels.
or not the KDC successfully decrypts the factor field, it must reply
with the same error fields, take the same amount of time, and make the When the KDC processes a response message, whether or not it decrypts
same observable communications to other servers.</t> the factor field, it must reply with the same error fields, take the
same amount of time, and make the same observable communications to
other servers.</t>
<t>Both the size of the EncryptedData and the number of EncryptedData <t>Both the size of the EncryptedData and the number of EncryptedData
messages used for second-factor data (including the factor field of the messages used for second-factor data (including the factor field of the
SPAKEResponse message and messages using the encdata PA-SPAKE choice) SPAKEResponse message and messages using the encdata PA-SPAKE choice)
may reveal information about the second factor used in an may reveal information about the second factor used in an
authentication. Care should be taken to keep second factor messages as authentication. Care should be taken to keep second-factor messages as
small and as few as possible.</t> small and as few as possible.</t>
<t>Any side channels in the creation of the shared secret input w, or <t>Any side channels in the creation of the shared secret input w, or
in the multiplications wM and wN, could allow an attacker to recover in the multiplications wM and wN, could allow an attacker to recover
the client long-term key. Implementations MUST take care to avoid side the client long-term key. Implementations <bcp14>MUST</bcp14> take care to avoid side
channels, particularly timing channels. Generation of the secret scalar channels, particularly timing channels. Generation of the secret scalar
values x and y need not take constant time, but the amount of time values x and y need not take constant time, but the amount of time
taken MUST NOT provide information about the resulting value.</t> taken <bcp14>MUST NOT</bcp14> provide information about the resulting va lue.</t>
<t>The conversion of the scalar multiplier for the SPAKE w parameter <t>The conversion of the scalar multiplier for the SPAKE w parameter
may produce a multiplier that is larger than the order of the group. may produce a multiplier that is larger than the order of the group.
Some group implementations may be unable to handle such a multiplier. Some group implementations may be unable to handle such a multiplier.
Others may silently accept such a multiplier, but proceed to perform Others may silently accept such a multiplier but proceed to perform
multiplication that is not constant time. This is only a minor risk in multiplication that is not constant time. This is only a minor risk in
most commonly-used groups, but is a more serious risk for P-521 due to most commonly used groups, but it is a more serious risk for P-521 due t o
the extra seven high bits in the input octet string. A common solution the extra seven high bits in the input octet string. A common solution
to this problem is achieved by reducing the multiplier modulo the group to this problem is achieved by reducing the multiplier modulo the group
order, taking care to ensure constant time operation.</t> order, taking care to ensure constant time operation.</t>
</section> </section>
<section anchor="kdcstate"><name>KDC State</name> <section anchor="kdcstate"><name>KDC State</name>
<t>A stateless KDC implementation generally must use a PA-FX-COOKIE <t>A stateless KDC implementation generally must use a PA-FX-COOKIE
value to remember its private scalar value x and the transcript hash. value to remember its private scalar value x and the transcript hash.
The KDC MUST maintain confidentiality and integrity of the cookie The KDC <bcp14>MUST</bcp14> maintain confidentiality and integrity of th e cookie
value, perhaps by encrypting it in a key known only to the realm's value, perhaps by encrypting it in a key known only to the realm's
KDCs. Cookie values may be replayed by attackers, perhaps splicing them KDCs. Cookie values may be replayed by attackers, perhaps by splicing th
into different SPAKE exchanges. The KDC SHOULD limit the time window of em
replays using a timestamp, and SHOULD prevent cookie values from being into different SPAKE exchanges. The KDC <bcp14>SHOULD</bcp14> limit the
time window of
replays using a timestamp, and it <bcp14>SHOULD</bcp14> prevent cookie v
alues from being
applied to other pre-authentication mechanisms or other client applied to other pre-authentication mechanisms or other client
principals. Within the validity period of a cookie, an attacker can principals. Within the validity period of a cookie, an attacker can
replay the final message of a pre-authentication exchange to any of the replay the final message of a pre-authentication exchange to any of the
realm's KDCs and make it appear that the client has authenticated.</t> realm's KDCs and make it appear that the client has authenticated.</t>
<t>The SPAKE pre-authentication mechanism is not designed to provide <t>The SPAKE pre-authentication mechanism is not designed to provide
forward secrecy. Nevertheless, some measure of forward secrecy may forward secrecy. Nevertheless, some measure of forward secrecy may
result depending on implementation choices. A passive attacker who result depending on implementation choices. A passive attacker who
determines the client long-term key after the exchange generally will determines the client long-term key after the exchange generally will
not be able to recover the ticket session key; however, an attacker who not be able to recover the ticket session key; however, an attacker who
skipping to change at line 742 skipping to change at line 754
encrypted cookie) will be able to recover the ticket session key. If encrypted cookie) will be able to recover the ticket session key. If
the KDC or client retains the x or y value for reuse with the same the KDC or client retains the x or y value for reuse with the same
client long-term key, an attacker who recovers the x or y value and the client long-term key, an attacker who recovers the x or y value and the
long-term key will be able to recover the ticket session key.</t> long-term key will be able to recover the ticket session key.</t>
</section> </section>
<section><name>Dictionary Attacks</name> <section><name>Dictionary Attacks</name>
<t>Although the SPAKE pre-authentication mechanism is designed to <t>Although the SPAKE pre-authentication mechanism is designed to
prevent an offline dictionary attack by an active attacker posing as prevent an offline dictionary attack by an active attacker posing as
the KDC, such an attacker can attempt to downgrade the client to the KDC, such an attacker can attempt to downgrade the client to
encrypted timestamp. Client implementations SHOULD provide a the encrypted timestamp pre-authentication mechanism. Client implementat
configuration option to enable or disable encrypted timestamp on a ions <bcp14>SHOULD</bcp14> provide a
configuration option to enable or disable the encrypted timestamp mechan
ism on a
per-realm basis to mitigate this attack.</t> per-realm basis to mitigate this attack.</t>
<t>If the user enters the wrong password, the client might fall back to <t>If the user enters the wrong password, the client might fall back
encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error from to the encrypted timestamp mechanism after receiving a
the KDC, if encrypted timestamp is offered by the KDC and not disabled KDC_ERR_PREAUTH_FAILED error from the KDC, if the encrypted timestamp me
by client configuration. This fallback will enable a passive attacker chanism
to mount an offline dictionary attack against the incorrect password, is offered by the KDC and not disabled by client configuration. This
which may be similar to the correct password. Client implementations fallback will enable a passive attacker to mount an offline dictionary
SHOULD assume that encrypted timestamp and encrypted challenge are attack against the incorrect password, which may be similar to the
unlikely to succeed if SPAKE pre-authentication fails in the second correct password. Client implementations <bcp14>SHOULD</bcp14> assume
pass and SF-NONE was used.</t> that the encrypted timestamp and encrypted challenge mechanisms are unli
kely to
succeed if SPAKE pre-authentication fails in the second pass and
SF-NONE was used.</t>
<t>Like any other pre-authentication mechanism using the client <t>Like any other pre-authentication mechanism using the client
long-term key, the SPAKE pre-authentication mechanism does not prevent long-term key, the SPAKE pre-authentication mechanism does not prevent
online password guessing attacks. The KDC is made aware of unsuccessful online password guessing attacks. The KDC is made aware of unsuccessful
guesses, and can apply facilities such as rate limiting to mitigate the guesses and can apply facilities such as rate limiting to mitigate the
risk of online attacks.</t> risk of online attacks.</t>
</section> </section>
<section><name>Brute Force Attacks</name> <section><name>Brute-Force Attacks</name>
<t>The selected group's resistance to offline brute-force attacks may <t>The selected group's resistance to offline brute-force attacks may
not correspond to the size of the reply key. For performance reasons, a not correspond to the size of the reply key. For performance reasons, a
KDC MAY select a group whose brute-force work factor is less than the KDC <bcp14>MAY</bcp14> select a group whose brute-force work factor is l ess than the
reply key length. A passive attacker who solves the group discrete reply key length. A passive attacker who solves the group discrete
logarithm problem after the exchange will be able to conduct an offline logarithm problem after the exchange will be able to conduct an offline
attack against the client long-term key. Although the use of password attack against the client long-term key. Although the use of password
policies and costly, salted string-to-key functions may increase the policies and costly, salted string-to-key functions may increase the
cost of such an attack, the resulting cost will likely not be higher cost of such an attack, the resulting cost will likely not be higher
than the cost of solving the group discrete logarithm.</t> than the cost of solving the group discrete logarithm.</t>
</section> </section>
<section><name>Denial of Service Attacks</name> <section><name>Denial-of-Service Attacks</name>
<t>Elliptic curve group operations are more computationally expensive <t>Elliptic curve group operations are more computationally expensive
than secret-key operations. As a result, the use of this mechanism may than secret-key operations. As a result, the use of this mechanism may
affect the KDC's performance under normal load and its resistance to affect the KDC's performance under normal load and its resistance to
denial of service attacks.</t> denial-of-service attacks.</t>
</section> </section>
<section><name>Reflection Attacks</name> <section><name>Reflection Attacks</name>
<t>The encdata choice of PA-SPAKE can be used in either direction, and <t>The encdata choice of PA-SPAKE can be used in either direction;
the factor-specific plaintext does not necessarily indicate a the factor-specific plaintext does not necessarily indicate a
direction. However, each encdata message is encrypted using a derived direction. However, each encdata message is encrypted using a derived
key K'[n], with client-originated messages using only odd values of n key K'[n], with client-originated messages using only odd values of n
and KDC-originated messages using only even values. An attempted and KDC-originated messages using only even values. Therefore, an attemp
reflection attack would therefore result in a failed decryption.</t> ted
reflection attack would result in a failed decryption.</t>
</section> </section>
<section><name>Reply-Key Encryption Type</name> <section><name>Reply Key Encryption Type</name>
<t>This mechanism does not upgrade the encryption type of the initial <t>This mechanism does not upgrade the encryption type of the initial
reply key, and relies on that encryption type for confidentiality, reply key and relies on that encryption type for confidentiality,
integrity, and pseudo-random functions. If the client long-term key integrity, and pseudorandom functions. If the client long-term key
uses a weak encryption type, an attacker might be able to subvert the uses a weak encryption type, an attacker might be able to subvert the
exchange, and the replaced reply key will also be of the same weak exchange, and the replaced reply key will also be of the same weak
encryption type.</t> encryption type.</t>
</section> </section>
<section><name>KDC Authentication</name> <section><name>KDC Authentication</name>
<t>This mechanism does not directly provide the KDC Authentication <t>This mechanism does not directly provide the KDC Authentication
pre-authentication facility, because it does not send a key pre-authentication facility because it does not send a key
confirmation from the KDC to the client. When used as a stand-alone confirmation from the KDC to the client. When used as a stand-alone
mechanism, the traditional KDC authentication provided by the KDC-REP mechanism, the preexisting KDC authentication provided by the KDC-REP
enc-part still applies.</t> enc-part still applies.</t>
</section> </section>
</section> </section>
<section><name>Assigned Constants</name> <section><name>Assigned Constants</name>
<t>The following key usage values are assigned for this mechanism:</t> <t>The following key usage values are assigned for this mechanism:</t>
<dl><dt>KEY_USAGE_SPAKE</dt><dd>65</dd></dl> <dl><dt>KEY_USAGE_SPAKE</dt><dd>65</dd></dl>
</section> </section>
<section><name>IANA Considerations</name> <section><name>IANA Considerations</name>
<t>IANA has assigned the following number for PA-SPAKE in the <t>IANA has assigned the following number for PA-SPAKE in the
"Pre-authentication and Typed Data" registry:</t> "Pre-authentication and Typed Data" registry:</t>
<table align="center"> <table align="center">
<thead> <thead>
<tr><th>Type</th><th>Value</th><th>Reference</th></tr> <tr><th>Type</th><th>Value</th><th>Reference</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td>PA-SPAKE</td><td>151</td><td>[this document]</td></tr> <tr><td>PA-SPAKE</td><td>151</td><td>RFC 9588</td></tr>
</tbody> </tbody>
</table> </table>
<t>This document establishes two registries with the following <t>This document establishes two registries (see Sections <xref target="Se cond-Factor" format="counter"/> and <xref target="SPAKE-Groups" format="counter" />) with the following
procedure, in accordance with <xref target="RFC8126"/>:</t> procedure, in accordance with <xref target="RFC8126"/>:</t>
<t>Registry entries are to be evaluated using the Specification <t>Registry entries are to be evaluated using the Specification
Required method. All specifications must be be published prior Required method. All specifications must be published prior
to entry inclusion in the registry. Once published, they can be to entry inclusion in the registry. Once published, they can be
submitted directly to the krb5-spake-review@ietf.org mailing submitted directly to the krb5-spake-review@ietf.org mailing
list, where there will be a three-week long review period by list, where there will be a three-week-long review period by
Designated Experts.</t> designated experts.</t>
<t>The Designated Experts ensure that the specification is publicly <t>The designated experts ensure that the specification is publicly
available. The Designated Experts may provide additional in-depth available. They may provide additional in-depth
reviews, but their approval should not be taken as endorsement of the reviews, but their approval should not be taken as endorsement of the
specification.</t> specification.</t>
<t>Prior to the end of the review period, the Designated Experts <t>Prior to the end of the review period, the designated experts
must approve or deny the request. This decision is conveyed to must approve or deny the request. This decision is conveyed to
both IANA and the submitter. Since the mailing list archives are both IANA and the submitter. Since the mailing list archives are
not public, it should include both a reasonably detailed not public, it should include both a reasonably detailed
explanation in the case of a denial as well as whether the explanation in the case of a denial as well as whether the
request can be resubmitted.</t> request can be resubmitted.</t>
<t>IANA must only accept registry updates from the designated experts <t>IANA must only accept registry updates from the designated experts
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list.</t> list.</t>
<section><name>Kerberos Second Factor Types</name> <section anchor="Second-Factor"><name>Kerberos Second-Factor Types</name>
<t>This section species the IANA "Kerberos Second Factor Types" <t>This section specifies the "Kerberos Second-Factor Types"
registry. This registry records the number, name, and reference for registry, which records the number, name, and reference for
each second factor protocol.</t> each second-factor protocol.</t>
<section><name>Registration Template</name> <section><name>Registration Template</name>
<dl> <dl>
<dt>ID Number:</dt> <dt>ID Number:</dt>
<dd> <dd>
This is a value that uniquely identifies this entry. It is a A value that uniquely identifies this entry. It is a
signed integer in range -2147483648 to 2147483647, inclusive. signed integer in the range -2147483648 to 2147483647, inclusive
.
Positive values must be assigned only for algorithms specified Positive values must be assigned only for algorithms specified
in accordance with these rules for use with Kerberos and in accordance with these rules for use with Kerberos and
related protocols. Negative values should be used for private related protocols. Negative values should be used for private
and experimental algorithms only. Zero is reserved and must and experimental algorithms only. Zero is reserved and must
not be assigned. Values should be assigned in increasing not be assigned. Values should be assigned in increasing
order. order.
</dd> </dd>
<dt>Name:</dt> <dt>Name:</dt>
<dd>Brief, unique, human-readable name for this algorithm.</dd> <dd>A brief, unique, human-readable name for this algorithm.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
URI or otherwise unique identifier for where the details of A URI or otherwise unique identifier for where the details of
this algorithm can be found. It should be as specific as this algorithm can be found. It should be as specific as
reasonably possible. reasonably possible.
</dd> </dd>
</dl> </dl>
</section> </section>
<section><name>Initial Registry Contents</name> <section><name>Initial Registry Contents</name>
<dl spacing="compact"> <dl spacing="compact">
<dt>ID Number:</dt><dd>0</dd>
<dt>Name:</dt><dd>Reserved</dd>
<dt>Reference:</dt><dd>RFC 9588</dd>
</dl>
<dl spacing="compact">
<dt>ID Number:</dt><dd>1</dd> <dt>ID Number:</dt><dd>1</dd>
<dt>Name:</dt><dd>SF-NONE</dd> <dt>Name:</dt><dd>SF-NONE</dd>
<dt>Reference:</dt><dd>[this document]</dd> <dt>Reference:</dt><dd>RFC 9588</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section><name>Kerberos SPAKE Groups</name> <section anchor="SPAKE-Groups"><name>Kerberos SPAKE Groups</name>
<t>This section specifies the IANA "Kerberos SPAKE Groups" registry. <t>This section specifies the "Kerberos SPAKE Groups" registry, which
This registry records the number, name, specification, serialization, records the number, name, specification, serialization,
multiplier length, multiplier conversion, SPAKE M and N constants, and multiplier length, multiplier conversion, SPAKE M and N constants, and
associated hash function.</t> associated hash function for each SPAKE Group.</t>
<section><name>Registration Template</name> <section><name>Registration Template</name>
<dl> <dl>
<dt>ID Number:</dt> <dt>ID Number:</dt>
<dd> <dd>
This is a value that uniquely identifies this entry. It is a A value that uniquely identifies this entry. It is a
signed integer in range -2147483648 to 2147483647, inclusive. signed integer in the range -2147483648 to 2147483647, inclusive
.
Positive values must be assigned only for algorithms specified i n Positive values must be assigned only for algorithms specified i n
accordance with these rules for use with Kerberos and related accordance with these rules for use with Kerberos and related
protocols. Negative values should be used for private and protocols. Negative values should be used for private and
experimental use only. Zero is reserved and must not be experimental use only. Zero is reserved and must not be
assigned. Values should be assigned in increasing order. assigned. Values should be assigned in increasing order.
</dd> </dd>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
Brief, unique, human readable name for this entry. A brief, unique, human-readable name for this entry.
</dd> </dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd> <dd>
Reference to the definition of the group parameters and operatio ns. A reference to the definition of the group parameters and operat ions.
</dd> </dd>
<dt>Serialization:</dt> <dt>Serialization:</dt>
<dd> <dd>
Reference to the definition of the method used to serialize A reference to the definition of the method used to serialize
and deserialize group elements. and deserialize group elements.
</dd> </dd>
<dt>Multiplier Length:</dt> <dt>Multiplier Length:</dt>
<dd> <dd>
The length of the input octet string to multiplication operation s. The length of the input octet string to multiplication operation s.
</dd> </dd>
<dt>Multiplier Conversion:</dt> <dt>Multiplier Conversion:</dt>
<dd> <dd>
Reference to the definition of the method used to convert an A reference to the definition of the method used to convert an
octet string to a multiplier scalar. octet string to a multiplier scalar.
</dd> </dd>
<dt>SPAKE M Constant:</dt> <dt>SPAKE M Constant:</dt>
<dd> <dd>
The serialized value of the SPAKE M constant in hexadecimal nota tion. The serialized value of the SPAKE M constant in hexadecimal nota tion.
</dd> </dd>
<dt>SPAKE N Constant:</dt> <dt>SPAKE N Constant:</dt>
<dd> <dd>
The serialized value of the SPAKE N constant in hexadecimal nota tion. The serialized value of the SPAKE N constant in hexadecimal nota tion.
</dd> </dd>
<dt>Hash Function:</dt> <dt>Hash Function:</dt>
<dd> <dd>
The group's associated hash function. The group's associated hash function.
</dd> </dd>
</dl> </dl>
</section> </section>
<section><name>Initial Registry Contents</name> <section><name>Initial Registry Contents</name>
<section><name>Edwards 25519</name><dl spacing="compact"> <section><name>Edwards 25519</name><dl spacing="compact">
<dt>ID Number:</dt><dd>1</dd> <dt>ID Number:</dt><dd>1</dd>
<dt>Name:</dt><dd>edwards25519</dd> <dt>Name:</dt><dd>edwards25519</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd>Section 4.1 of <xref target="RFC7748"/> (edwards25519)</dd> <dd><xref target="RFC7748" section="4.1" sectionFormat="of"/> (edwar ds25519)</dd>
<dt>Serialization:</dt> <dt>Serialization:</dt>
<dd>Section 3.1 of <xref target="RFC8032"/></dd> <dd><xref target="RFC8032" section="3.1" sectionFormat="of"/></dd>
<dt>Multiplier Length:</dt><dd>32</dd> <dt>Multiplier Length:</dt><dd>32</dd>
<dt>Multiplier Conversion:</dt> <dt>Multiplier Conversion:</dt>
<dd>Section 3.1 of <xref target="RFC8032"/></dd> <dd><xref target="RFC8032" section="3.1" sectionFormat="of"/></dd>
<dt>SPAKE M Constant:</dt> <dt>SPAKE M Constant:</dt>
<dd>d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf </dd> <dd>d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf </dd>
<dt>SPAKE N Constant:</dt> <dt>SPAKE N Constant:</dt>
<dd>d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab </dd> <dd>d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab </dd>
<dt>Hash function:</dt><dd>SHA-256 (<xref target="RFC6234"/>)</dd> <dt>Hash function:</dt><dd>SHA-256 <xref target="RFC6234"/></dd>
</dl></section> </dl></section>
<section><name>P-256</name><dl spacing="compact"> <section><name>P-256</name><dl spacing="compact">
<dt>ID Number:</dt><dd>2</dd> <dt>ID Number:</dt><dd>2</dd>
<dt>Name:</dt><dd>P-256</dd> <dt>Name:</dt><dd>P-256</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd>Section 2.4.2 of <xref target="SEC2"/></dd> <dd>Section 2.4.2 of <xref target="SEC2"/></dd>
<dt>Serialization:</dt> <dt>Serialization:</dt>
<dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd> <dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd>
<dt>Multiplier Length:</dt><dd>32</dd> <dt>Multiplier Length:</dt><dd>32</dd>
<dt>Multiplier Conversion:</dt> <dt>Multiplier Conversion:</dt>
<dd>Section 2.3.8 of <xref target="SEC1"/></dd> <dd>Section 2.3.8 of <xref target="SEC1"/></dd>
<dt>SPAKE M Constant:</dt> <dt>SPAKE M Constant:</dt>
<dd>02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa1 2f</dd> <dd>02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa1 2f</dd>
<dt>SPAKE N Constant:</dt> <dt>SPAKE N Constant:</dt>
<dd>03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b 49</dd> <dd>03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b 49</dd>
<dt>Hash function:</dt><dd>SHA-256 (<xref target="RFC6234"/>)</dd> <dt>Hash function:</dt><dd>SHA-256 <xref target="RFC6234"/></dd>
</dl></section> </dl></section>
<section><name>P-384</name><dl spacing="compact"> <section><name>P-384</name><dl spacing="compact">
<dt>ID Number:</dt><dd>3</dd> <dt>ID Number:</dt><dd>3</dd>
<dt>Name:</dt><dd>P-384</dd> <dt>Name:</dt><dd>P-384</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd>Section 2.5.1 of <xref target="SEC2"/></dd> <dd>Section 2.5.1 of <xref target="SEC2"/></dd>
<dt>Serialization:</dt> <dt>Serialization:</dt>
<dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd> <dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd>
<dt>Multiplier Length:</dt><dd>48</dd> <dt>Multiplier Length:</dt><dd>48</dd>
<dt>Multiplier Conversion:</dt> <dt>Multiplier Conversion:</dt>
<dd>Section 2.3.8 of <xref target="SEC1"/></dd> <dd>Section 2.3.8 of <xref target="SEC1"/></dd>
<dt>SPAKE M Constant:</dt> <dt>SPAKE M Constant:</dt>
<dd>030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d 3dc36f15314739074d2eb8613fceec2853</dd> <dd>030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d 3dc36f15314739074d2eb8613fceec2853</dd>
<dt>SPAKE N Constant:</dt> <dt>SPAKE N Constant:</dt>
<dd>02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c54 3bb252c5490214cf9aa3f0baab4b665c10</dd> <dd>02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c54 3bb252c5490214cf9aa3f0baab4b665c10</dd>
<dt>Hash function:</dt><dd>SHA-384 (<xref target="RFC6234"/>)</dd> <dt>Hash function:</dt><dd>SHA-384 <xref target="RFC6234"/></dd>
</dl></section> </dl></section>
<section><name>P-521</name><dl spacing="compact"> <section><name>P-521</name><dl spacing="compact">
<dt>ID Number:</dt><dd>4</dd> <dt>ID Number:</dt><dd>4</dd>
<dt>Name:</dt><dd>P-521</dd> <dt>Name:</dt><dd>P-521</dd>
<dt>Specification:</dt> <dt>Specification:</dt>
<dd>Section 2.6.1 of <xref target="SEC2"/></dd> <dd>Section 2.6.1 of <xref target="SEC2"/></dd>
<dt>Serialization:</dt> <dt>Serialization:</dt>
<dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd> <dd>Section 2.3.3 of <xref target="SEC1"/> (compressed format)</dd>
<dt>Multiplier Length:</dt><dd>48</dd> <dt>Multiplier Length:</dt><dd>48</dd>
<dt>Multiplier Conversion:</dt> <dt>Multiplier Conversion:</dt>
<dd>Section 2.3.8 of <xref target="SEC1"/></dd> <dd>Section 2.3.8 of <xref target="SEC1"/></dd>
<dt>SPAKE M Constant:</dt> <dt>SPAKE M Constant:</dt>
<dd>02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85 608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa</dd> <dd>02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85 608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa</dd>
<dt>SPAKE N Constant:</dt> <dt>SPAKE N Constant:</dt>
<dd>0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e49 4b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25</dd> <dd>0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e49 4b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25</dd>
<dt>Hash function:</dt><dd>SHA-512 (<xref target="RFC6234"/>)</dd> <dt>Hash function:</dt><dd>SHA-512 <xref target="RFC6234"/></dd>
</dl></section> </dl></section>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references><name>Normative References</name> <references>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <name>References</name>
.2119.xml'/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <references>
.3961.xml'/> <name>Normative References</name>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
.4120.xml'/> 9.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.396
.6113.xml'/> 1.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.412
.6234.xml'/> 0.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.611
.7748.xml'/> 3.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.623
.8032.xml'/> 4.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.774
.8126.xml'/> 8.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
.8174.xml'/> 2.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml2/reference.CC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
ITT.X680.2002.xml'/> 6.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml2/reference.CC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
ITT.X690.2002.xml'/> 4.xml"/>
<reference anchor='ITU-T.X680.2021'>
<front>
<title>Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference>
<reference anchor='ITU-T.X690.2021'>
<front>
<title>Information technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference>
<reference anchor='SEC1'> <reference anchor='SEC1'>
<front> <front>
<title>SEC 1: Elliptic Curve Cryptography</title> <title>SEC 1: Elliptic Curve Cryptography</title>
<author><organization>Standards for Efficient Cryptography <author>
Group</organization></author> <organization>Standards for Efficient Cryptography
Group</organization>
</author>
<date month="May" year="2009" /> <date month="May" year="2009" />
</front> </front>
</reference> </reference>
<reference anchor='SEC2'> <reference anchor='SEC2'>
<front> <front>
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
<author><organization>Standards for Efficient Cryptography <author>
Group</organization></author> <organization>Standards for Efficient Cryptography
Group</organization>
</author>
<date month="January" year="2010" /> <date month="January" year="2010" />
</front> </front>
</reference> </reference>
</references> </references>
<references><name>Informative References</name>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <references>
.6090.xml'/> <name>Informative References</name>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.609
.6560.xml'/> 0.xml"/>
<xi:include href='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.656
.8125.xml'/> 0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
5.xml"/>
<reference anchor="SPAKE"> <reference anchor="SPAKE">
<front> <front>
<title>Simple Password-Based Encrypted Key Exchange Protocols</title> <title>Simple Password-Based Encrypted Key Exchange Protocols</title>
<author surname="Abdalla" initials="M." /> <author surname="Abdalla" initials="M."/>
<author surname="Pointcheval" initials="D. " /> <author surname="Pointcheval" initials="D."/>
<date month="February" year="2005" /> <date month="February" year="2005"/>
</front> </front>
<refcontent>Cryptography-CT-RSA 2005, Lecture Notes in Computer <refcontent>CT-RSA 2005, Lecture Notes in Computer
Science, Volume 3376, pages 191-208, Springer</refcontent> Science, Volume 3376, pages 191-208, Springer</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-540-30574-3_14"/> <seriesInfo name="DOI" value="10.1007/978-3-540-30574-3_14"/>
</reference> </reference>
</references> </references>
</references>
<section><name>ASN.1 Module</name> <section><name>ASN.1 Module</name>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
KerberosV5SPAKE { KerberosV5SPAKE {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) spake(8) security(5) kerberosV5(2) modules(4) spake(8)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
EncryptedData, Int32 EncryptedData, Int32
FROM KerberosV5Spec2 { iso(1) identified-organization(3) FROM KerberosV5Spec2 { iso(1) identified-organization(3)
skipping to change at line 1121 skipping to change at line 1178
factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor
} }
END END
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section><name>SPAKE M and N Value Selection</name> <section><name>SPAKE M and N Value Selection</name>
<t>The M and N values for the initial contents of the SPAKE group <t>The M and N values for the initial contents of the SPAKE group
registry were generated using the following Python snippet, which assumes registry were generated using the following Python snippet, which assumes
an elliptic curve implementation following the interface of an elliptic curve implementation following the interface of
Edwards25519Point.stdbase() and Edwards448Point.stdbase() in Appendix A Edwards25519Point.stdbase() and Edwards448Point.stdbase() in <xref target=
of <xref target="RFC8032"/>:</t> "RFC8032" sectionFormat="of" section="A"/>:</t>
<sourcecode type="python"><![CDATA[ <sourcecode type="python"><![CDATA[
def iterhash(seed, n): def iterhash(seed, n):
h = seed h = seed
for i in range(n): for i in range(n):
h = hashlib.sha256(h).digest() h = hashlib.sha256(h).digest()
return h return h
def bighash(seed, start, sz): def bighash(seed, start, sz):
n = -(-sz // 32) n = -(-sz // 32)
hashes = [iterhash(seed, i) for i in range(start, start + n)] hashes = [iterhash(seed, i) for i in range(start, start + n)]
skipping to change at line 1154 skipping to change at line 1210
for i in range(1, 1000): for i in range(1, 1000):
hval = bighash(seed, i, len(ec.encode())) hval = bighash(seed, i, len(ec.encode()))
pointstr = canon_pointstr(ecname, hval) pointstr = canon_pointstr(ecname, hval)
try: try:
p = ec.decode(pointstr) p = ec.decode(pointstr)
if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
return pointstr, i return pointstr, i
except Exception: except Exception:
pass pass
]]></sourcecode> ]]></sourcecode>
<t>The seed initial seed strings are:</t>
<t>The initial seed strings are as follows:</t>
<ul> <ul>
<li>For group 1 M: edwards25519 point generation seed (M)</li> <li>For group 1 M: edwards25519 point generation seed (M)</li>
<li>For group 1 N: edwards25519 point generation seed (N)</li> <li>For group 1 N: edwards25519 point generation seed (N)</li>
<li>For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)</li> <li>For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)</li>
<li>For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)</li> <li>For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)</li>
<li>For group 3 M: 1.3.132.0.34 point generation seed (M)</li> <li>For group 3 M: 1.3.132.0.34 point generation seed (M)</li>
<li>For group 3 N: 1.3.132.0.34 point generation seed (N)</li> <li>For group 3 N: 1.3.132.0.34 point generation seed (N)</li>
<li>For group 4 M: 1.3.132.0.35 point generation seed (M)</li> <li>For group 4 M: 1.3.132.0.35 point generation seed (M)</li>
<li>For group 4 N: 1.3.132.0.35 point generation seed (N)</li> <li>For group 4 N: 1.3.132.0.35 point generation seed (N)</li>
</ul> </ul>
</section> </section>
<section><name>Test Vectors</name> <section><name>Test Vectors</name>
<t>For the following text vectors:</t> <t>For the following text vectors:</t>
<ul> <ul>
<li>The key is the string-to-key of "password" with the salt <li>The key is the string-to-key of "password" with the salt
"ATHENA.MIT.EDUraeburn" for the designated initial reply key "ATHENA.MIT.EDUraeburn" for the designated initial reply key
encryption type.</li> encryption type.</li>
<li>x and y were chosen randomly within the order of the <li>x and y were chosen randomly within the order of the
designated group, then multiplied by the cofactor..</li> designated group, then multiplied by the cofactor.</li>
<li>The SPAKESupport message contains only the designated <li>The SPAKESupport message contains only the designated
group's number.</li> group's number.</li>
<li>The SPAKEChallenge message offers only the SF-NONE second <li>The SPAKEChallenge message offers only the SF-NONE second-factor typ
factor type.</li> e.</li>
<li>The KDC-REQ-BODY message contains no KDC options, the
client principal name "raeburn@ATHENA.MIT.EDU", the server <li>The KDC-REQ-BODY message does not contain KDC options, but
principal name "krbtgt/ATHENA.MIT.EDU", the realm does contain the client principal name "raeburn@ATHENA.MIT.EDU", the
"ATHENA.MIT.EDU", the till field "19700101000000Z", the nonce server principal name "krbtgt/ATHENA.MIT.EDU", the realm
zero, and an etype list containing only the designated "ATHENA.MIT.EDU", the till field "19700101000000Z", the nonce zero,
encryption type.</li> and an etype list containing only the designated encryption type.</li>
</ul> </ul>
<artwork><![CDATA[ <sourcecode type="test-vector"><![CDATA[
des3-cbc-sha1 edwards25519 des3-cbc-sha1 edwards25519
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
w (PRF+ output): 686d84730cb8679ae95416c6567c6a63 w (PRF+ output): 686d84730cb8679ae95416c6567c6a63
f2c9cef124f7a3371ae81e11cad42a37 f2c9cef124f7a3371ae81e11cad42a37
w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24 w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24
f2c9cef124f7a3371ae81e11cad42a07 f2c9cef124f7a3371ae81e11cad42a07
x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723 x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723
y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25 y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25
X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e
Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028 Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028
skipping to change at line 1548 skipping to change at line 1604
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: 631fcc8596e7f40e59045950d72aa0b7 K'[0]: 631fcc8596e7f40e59045950d72aa0b7
bac2810a07b767050e983841cf3a2d4c bac2810a07b767050e983841cf3a2d4c
K'[1]: 881464920117074dbc67155a8f3341d1 K'[1]: 881464920117074dbc67155a8f3341d1
121ef65f78ea0380bfa81a134c1c47b1 121ef65f78ea0380bfa81a134c1c47b1
K'[2]: 377b72ac3af2caad582d73ae4682fd56 K'[2]: 377b72ac3af2caad582d73ae4682fd56
b531ee56706200dd6c38c42b8219837a b531ee56706200dd6c38c42b8219837a
K'[3]: 35ad8e4d580ed3f0d15ad928329773c0 K'[3]: 35ad8e4d580ed3f0d15ad928329773c0
81bd19f9a56363f3a5f77c7e66108c26 81bd19f9a56363f3a5f77c7e66108c26
]]></artwork> ]]></sourcecode>
<t>There are currently no encryption types with a seed size large enough <t>There are currently no encryption types with a seed size large enough
to require multiple hash blocks during key derivation with any of the to require multiple hash blocks during key derivation with any of the
assigned hash functions. To exercise this possibility, the following assigned hash functions. To exercise this possibility, the following
test vector illustrates what keys would be derived if there were a copy test vector illustrates what keys would be derived if there were a copy
of the edwards25519 group with group number -1 and associated hash of the edwards25519 group with group number -1 and associated hash
function SHA-1:</t> function SHA-1:</t>
<artwork><![CDATA[ <sourcecode type="test-vector"><![CDATA[
AES256 edwards25519 SHA-1 group number -1 AES256 edwards25519 SHA-1 group number -1
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): 26da6b118cee6fa5ea795ed32d61490d w (PRF+ output): 26da6b118cee6fa5ea795ed32d61490d
82b2f11102312f3f2fc04fb01c93df91 82b2f11102312f3f2fc04fb01c93df91
w (reduced multiplier): d166c7cc9e72ca8c61f6a9185a987251 w (reduced multiplier): d166c7cc9e72ca8c61f6a9185a987251
81b2f11102312f3f2fc04fb01c93df01 81b2f11102312f3f2fc04fb01c93df01
x: 606c1b668008ed78fe2eee942e8f08007f3f1dcbef66d37fd69033525bda2030 x: 606c1b668008ed78fe2eee942e8f08007f3f1dcbef66d37fd69033525bda2030
y: 10fc4e0bb1a902e58f632a1ea0bceb366360ac985f46996d956a02572bfcf050 y: 10fc4e0bb1a902e58f632a1ea0bceb366360ac985f46996d956a02572bfcf050
X: 389621509665abad35eaab26eab3a0f593c7b4380562aa5513c1140fd78ce048 X: 389621509665abad35eaab26eab3a0f593c7b4380562aa5513c1140fd78ce048
Y: de3ed05986eeac518958b566f9bad065b321402025cd188f3d198dc55c6d6b8d Y: de3ed05986eeac518958b566f9bad065b321402025cd188f3d198dc55c6d6b8d
skipping to change at line 1590 skipping to change at line 1646
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: 40bceb51bba474fd29ae65950022b704 K'[0]: 40bceb51bba474fd29ae65950022b704
17b80d973fa8d8d6cd39833ff89964ad 17b80d973fa8d8d6cd39833ff89964ad
K'[1]: c29a7315453dc1cce938fa12a9e5c0db K'[1]: c29a7315453dc1cce938fa12a9e5c0db
2894b2194da14c9cd4f7bc3a6a37223d 2894b2194da14c9cd4f7bc3a6a37223d
K'[2]: f261984dba3c230fad99d324f871514e K'[2]: f261984dba3c230fad99d324f871514e
5aad670e44f00daef3264870b0851c25 5aad670e44f00daef3264870b0851c25
K'[3]: d24b2b46bab7c4d1790017d9116a7eeb K'[3]: d24b2b46bab7c4d1790017d9116a7eeb
ca88b0562a5ad8989c826cb7dab715c7 ca88b0562a5ad8989c826cb7dab715c7
]]></artwork> ]]></sourcecode>
</section> </section>
<section><name>Acknowledgements</name> <section numbered="false"><name>Acknowledgements</name>
<artwork><![CDATA[ <t><contact fullname="Nico Williams"/> (Cryptonector)</t>
Nico Williams (Cryptonector) <t><contact fullname="Taylor Yu"/> (MIT)</t>
Taylor Yu (MIT)
]]></artwork>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 181 change blocks. 
371 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.48.