rfc9588.original   rfc9588.txt 
Internet Engineering Task Force N. McCallum Internet Engineering Task Force (IETF) N. McCallum
Internet-Draft S. Sorce Request for Comments: 9588 S. Sorce
Intended status: Standards Track R. Harwood Category: Standards Track R. Harwood
Expires: 11 August 2024 Red Hat, Inc. ISSN: 2070-1721 Red Hat, Inc.
G. Hudson G. Hudson
MIT MIT
8 February 2024 August 2024
Kerberos SPAKE Pre-Authentication Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-
draft-ietf-kitten-krb-spake-preauth-13 authentication
Abstract Abstract
This document defines a new pre-authentication mechanism for the This document defines a new pre-authentication mechanism for the
Kerberos protocol. The mechanism uses a password-authenticated key Kerberos protocol. The mechanism uses a password-authenticated key
exchange to prevent brute-force password attacks, and may optionally exchange (PAKE) to prevent brute-force password attacks, and it may
incorporate a second factor. incorporate a second factor.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 11 August 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9588.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Properties of PAKE . . . . . . . . . . . . . . . . . . . 3 1.1. Properties of PAKE
1.2. PAKE Algorithm Selection . . . . . . . . . . . . . . . . 4 1.2. PAKE Algorithm Selection
1.3. PAKE and Two-Factor Authentication . . . . . . . . . . . 4 1.3. PAKE and Two-Factor Authentication
1.4. SPAKE Overview . . . . . . . . . . . . . . . . . . . . . 5 1.4. SPAKE Overview
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 5 2. Document Conventions
3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Prerequisites
3.1. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . 6 3.1. PA-ETYPE-INFO2
3.2. Cookie Support . . . . . . . . . . . . . . . . . . . . . 6 3.2. Cookie Support
3.3. More Pre-Authentication Data Required . . . . . . . . . . 6 3.3. More Pre-authentication Data Required
4. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 6 4. SPAKE Pre-authentication Message Protocol
4.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. First Pass
4.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Second Pass
4.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Third Pass
4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10 4.4. Subsequent Passes
4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 11 4.5. Reply Key Strengthening
4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Optimizations
5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 12 5. SPAKE Parameters and Conversions
6. Transcript Hash . . . . . . . . . . . . . . . . . . . . . . . 12 6. Transcript Hash
7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 13 7. Key Derivation
8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 14 8. Second-Factor Types
9. Hint for Authentication Sets . . . . . . . . . . . . . . . . 14 9. Hint for Authentication Sets
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations
10.1. SPAKE Computations . . . . . . . . . . . . . . . . . . . 15 10.1. SPAKE Computations
10.2. Unauthenticated Plaintext . . . . . . . . . . . . . . . 15 10.2. Unauthenticated Plaintext
10.3. Side Channels . . . . . . . . . . . . . . . . . . . . . 16 10.3. Side Channels
10.4. KDC State . . . . . . . . . . . . . . . . . . . . . . . 17 10.4. KDC State
10.5. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 18 10.5. Dictionary Attacks
10.6. Brute Force Attacks . . . . . . . . . . . . . . . . . . 18 10.6. Brute-Force Attacks
10.7. Denial of Service Attacks . . . . . . . . . . . . . . . 18 10.7. Denial-of-Service Attacks
10.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . 19 10.8. Reflection Attacks
10.9. Reply-Key Encryption Type . . . . . . . . . . . . . . . 19 10.9. Reply Key Encryption Type
10.10. KDC Authentication . . . . . . . . . . . . . . . . . . . 19 10.10. KDC Authentication
11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 19 11. Assigned Constants
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations
12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 20 12.1. Kerberos Second-Factor Types
12.1.1. Registration Template . . . . . . . . . . . . . . . 20 12.1.1. Registration Template
12.1.2. Initial Registry Contents . . . . . . . . . . . . . 20 12.1.2. Initial Registry Contents
12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 21 12.2. Kerberos SPAKE Groups
12.2.1. Registration Template . . . . . . . . . . . . . . . 21 12.2.1. Registration Template
12.2.2. Initial Registry Contents . . . . . . . . . . . . . 21 12.2.2. Initial Registry Contents
13. Normative References . . . . . . . . . . . . . . . . . . . . 23 13. References
14. Informative References . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References
Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 26 Appendix A. ASN.1 Module
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 Appendix B. SPAKE M and N Value Selection
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix C. Test Vectors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
The Kerberos protocol [RFC4120] commonly uses password-derived long- The Kerberos protocol [RFC4120] commonly uses password-derived long-
term keys to secure the initial authentication exchange between a term keys to secure the initial authentication exchange between a
Kerberos client and a Key Distribution Center (KDC). As noted in Kerberos client and a Key Distribution Center (KDC). As noted in
Section 10 of [RFC4120], an attacker can perform an offline Section 10 of [RFC4120], an attacker can perform an offline
dictionary attack against the password, either by initiating an dictionary attack against the password; this is performed either by
authentication exchange to a principal for which the KDC does not initiating an authentication exchange to a principal for which the
require pre-authentication, or after eavesdropping on a legitimate KDC does not require pre-authentication or after eavesdropping on a
authentication exchange that uses encrypted timestamp pre- legitimate authentication exchange that uses encrypted timestamp pre-
authentication (Section 5.2.7.2 of [RFC4120]). authentication (Section 5.2.7.2 of [RFC4120]).
This document defines a pre-authentication mechanism that This document defines a pre-authentication mechanism that
authenticates using long-term keys but is resistant to offline authenticates using long-term keys but is resistant to offline
dictionary attacks. The mechanism additionally enables the use of dictionary attacks. The mechanism additionally enables the use of
second factor authentication without the need for a separately- second-factor authentication without the need for a separately
established secure channel, by leveraging the trust relationship established secure channel, by leveraging the trust relationship
established by the shared long-term key. established by the shared long-term key.
1.1. Properties of PAKE 1.1. Properties of PAKE
Password authenticated key exchange (PAKE) algorithms [RFC8125] Password-authenticated key exchange (PAKE) algorithms [RFC8125]
provide several properties which defend against offline dictionary provide several properties that defend against offline dictionary
attacks and make them ideal for use in a Kerberos pre-authentication attacks and make them ideal for use in a Kerberos pre-authentication
mechanism. mechanism.
1. Each side of the exchange contributes entropy. 1. Each side of the exchange contributes entropy.
2. Passive attackers cannot determine the shared key. 2. Passive attackers cannot determine the shared key.
3. Active attackers cannot perform a machine-in-the-middle attack. 3. Active attackers cannot perform a machine-in-the-middle attack.
These properties of PAKE allow us to establish high-entropy 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). the passwords used are weak (low entropy).
1.2. PAKE Algorithm Selection 1.2. PAKE Algorithm Selection
The SPAKE algorithm (defined in [SPAKE]) works by encrypting the The SPAKE algorithm (defined in [SPAKE]) works by encrypting the
public keys of a Diffie-Hellman key exchange with a shared secret. public keys of a Diffie-Hellman (DH) key exchange with a shared
SPAKE is selected for this pre-authentication mechanism for the secret. SPAKE is selected for this pre-authentication mechanism for
following properties: the following properties:
1. Because SPAKE's encryption method ensures that the result is a 1. SPAKE's encryption method ensures that the result is a member of
member of the underlying group, it can be used with elliptic the underlying group, so it can be used with elliptic curve
curve cryptography, which is believed to provide equivalent cryptography, which is believed to provide equivalent security
security levels to finite-field DH key exchange at much smaller levels to finite-field DH key exchange at much smaller key sizes.
key sizes.
2. It can compute the shared key after just one message from each 2. It can compute the shared key after just one message from each
party, minimizing the need for additional round trips and state. party, minimizing the need for additional round trips and state.
3. It requires a small number of group operations, and can therefore 3. It requires a small number of group operations; therefore, it can
be implemented simply and efficiently. be implemented simply and efficiently.
1.3. PAKE and Two-Factor Authentication 1.3. PAKE and Two-Factor Authentication
Using PAKE in a pre-authentication mechanism also has another benefit Using PAKE in a pre-authentication mechanism also has another benefit
when used as a component of two-factor authentication (2FA). 2FA when used as a component of two-factor authentication (2FA). 2FA
methods often require the secure transfer of plaintext material to 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 challenge/response signatures, and biometric data. Encrypting this
data using the long-term secret results in packets that are data using the long-term secret results in packets that are
vulnerable to offline brute-force attack on the password, using vulnerable to offline brute-force attacks on the password, using
either an authentication tag or statistical properties of the 2FA either an authentication tag or statistical properties of the 2FA
credentials to determine whether a password guess is correct. credentials to determine whether a password guess is correct.
In the One-Time Password pre-authentication [RFC6560] specification, In "One-Time Password (OTP) Pre-Authentication" [RFC6560], this
this problem is mitigated by using flexible authentication secure problem is mitigated using flexible authentication secure tunneling
tunneling (FAST) (Section 5.4 of [RFC6113]), which uses a secondary (FAST) (Section 5.4 of [RFC6113]), which uses a secondary trust
trust relationship to create a secure encryption channel within which relationship to create a secure encryption channel within which pre-
pre-authentication data can be sent. However, the requirement for a authentication data can be sent. However, the requirement for a
secondary trust relationship has proven to be cumbersome to deploy secondary trust relationship has proven to be cumbersome to deploy
and often introduces third parties into the trust chain (such as and often introduces third parties into the trust chain (such as
certification authorities). These requirements make it difficult to certification authorities). These requirements make it difficult to
enable FAST without manual configuration of client hosts. SPAKE pre- enable FAST without manual configuration of client hosts. In
authentication, in contrast, can create a secure encryption channel contrast, SPAKE pre-authentication, can create a secure encryption
implicitly, using the key exchange to negotiate a high-entropy channel implicitly, using the key exchange to negotiate a high-
encryption key. This key can then be used to securely encrypt 2FA entropy encryption key. This key can then be used to securely
plaintext data without the need for a secondary trust relationship. encrypt 2FA plaintext data without the need for a secondary trust
Further, if the second factor verifiers are sent at the same time as relationship. Further, if the second-factor verifiers are sent at
the first factor verifier, and the KDC is careful to prevent timing the same time as the first-factor verifier, and the KDC is careful to
attacks, then an online brute-force attack cannot be used to attack prevent timing attacks, then an online brute-force attack cannot be
the factors separately. used to attack the factors separately.
For these reasons, this document departs from the advice given in For these reasons, this document departs from the advice given in
Section 1 of RFC 6113 [RFC6113] which states that "Mechanism Section 1 of [RFC6113], which states: "Mechanism designers should
designers should design FAST factors, instead of new pre- design FAST factors, instead of new pre-authentication mechanisms
authentication mechanisms outside of FAST." However, the SPAKE pre- outside of FAST." However, the SPAKE pre-authentication mechanism
authentication mechanism does not intend to replace FAST, and may be does not intend to replace FAST and may be used with it to further
used with it to further conceal the metadata of the Kerberos conceal the metadata of the Kerberos messages.
messages.
1.4. SPAKE Overview 1.4. SPAKE Overview
The SPAKE algorithm can be broadly described in a series of four The SPAKE algorithm can be broadly described in a series of four
steps: steps:
1. Calculation and exchange of the public key 1. Calculation and exchange of the public key
2. Calculation of the shared secret (K) 2. Calculation of the shared secret (K)
3. Derivation of an encryption key (K') 3. Derivation of an encryption key (K')
4. Verification of the derived encryption key (K') 4. Verification of the derived encryption key (K')
In this mechanism, key verification happens implicitly by a 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 no second factor is required. This mechanism uses a tailored method
of deriving encryption keys from the calculated shared secret K, for of deriving encryption keys from the calculated shared secret K, for
several reasons: to fit within the framework of [RFC3961], to ensure several reasons:
negotiation integrity using a transcript hash, to derive different
keys for each use, and to bind the KDC-REQ-BODY to the pre- * to fit within the framework of [RFC3961],
authentication exchange.
* to ensure negotiation integrity using a transcript hash,
* to derive different keys for each use, and
* to bind the KDC-REQ-BODY to the pre-authentication exchange.
2. Document Conventions 2. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document refers to numerous terms and protocol messages defined This document refers to numerous terms and protocol messages defined
in [RFC4120]. in [RFC4120].
The terms "encryption type", "key generation seed length", and The terms "encryption type", "key generation seed length", and
"random-to-key" are defined in [RFC3961]. "random-to-key" are defined in [RFC3961].
The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED",
"KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre- "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre-
authentication facility", and "authentication set" are defined in authentication facility", and "authentication set" are defined in
[RFC6113]. [RFC6113].
The [SPAKE] paper defines SPAKE as a family of two key exchange [SPAKE] defines SPAKE as a family of two key-exchange algorithms
algorithms differing only in derivation of the final key. This differing only in derivation of the final key. This mechanism uses a
mechanism uses a derivation similar to the second algorithm (SPAKE2). derivation similar to the second algorithm (SPAKE2). For simplicity,
For simplicity, this document refers to the algorithm as "SPAKE". this document refers to the algorithm as "SPAKE".
The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and The terms "Abstract Syntax Notation One (ASN.1)" and "Distinguished
[CCITT.X690.2002] respectively. Encoding Rules (DER)" are defined in [ITU-T.X680.2021] and
[ITU-T.X690.2021], respectively.
When discussing operations within algebraic groups, this document When discussing operations within algebraic groups, this document
uses additive notation (as described in Section 2.2 of [RFC6090]). uses additive notation (as described in Section 2.2 of [RFC6090]).
Group elements are denoted with uppercase letters, while scalar Group elements are denoted with uppercase letters, while scalar
multiplier values are denoted with lowercase letters. multiplier values are denoted with lowercase letters.
3. Prerequisites 3. Prerequisites
3.1. PA-ETYPE-INFO2 3.1. PA-ETYPE-INFO2
This mechanism requires the initial KDC pre-authentication state to 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 PA-ETYPE- pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE-
INFO2 value containing a single ETYPE-INFO2-ENTRY, following the INFO2 value containing a single ETYPE-INFO2-ENTRY, following the
guidance in Section 2.1 of [RFC6113]. PA-ETYPE-INFO2 is specified in guidance in Section 2.1 of [RFC6113]. PA-ETYPE-INFO2 is specified in
Section 5.2.7.5 of [RFC4120]. Section 5.2.7.5 of [RFC4120].
3.2. Cookie Support 3.2. Cookie Support
KDCs which implement SPAKE pre-authentication MUST have some secure KDCs that implement SPAKE pre-authentication MUST have some secure
mechanism for retaining state between AS-REQs. For stateless KDC mechanism for retaining state between authentication service requests
implementations, this method will most commonly be an encrypted PA- (AS-REQs). For stateless KDC implementations, this method will most
FX-COOKIE. Clients which implement SPAKE pre-authentication MUST commonly be an encrypted PA-FX-COOKIE. Clients that implement SPAKE
support PA-FX-COOKIE, as described in Section 5.2 of [RFC6113]. pre-authentication MUST support PA-FX-COOKIE, as described in
Section 5.2 of [RFC6113].
3.3. More Pre-Authentication Data Required 3.3. More Pre-authentication Data Required
Both KDCs and clients which implement SPAKE pre-authentication MUST Both KDCs and clients that implement SPAKE pre-authentication MUST
support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described
in Section 5.2 of [RFC6113]. in Section 5.2 of [RFC6113].
4. SPAKE Pre-Authentication Message Protocol 4. SPAKE Pre-authentication Message Protocol
This mechanism uses the reply key and provides the Client This mechanism uses the reply key and provides the client
Authentication and Strengthening Reply Key pre-authentication authentication and strengthening reply key pre-authentication
facilities (Section 3 of [RFC6113]). When the mechanism completes facilities (Section 3 of [RFC6113]). When the mechanism 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- exchange. This mechanism also ensures the integrity of the KDC-REQ-
BODY contents. This mechanism can be used in an authentication set; BODY contents. This mechanism can be used in an authentication set;
no pa-hint value is required or defined. no pa-hint value is required or defined.
This mechanism negotiates a choice of group for the SPAKE algorithm. This mechanism negotiates a choice of group for the SPAKE algorithm.
Groups are defined in the IANA "Kerberos SPAKE Groups" registry Groups are defined in the "Kerberos SPAKE Groups" registry created by
created by this document. Each group definition specifies an this document (see Section 12.2). Each group definition specifies an
associated hash function, which will be used for transcript associated hash function, which will be used for transcript
protection and key derivation. Clients and KDCs MUST implement the protection and key derivation. Clients and KDCs MUST implement the
edwards25519 group, but MAY choose not to offer or accept it by edwards25519 group, but they MAY choose not to offer or accept it by
default. default.
This section will describe the flow of messages when performing SPAKE The subsections that follow will describe the flow of messages when
pre-authentication. We will begin by explaining the most verbose performing SPAKE pre-authentication. We will begin by explaining the
version of the protocol which all implementations MUST support. Then most verbose version of the protocol, which all implementations MUST
we will describe several optional optimizations to reduce round- support. Then, we will describe several optional optimizations to
trips. reduce round trips.
Mechanism messages are communicated using PA-DATA elements within the Mechanism messages are communicated using PA-DATA elements within the
padata field of KDC-REQ messages or within the METHOD-DATA in the 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 e-data field of KRB-ERROR messages. All PA-DATA elements for this
mechanism MUST use the following padata-type: mechanism MUST use the following padata-type:
PA-SPAKE 151 PA-SPAKE 151
The padata-value for all PA-SPAKE PA-DATA values MUST be empty or The padata-value for all PA-SPAKE PA-DATA values MUST be empty or
contain a DER encoding for the ASN.1 type PA-SPAKE. contain a DER encoding for the ASN.1 type PA-SPAKE.
skipping to change at page 7, line 42 skipping to change at line 326
challenge [1] SPAKEChallenge, challenge [1] SPAKEChallenge,
response [2] SPAKEResponse, response [2] SPAKEResponse,
encdata [3] EncryptedData, encdata [3] EncryptedData,
... ...
} }
4.1. First Pass 4.1. First Pass
The SPAKE pre-authentication exchange begins when the client sends an The SPAKE pre-authentication exchange begins when the client sends an
initial authentication service request (AS-REQ) without pre- initial authentication service request (AS-REQ) without pre-
authentication data. Upon receipt of this AS-REQ, a KDC which 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 SHOULD (unless
configuration indicates otherwise) reply with a 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 elements). This message indicates to the client that the KDC
supports SPAKE pre-authentication. supports SPAKE pre-authentication.
4.2. Second Pass 4.2. Second Pass
Once the client knows that the KDC supports SPAKE pre-authentication Once the client knows that the KDC supports SPAKE pre-authentication
and the client desires to use it, the client will generate a new AS- and the client wants to use it, the client will generate a new AS-REQ
REQ message containing a PA-SPAKE PA-DATA element using the support 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 prefers for the SPAKE operation. The group numbers are defined in
the IANA "Kerberos SPAKE Groups" registry created by this document. the "Kerberos SPAKE Groups" registry (see Section 12.2). The group's
The groups sequence is ordered from the most preferred group to the sequence is ordered from the most preferred group to the least
least preferred group. preferred group.
SPAKESupport ::= SEQUENCE { SPAKESupport ::= SEQUENCE {
groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
... ...
} }
Upon receipt of the support message, the KDC will select a group. Upon receipt of the support message, the KDC will select a group.
The KDC SHOULD choose a group from the groups provided by the support The KDC SHOULD choose a group from the groups provided by the support
message. However, if the support message does not contain any group message. However, if the support message does not contain any group
that is supported by the KDC, the KDC MAY select another group in that is supported by the KDC, the KDC MAY select another group in
hopes that the client might support it. Otherwise, the KDC MUST hopes that the client might support it. Otherwise, the KDC MUST
respond with a KDC_ERR_PREAUTH_FAILED error. respond with a KDC_ERR_PREAUTH_FAILED error.
The group selection determines the group order, which shall be a The group selection determines the group order, which shall be a
large prime p multiplied by a small cofactor h (possibly 1), as well large prime p multiplied by a small cofactor h (possibly 1), a
as a generator P of a prime-order subgroup and two masking points M generator P of a prime-order subgroup, and two masking points M and
and N. The KDC selects a random integer x in the range 0 <= x < h*p, N. The KDC selects a random integer x in the range 0 <= x < h*p,
which MUST be divisible by h. The KDC computes a public key which MUST be divisible by h. The KDC computes a public key
T=x*P+w*M, where w is computed from the initial reply key according T=x*P+w*M, where w is computed from the initial reply key according
to Section 5. to Section 5.
The KDC will reply to the client with a The KDC will reply to the client with a
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA- KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-
DATA element using the challenge choice. DATA element using the challenge choice.
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,
... ...
} }
The group field indicates the KDC-selected group used for all SPAKE The group field indicates the KDC-selected group used for all SPAKE
calculations as defined in the IANA "Kerberos SPAKE Groups" registry calculations as defined in the "Kerberos SPAKE Groups" registry (see
created by this document. Section 12.2).
The pubkey field indicates the KDC's public key T, serialized The pubkey field indicates the KDC's public key T, serialized
according to Section 5. according to Section 5.
The factors field contains an unordered list of second factors which The factors field contains an unordered list of second factors, which
can be used to complete the authentication. Each second factor is can be used to complete the authentication. Each second factor is
represented by a SPAKESecondFactor. represented by a SPAKESecondFactor.
SPAKESecondFactor ::= SEQUENCE { SPAKESecondFactor ::= SEQUENCE {
type [0] Int32, type [0] Int32,
data [1] OCTET STRING OPTIONAL data [1] OCTET STRING OPTIONAL
} }
The type field is a unique integer which identifies the second factor The type field is a unique integer that identifies the second-factor
type. The factors field of SPAKEChallenge MUST NOT contain more than type. The factors field of SPAKEChallenge MUST NOT contain more than
one SPAKESecondFactor with the same type value. one SPAKESecondFactor with the same type value.
The data field contains optional challenge data. The contents in 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 Section 10.2. see Section 10.2.
The client and KDC will each initialize a transcript hash (Section 6) The client and KDC will each initialize a transcript hash (Section 6)
using the hash function associated with the chosen group, and update using the hash function associated with the chosen group and update
it with the concatenation of the DER-encoded PA-SPAKE messages sent it with the concatenation of the DER-encoded PA-SPAKE messages sent
by the client and the KDC. by the client and the KDC.
4.3. Third Pass 4.3. Third Pass
Upon receipt of the challenge message, the client observes which 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 <= x < h*p, T. The client selects a random integer y in the range 0 <= x < h*p,
which MUST be divisible by h. The client computes a public key which MUST 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 S=y*P+w*N, where w is computed from the initial reply key according
to Section 5. The client computes a shared group element to Section 5. The client computes a shared group element
K=y*(T-w*M). K=y*(T-w*M).
The client will then choose one of the second factor types listed in The client will then choose one of the second-factor types listed in
the factors field of the challenge message and gather whatever data the factors field of the challenge message and gather whatever data
is required for the chosen second factor type, possibly using the is 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. containing a PA-SPAKE PA-DATA element using the response choice.
SPAKEResponse ::= SEQUENCE { SPAKEResponse ::= SEQUENCE {
pubkey [0] OCTET STRING, pubkey [0] OCTET STRING,
factor [1] EncryptedData, -- SPAKESecondFactor factor [1] EncryptedData, -- SPAKESecondFactor
... ...
} }
The client and KDC will update the transcript hash with the pubkey The client and KDC will update the transcript hash with the pubkey
value, and use the resulting hash for all encryption key derivations. value and use the resulting hash for all encryption key derivations.
The pubkey field indicates the client's public key S, serialized The pubkey field indicates the client's public key S, serialized
according to Section 5. according to Section 5.
The factor field indicates the client's chosen second factor data. The factor field indicates the client's chosen second-factor data.
The key for this field is K'[1] as specified in Section 7. The kvno The key for this field is K'[1] (specified in Section 7). The kvno
field of the EncryptedData sequence is omitted. The key usage number field of the EncryptedData sequence is omitted. The key usage number
for the encryption is KEY_USAGE_SPAKE. The plain text inside the for the encryption is KEY_USAGE_SPAKE. The plaintext inside the
EncryptedData is an encoding of SPAKESecondFactor. Once decoded, the EncryptedData is an encoding of the SPAKESecondFactor. Once decoded,
SPAKESecondFactor contains the type of the second factor and any the SPAKESecondFactor provides the type of the second factor and any
optional data used. The contents of the data field will depend on optional data used. The contents of the data field will depend on
the second factor type chosen. The client MUST NOT send a response the second-factor type chosen. The client MUST NOT send a response
containing a second factor type which was not listed in the factors containing a second-factor type that was not listed in the factors
field of the challenge message. field of the challenge message.
When the KDC receives the response message from the client, it 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 validated. The KDC then validates the second factor. If either
factor fails to validate, the KDC MUST respond with a factor fails to validate, the KDC MUST respond with a
KDC_ERR_PREAUTH_FAILED error. KDC_ERR_PREAUTH_FAILED error.
If validation of the second factor requires further round-trips, the 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 MUST reply to the client with a
containing a PA-SPAKE PA-DATA element using the encdata choice. The KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-
kvno field of the EncryptedData sequence is omitted. The key for the DATA element using the encdata choice. The kvno field of the
EncryptedData value is K'[2] as specified in Section 7, and the key EncryptedData sequence is omitted. The key for the EncryptedData
usage number is KEY_USAGE_SPAKE. The plain text of this message value is K'[2] (specified in Section 7), and the key usage number is
contains a DER-encoded SPAKESecondFactor message. As before, the KEY_USAGE_SPAKE. The plaintext of this message contains a DER-
type field of this message will contain the second factor type, and encoded SPAKESecondFactor message. As before, the type field of this
the data field will optionally contain second factor type specific message will contain the second-factor type and the data field will,
data. optionally, contain data specific to the second-factor type.
4.4. Subsequent Passes 4.4. Subsequent Passes
Any number of additional round trips may occur using the encdata 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 type. If a client receives a PA-SPAKE PA-DATA element using factor type. If a client receives a PA-SPAKE PA-DATA element using
the encdata choice from the KDC, it MUST reply with a subsequent AS- the 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 REQ with a PA-SPAKE PA-DATA element using the encdata choice or abort
exchange. the AS exchange.
The key for client-originated encdata messages in subsequent passes The key for client-originated encdata messages in subsequent passes
is K'[3] as specified in Section 7 for the first subsequent pass, is K'[3] (specified in Section 7) for the first subsequent pass,
K'[5] for the second, and so on. The key for KDC-originated encdata K'[5] for the second, and so on. The key for KDC-originated encdata
messages is K'[4] for the first subsequent pass, K'[6] for the messages is K'[4] for the first subsequent pass, K'[6] for the
second, and so on. second, and so on.
4.5. Reply Key Strengthening 4.5. Reply Key Strengthening
When the KDC has successfully validated both factors, the reply key When the KDC has successfully validated both factors, the reply key
is strengthened and the mechanism is complete. To strengthen the is strengthened and the mechanism is complete. The strengthening of
reply key, the client and KDC replace it with K'[0] as specified in the reply key is accomplished by the client and KDC replacing it with
Section 7. The KDC then replies with a KDC-REP message, or continues K'[0] (as specified in Section 7). The KDC then replies with a KDC-
on to the next mechanism in the authentication set. There is no REP message or continues on to the next mechanism in the
final PA-SPAKE PA-DATA message from the KDC to the client. authentication set. There is no final PA-SPAKE PA-DATA message from
the KDC to the client.
Reply key strengthening occurs only once at the end of the exchange. Reply key strengthening occurs only once: at the end of the exchange.
The client and KDC MUST use the initial reply key as the base key for The client and KDC MUST use the initial reply key as the base key for
all K'[n] derivations. all K'[n] derivations.
4.6. Optimizations 4.6. Optimizations
The full protocol has two possible optimizations. The full protocol has two possible optimizations.
First, the KDC MAY reply to the initial AS-REQ (containing no pre- First, the KDC MAY reply to the initial AS-REQ (containing no pre-
authentication data) with a PA-SPAKE PA-DATA element using the authentication data) with a PA-SPAKE PA-DATA element using the
challenge choice, instead of an empty padata-value. In this case, challenge choice instead of an empty padata-value. In this case, the
the KDC optimistically selects a group which the client may not KDC optimistically selects a group that the client may not support.
support. If the group chosen by the challenge message is supported If the group chosen by the challenge message is supported by the
by the client, the client MUST skip to the third pass by issuing an client, the client MUST skip to the third pass by issuing an AS-REQ
AS-REQ with a PA-SPAKE message using the response choice. In this with a PA-SPAKE message using the response choice. In this case, no
case no SPAKESupport message is sent by the client, so the first SPAKESupport message is sent by the client, so the first update to
update to the transcript hash contains only the KDC's optimistic the transcript hash contains only the KDC's optimistic challenge. If
challenge. If the KDC's chosen group is not supported by the client, the KDC's chosen group is not supported by the client, the client
the client MUST continue to the second pass. In this case both the MUST continue to the second pass. In this case, both the client and
client and KDC MUST reinitialize the transcript hash for the client's KDC MUST reinitialize the transcript hash for the client's support
support message. Clients MUST support this optimization. message. Clients MUST support this optimization.
Second, clients MAY skip the first pass and send an AS-REQ with a PA- Second, clients MAY skip the first pass and send an AS-REQ with a PA-
SPAKE PA-DATA element using the support choice. If the KDC accepts SPAKE PA-DATA element using the support choice. If the KDC accepts
the support message and generates a challenge, it MUST include a PA- the support message and generates a challenge, it MUST include a PA-
ETYPE-INFO2 value within the METHOD-DATA of the 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
incompatible with SPAKE or because it does not support any of the is incompatible with SPAKE or because it does not support any of the
client's groups) but can offer other pre-authentication mechanisms, client's groups) but can offer other pre-authentication mechanisms,
it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing the KDC MUST respond with a KDC_ERR_PREAUTH_FAILED error containing
METHOD-DATA for the available mechanisms. A client supporting this METHOD-DATA for the available mechanisms. A client supporting this
optimization MUST continue after a KDC_ERR_PREAUTH_FAILED error as optimization MUST continue after a KDC_ERR_PREAUTH_FAILED error as
described in Section 2 of [RFC6113]. KDCs MUST support this described in Section 2 of [RFC6113]. KDCs MUST support this
optimization. optimization.
5. SPAKE Parameters and Conversions 5. SPAKE Parameters and Conversions
Group elements are converted to and from octet strings using the Group elements are converted to and from octet strings using the
serialization method defined in the IANA "Kerberos SPAKE Groups" serialization method defined in the "Kerberos SPAKE Groups" registry
registry created by this document. (see Section 12.2).
The SPAKE algorithm requires constants M and N for each group. These 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 (see
created by this document. Section 12.2).
The SPAKE algorithm requires a shared secret input w to be used as a The SPAKE algorithm requires a shared secret input w to be used as a
scalar multiplier. This value MUST be produced from the initial scalar multiplier. This value MUST be produced from the initial
reply key as follows: reply key as follows:
1. Determine the length of the multiplier octet string as defined in 1. 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 Section 12.2).
document.
2. Compose a pepper string by concatenating the string "SPAKEsecret" 2. Compose a pepper string by concatenating the string "SPAKEsecret"
and the group number as a big-endian four-byte two's complement and the group number as a big-endian four-byte two's complement
binary number. binary number.
3. Produce an octet string of the required length using PRF+(K, 3. 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
Section 5.1 of [RFC6113]. in Section 5.1 of [RFC6113].
4. Convert the octet string to a multiplier scalar using the 4. 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. Groups" registry (see Section 12.2).
The KDC chooses a secret scalar value x and the client chooses a The KDC chooses a secret scalar value x and the client chooses a
secret scalar value y. As required by the SPAKE algorithm, these secret scalar value y. As required by the SPAKE algorithm, these
values are chosen randomly and uniformly. The KDC and client MUST values are chosen randomly and uniformly. The KDC and client MUST
NOT reuse x or y values for authentications involving different NOT reuse x or y values for authentications involving different
initial reply keys (see Section 10.4). initial reply keys (see Section 10.4).
6. Transcript Hash 6. Transcript Hash
The transcript hash is an octet string of length equal to the output 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
initial value consists of all bits set to zero. bits are set to zero in the initial value.
When the transcript hash is updated with an octet string input, the 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. old value and the input.
In the normal message flow or with the second optimization described In the normal message flow or with the second optimization described
in Section 4.6, the transcript hash is first updated with the in Section 4.6, the transcript hash is:
concatenation of the client's support message and the KDC's
challenge, and then updated a second time with the client's pubkey 1. updated with the concatenation of the client's support message
value. It therefore incorporates the client's supported groups, the and the KDC's challenge, then
KDC's chosen group, the KDC's initial second-factor messages, and the
2. updated a second time with the client's pubkey value.
Therefore, it incorporates the client's supported groups, 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, client and KDC public values. Once the transcript hash is finalized,
it is used without change for all key derivations (Section 7). In it is used without change for all key derivations (Section 7). In
particular, encrypted second-factor messages are not included in the particular, encrypted second-factor messages are not included in the
transcript hash. transcript hash.
If the first optimization described in Section 4.6 is used If the first optimization described in Section 4.6 is used
successfully, the transcript hash is updated first with the KDC's successfully, the transcript hash is first updated with the KDC's
challenge message, and second with the client's pubkey value. challenge message and updated a second time with the client's pubkey
value.
If first optimization is used unsuccessfully (i.e. the client does If the first optimization is used unsuccessfully (i.e., the client
not accept the KDC's selected group), the transcript hash is computed does not accept the KDC's selected group), the transcript hash is
as in the normal message flow, without including the KDC's optimistic computed as in the normal message flow, without including the KDC's
challenge. optimistic challenge.
7. Key Derivation 7. Key Derivation
Implementations MUST NOT use the shared group element (denoted by K) Implementations MUST NOT use the shared group element (denoted by K)
directly for any cryptographic operation. Instead, the SPAKE result directly for any cryptographic operation. Instead, the SPAKE result
is used to derive keys K'[n] as defined in this section. is used to derive keys K'[n] (defined in this section).
First, compute the hash function associated with the selected group First, compute the hash function associated with the selected group
over the concatenation of the following values: over the concatenation of the following values:
* The fixed string "SPAKEkey". * The fixed string "SPAKEkey".
* The group number as a big-endian four-byte two's complement binary * The group number as a big-endian four-byte two's complement binary
number. number.
* The encryption type of the initial reply key as a big-endian four- * The encryption type of the initial reply key as a big-endian four-
byte two's complement binary number. byte two's complement binary number.
* The PRF+ output used to compute the initial secret input w as * The PRF+ output used to compute the initial secret input w (as
specified in Section 5. specified in Section 5).
* The SPAKE result K, converted to an octet string as specified in * The SPAKE result K, converted to an octet string (as specified in
Section 5. Section 5).
* The transcript hash. * The transcript hash.
* The KDC-REQ-BODY encoding for the request being sent or responded * The KDC-REQ-BODY encoding for the request being sent or responded
to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST
be used. be used.
* The value n as a big-endian four-byte unsigned binary number. * The value n as a big-endian, four-byte, and unsigned binary
number.
* A single-byte block counter, with the initial value 0x01. * A single-byte block counter with the initial value 0x01.
If the hash output is too small for the encryption type's key If the hash output is too small for the encryption type's key
generation seed length, the block counter value is incremented and generation seed length, the block counter value is incremented and
the hash function re-computed to produce as many blocks as are the hash function is recomputed to produce as many blocks as are
required. The result is truncated to the key generation seed length, required. The result is truncated to the key generation seed length,
and the random-to-key function is used to produce an intermediate key and the random-to-key function is used to produce an intermediate key
with the same encryption type as the initial reply key. with the same encryption type as the initial reply key.
The key K'[n] has the same encryption type as the initial reply key, 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 "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in Section 5.1 of
[RFC6113]. [RFC6113].
8. Second Factor Types 8. Second-Factor Types
This document defines one second factor type: This document defines one second-factor type:
SF-NONE 1 SF-NONE 1
This second factor type indicates that no second factor is used. This second-factor type indicates that no second factor is used.
Whenever a SPAKESecondFactor is used with SF-NONE, the data field Whenever a SPAKESecondFactor is used with SF-NONE, the data field
MUST be omitted. The SF-NONE second factor always successfully MUST be omitted. The SF-NONE second factor always successfully
validates. validates.
9. Hint for Authentication Sets 9. Hint for Authentication Sets
If a KDC offers SPAKE pre-authentication as part of an authentication If a KDC offers SPAKE pre-authentication as part of an authentication
set (Section 5.3 of [RFC6113]), it SHOULD provide a pa-hint value set (Section 5.3 of [RFC6113]), it SHOULD provide a pa-hint value
containing the DER encoding of the ASN.1 type PA-SPAKE-HINT, to help containing the DER encoding of the ASN.1 type PA-SPAKE-HINT. This
the client determine whether SPAKE pre-authentication is likely to helps the client determine whether SPAKE pre-authentication is likely
succeed if the authentication set is chosen. to succeed if the authentication set is chosen.
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
} }
The groups field indicates the KDC's supported groups. The factors The groups field indicates the KDC's supported groups. The factors
field indicates the KDC's supported second factors. The KDC MAY omit field indicates the KDC's supported second factors. The KDC MAY omit
the data field of values in the factors list. the data field of values in the factors list.
A KDC MUST NOT include a PA-SPAKE-HINT message directly in a pa-value A KDC MUST NOT 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 SHOULD include a hint if SPAKE pre-authentication is offered as the
second or later element of an authentication set. second or later element of an authentication set.
The PA-SPAKE-HINT message is not part of the transcript, and does not The PA-SPAKE-HINT message is not part of the transcript, and it does
replace any part of the SPAKE message flow. not replace any part of the SPAKE message flow.
10. Security Considerations 10. Security Considerations
10.1. SPAKE Computations 10.1. SPAKE Computations
The deserialized public keys S and T MUST be verified to be elements The deserialized public keys S and T MUST be verified to be elements
of the group, to prevent invalid curve attacks. It is not necessary of the group to prevent invalid curve attacks. It is not necessary
to verify that they are members of the prime-order subgroup, as the 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. cofactor h.
The aforementioned cofactor multiplication is accomplished by The aforementioned cofactor multiplication is accomplished by
choosing private scalars x and y which are divisible by the cofactor. choosing private scalars x and y, which are divisible by the
If the client or KDC chooses a scalar which might not be divisible by cofactor. If the client or KDC chooses a scalar that might not be
the cofactor, an attacker might be able to coerce values of K which divisible by the cofactor, an attacker might be able to coerce values
are not members of the prime-order subgroup, and deduce a limited of K that are not members of the prime-order subgroup and deduce a
amount of information about w from the order of K. limited amount of information about w from the order of K.
The scalars x and y MUST be chosen uniformly, and must not be reused The scalars x and y MUST be chosen uniformly. They MUST NOT be
for different initial reply keys. If an x or y value is reused for reused for different initial reply keys. If an x or y value is
pre-authentications involving two different initial reply keys, an reused for pre-authentications involving two different initial reply
attacker who observes both authentications and knows one of the keys, an attacker who observes both authentications and knows one of
initial reply keys can conduct an offline dictionary attack to the initial reply keys can conduct an offline dictionary attack to
recover the other one. recover the other one.
The M and N values for a group MUST NOT have known discrete logs. An The M and N values for a group MUST NOT have known discrete 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. without multiplying a known value by the generator P.
10.2. Unauthenticated Plaintext 10.2. Unauthenticated Plaintext
This mechanism includes unauthenticated plaintext in the support and 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 keys. Downgrade attacks on support and challenge messages will
result in the client and KDC deriving different reply keys and result in the client and KDC deriving different reply keys and
EncryptedData keys. The KDC-REQ-BODY contents are also incorporated EncryptedData keys. The KDC-REQ-BODY contents are also incorporated
into key derivation, ensuring their integrity. The unauthenticated into key derivation, ensuring their integrity. The unauthenticated
plaintext in the KDC-REP message is not protected by this mechanism. plaintext in the KDC-REP message is not protected by this mechanism.
Unless FAST is used, the factors field of a challenge message is not Unless FAST is used, the factors field of a challenge message is not
integrity-protected until the response is verified. Second factor integrity protected until the response is verified. Second-factor
types MUST account for this when specifying the semantics of the data types MUST account for this when specifying the semantics of the data
field. In particular, second factor data in the challenge should not field. In particular, second-factor data in the challenge should not
be included in user prompts, as it could be modified by an attacker be included in user prompts: it could be modified by an attacker to
to contain misleading or offensive information. contain misleading or offensive information.
Unless FAST is used, the factors field of a challenge message is 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. factor is required for the client.
Subsequent factor data, including the data in the response, are Subsequent factor data, including the data in the response, are
encrypted in a derivative of the shared secret K. Therefore, it is encrypted in a derivative of the shared secret K. Therefore, it is
not possible to exploit the untrustworthiness of the challenge to not possible to exploit the untrustworthiness of the challenge to
turn the client into an encryption or signing oracle for the second turn the client into an encryption or signing oracle for the second-
factor credentials, unless the attacker knows the client's long-term factor credentials, unless the attacker knows the client's long-term
key. key.
Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE 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
protected by the transcript hash. Since hints do not replace any when SPAKE is advertised in authentication sets. Since hints do not
part of the message flow, manipulation of hint messages can only replace any part of the message flow, manipulation of hint messages
affect the client's decision to use or not use an authentication set, can only affect the client's decision to use or not use an
which could more easily be accomplished by removing authentication authentication set, which could more easily be accomplished by
sets entirely. removing authentication sets entirely.
10.3. Side Channels 10.3. Side Channels
An implementation of the SPAKE pre-authentication mechanism can have 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 correct. whether one of the factors was correct unless both are correct.
Indistinguishability is only maintained if the second factor can be Indistinguishability is only maintained if the second factor can be
validated solely based on the data in the response; the use of validated solely based on the data in the response; the use of
additional round trips will reveal to the attacker whether the long- additional round trips will reveal to the attacker whether the long-
term key is correct. Indistinguishability also requires that there term key is correct. Indistinguishability also requires that there
are no side channels. When processing a response message, whether or are no side channels. When the KDC processes a response message,
not the KDC successfully decrypts the factor field, it must reply whether or not it decrypts the factor field, it must reply with the
with the same error fields, take the same amount of time, and make same error fields, take the same amount of time, and make the same
the same observable communications to other servers. observable communications to other servers.
Both the size of the EncryptedData and the number of EncryptedData Both the size of the EncryptedData and the number of EncryptedData
messages used for second-factor data (including the factor field of messages used for second-factor data (including the factor field of
the SPAKEResponse message and messages using the encdata PA-SPAKE the SPAKEResponse message and messages using the encdata PA-SPAKE
choice) may reveal information about the second factor used in an choice) may reveal information about the second factor used in an
authentication. Care should be taken to keep second factor messages authentication. Care should be taken to keep second-factor messages
as small and as few as possible. as small and as few as possible.
Any side channels in the creation of the shared secret input w, or in 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 the the multiplications wM and wN, could allow an attacker to recover the
client long-term key. Implementations MUST take care to avoid side client long-term key. Implementations MUST take care to avoid side
channels, particularly timing channels. Generation of the secret channels, particularly timing channels. Generation of the secret
scalar values x and y need not take constant time, but the amount of scalar values x and y need not take constant time, but the amount of
time taken MUST NOT provide information about the resulting value. time taken MUST NOT provide information about the resulting value.
The conversion of the scalar multiplier for the SPAKE w parameter may The conversion of the scalar multiplier for the SPAKE w parameter may
produce a multiplier that is larger than the order of the group. 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 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 in most commonly used groups, but it is a more serious risk for P-521
due to the extra seven high bits in the input octet string. A common due to the extra seven high bits in the input octet string. A common
solution to this problem is achieved by reducing the multiplier solution to this problem is achieved by reducing the multiplier
modulo the group order, taking care to ensure constant time modulo the group order, taking care to ensure constant time
operation. operation.
10.4. KDC State 10.4. KDC State
A stateless KDC implementation generally must use a PA-FX-COOKIE 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 MUST maintain confidentiality and integrity of the 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 KDCs. Cookie values may be replayed by attackers, perhaps by
them into different SPAKE exchanges. The KDC SHOULD limit the time splicing them into different SPAKE exchanges. The KDC SHOULD limit
window of replays using a timestamp, and SHOULD prevent cookie values the time window of replays using a timestamp, and it SHOULD prevent
from being applied to other pre-authentication mechanisms or other cookie values from being applied to other pre-authentication
client principals. Within the validity period of a cookie, an mechanisms or other client principals. Within the validity period of
attacker can replay the final message of a pre-authentication a cookie, an attacker can replay the final message of a pre-
exchange to any of the realm's KDCs and make it appear that the authentication exchange to any of the realm's KDCs and make it appear
client has authenticated. that the client has authenticated.
The SPAKE pre-authentication mechanism is not designed to provide 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 not be able to recover the ticket session key; however, an attacker
who also determines the PA-FX-COOKIE encryption key (if the KDC uses who also determines the PA-FX-COOKIE encryption key (if the KDC uses
an encrypted cookie) will be able to recover the ticket session key. an 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 If 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 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. the long-term key will be able to recover the ticket session key.
10.5. Dictionary Attacks 10.5. Dictionary Attacks
Although the SPAKE pre-authentication mechanism is designed to 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 the
encrypted timestamp. Client implementations SHOULD provide a encrypted timestamp pre-authentication mechanism. Client
configuration option to enable or disable encrypted timestamp on a implementations SHOULD provide a configuration option to enable or
per-realm basis to mitigate this attack. disable the encrypted timestamp mechanism on a per-realm basis to
mitigate this attack.
If the user enters the wrong password, the client might fall back to If the user enters the wrong password, the client might fall back to
encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error the encrypted timestamp mechanism after receiving a
from the KDC, if encrypted timestamp is offered by the KDC and not KDC_ERR_PREAUTH_FAILED error from the KDC, if the encrypted timestamp
disabled by client configuration. This fallback will enable a mechanism is offered by the KDC and not disabled by client
passive attacker to mount an offline dictionary attack against the configuration. This fallback will enable a passive attacker to mount
incorrect password, which may be similar to the correct password. an offline dictionary attack against the incorrect password, which
Client implementations SHOULD assume that encrypted timestamp and may be similar to the correct password. Client implementations
encrypted challenge are unlikely to succeed if SPAKE pre- SHOULD assume that the encrypted timestamp and encrypted challenge
authentication fails in the second pass and SF-NONE was used. mechanisms are unlikely to succeed if SPAKE pre-authentication fails
in the second pass and SF-NONE was used.
Like any other pre-authentication mechanism using the client long- Like any other pre-authentication mechanism using the client long-
term key, the SPAKE pre-authentication mechanism does not prevent term key, the SPAKE pre-authentication mechanism does not prevent
online password guessing attacks. The KDC is made aware of online password guessing attacks. The KDC is made aware of
unsuccessful guesses, and can apply facilities such as rate limiting unsuccessful guesses and can apply facilities such as rate limiting
to mitigate the risk of online attacks. to mitigate the risk of online attacks.
10.6. Brute Force Attacks 10.6. Brute-Force Attacks
The selected group's resistance to offline brute-force attacks may The selected group's resistance to offline brute-force attacks may
not correspond to the size of the reply key. For performance not correspond to the size of the reply key. For performance
reasons, a KDC MAY select a group whose brute-force work factor is reasons, a KDC MAY select a group whose brute-force work factor is
less than the reply key length. A passive attacker who solves the less than the reply key length. A passive attacker who solves the
group discrete logarithm problem after the exchange will be able to group discrete logarithm problem after the exchange will be able to
conduct an offline attack against the client long-term key. Although conduct an offline attack against the client long-term key. Although
the use of password policies and costly, salted string-to-key the use of password policies and costly, salted string-to-key
functions may increase the cost of such an attack, the resulting cost functions may increase the cost of such an attack, the resulting cost
will likely not be higher than the cost of solving the group discrete will likely not be higher than the cost of solving the group discrete
logarithm. logarithm.
10.7. Denial of Service Attacks 10.7. Denial-of-Service Attacks
Elliptic curve group operations are more computationally expensive Elliptic curve group operations are more computationally expensive
than secret-key operations. As a result, the use of this mechanism than secret-key operations. As a result, the use of this mechanism
may affect the KDC's performance under normal load and its resistance may affect the KDC's performance under normal load and its resistance
to denial of service attacks. to denial-of-service attacks.
10.8. Reflection Attacks 10.8. Reflection Attacks
The encdata choice of PA-SPAKE can be used in either direction, and The encdata choice of PA-SPAKE can be used in either direction; the
the factor-specific plaintext does not necessarily indicate a factor-specific plaintext does not necessarily indicate a direction.
direction. However, each encdata message is encrypted using a However, each encdata message is encrypted using a derived key K'[n],
derived key K'[n], with client-originated messages using only odd with client-originated messages using only odd values of n and KDC-
values of n and KDC-originated messages using only even values. An originated messages using only even values. Therefore, an attempted
attempted reflection attack would therefore result in a failed reflection attack would result in a failed decryption.
decryption.
10.9. Reply-Key Encryption Type 10.9. Reply Key Encryption Type
This mechanism does not upgrade the encryption type of the initial 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. encryption type.
10.10. KDC Authentication 10.10. KDC Authentication
This mechanism does not directly provide the KDC Authentication pre- This mechanism does not directly provide the KDC Authentication pre-
authentication facility, because it does not send a key confirmation authentication facility because it does not send a key confirmation
from the KDC to the client. When used as a stand-alone mechanism, from the KDC to the client. When used as a stand-alone mechanism,
the traditional KDC authentication provided by the KDC-REP enc-part the preexisting KDC authentication provided by the KDC-REP enc-part
still applies. still applies.
11. Assigned Constants 11. Assigned Constants
The following key usage values are assigned for this mechanism: The following key usage values are assigned for this mechanism:
KEY_USAGE_SPAKE 65 KEY_USAGE_SPAKE 65
12. IANA Considerations 12. IANA Considerations
IANA has assigned the following number for PA-SPAKE in the "Pre- IANA has assigned the following number for PA-SPAKE in the "Pre-
authentication and Typed Data" registry: authentication and Typed Data" registry:
+==========+=======+=================+ +==========+=======+===========+
| Type | Value | Reference | | Type | Value | Reference |
+==========+=======+=================+ +==========+=======+===========+
| PA-SPAKE | 151 | [this document] | | PA-SPAKE | 151 | RFC 9588 |
+----------+-------+-----------------+ +----------+-------+-----------+
Table 1 Table 1
This document establishes two registries with the following This document establishes two registries (see Sections 12.1 and 12.2)
procedure, in accordance with [RFC8126]: with the following procedure, in accordance with [RFC8126]:
Registry entries are to be evaluated using the Specification Required Registry entries are to be evaluated using the Specification Required
method. All specifications must be be published prior to entry method. All specifications must be published prior to entry
inclusion in the registry. Once published, they can be submitted inclusion in the registry. Once published, they can be submitted
directly to the krb5-spake-review@ietf.org mailing list, where there directly to the krb5-spake-review@ietf.org mailing list, where there
will be a three-week long review period by Designated Experts. will be a three-week-long review period by designated experts.
The Designated Experts ensure that the specification is publicly 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
reviews, but their approval should not be taken as endorsement of the approval should not be taken as endorsement of the specification.
specification.
Prior to the end of the review period, the Designated Experts must Prior to the end of the review period, the designated experts must
approve or deny the request. This decision is conveyed to both IANA approve or deny the request. This decision is conveyed to both IANA
and the submitter. Since the mailing list archives are not public, and the submitter. Since the mailing list archives are not public,
it should include both a reasonably detailed explanation in the case it should include both a reasonably detailed explanation in the case
of a denial as well as whether the request can be resubmitted. of a denial as well as whether the request can be resubmitted.
IANA must only accept registry updates from the designated experts 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. list.
12.1. Kerberos Second Factor Types 12.1. Kerberos Second-Factor Types
This section species the IANA "Kerberos Second Factor Types" This section specifies the "Kerberos Second-Factor Types" registry,
registry. This registry records the number, name, and reference for which records the number, name, and reference for each second-factor
each second factor protocol. protocol.
12.1.1. Registration Template 12.1.1. Registration Template
ID Number: This is a value that uniquely identifies this entry. It ID Number: A value that uniquely identifies this entry. It is a
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 in Positive values must be assigned only for algorithms specified in
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 algorithms only. Zero is reserved and must not be experimental algorithms only. Zero is reserved and must not be
assigned. Values should be assigned in increasing order. assigned. Values should be assigned in increasing order.
Name: Brief, unique, human-readable name for this algorithm. Name: A brief, unique, human-readable name for this algorithm.
Reference: URI or otherwise unique identifier for where the details Reference: A URI or otherwise unique identifier for where the
of this algorithm can be found. It should be as specific as details of this algorithm can be found. It should be as specific
reasonably possible. as reasonably possible.
12.1.2. Initial Registry Contents 12.1.2. Initial Registry Contents
ID Number: 0
Name: Reserved
Reference: RFC 9588
ID Number: 1 ID Number: 1
Name: SF-NONE Name: SF-NONE
Reference: [this document] Reference: RFC 9588
12.2. Kerberos SPAKE Groups 12.2. Kerberos SPAKE Groups
This section specifies the IANA "Kerberos SPAKE Groups" registry. This section specifies the "Kerberos SPAKE Groups" registry, which
This registry records the number, name, specification, serialization, records the number, name, specification, serialization, multiplier
multiplier length, multiplier conversion, SPAKE M and N constants, length, multiplier conversion, SPAKE M and N constants, and
and associated hash function. associated hash function for each SPAKE Group.
12.2.1. Registration Template 12.2.1. Registration Template
ID Number: This is a value that uniquely identifies this entry. It ID Number: A value that uniquely identifies this entry. It is a
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 in Positive values must be assigned only for algorithms specified in
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 assigned. experimental use only. Zero is reserved and must not be assigned.
Values should be assigned in increasing order. Values should be assigned in increasing order.
Name: Brief, unique, human readable name for this entry. Name: A brief, unique, human-readable name for this entry.
Specification: Reference to the definition of the group parameters Specification: A reference to the definition of the group parameters
and operations. and operations.
Serialization: Reference to the definition of the method used to Serialization: A reference to the definition of the method used to
serialize and deserialize group elements. serialize and deserialize group elements.
Multiplier Length: The length of the input octet string to Multiplier Length: The length of the input octet string to
multiplication operations. multiplication operations.
Multiplier Conversion: Reference to the definition of the method Multiplier Conversion: A reference to the definition of the method
used to convert an octet string to a multiplier scalar. used to convert an octet string to a multiplier scalar.
SPAKE M Constant: The serialized value of the SPAKE M constant in SPAKE M Constant: The serialized value of the SPAKE M constant in
hexadecimal notation. hexadecimal notation.
SPAKE N Constant: The serialized value of the SPAKE N constant in SPAKE N Constant: The serialized value of the SPAKE N constant in
hexadecimal notation. hexadecimal notation.
Hash Function: The group's associated hash function. Hash Function: The group's associated hash function.
skipping to change at page 22, line 9 skipping to change at line 1012
ID Number: 1 ID Number: 1
Name: edwards25519 Name: edwards25519
Specification: Section 4.1 of [RFC7748] (edwards25519) Specification: Section 4.1 of [RFC7748] (edwards25519)
Serialization: Section 3.1 of [RFC8032] Serialization: Section 3.1 of [RFC8032]
Multiplier Length: 32 Multiplier Length: 32
Multiplier Conversion: Section 3.1 of [RFC8032] Multiplier Conversion: Section 3.1 of [RFC8032]
SPAKE M Constant: SPAKE M Constant:
d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
SPAKE N Constant: SPAKE N Constant:
d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
Hash function: SHA-256 ([RFC6234]) Hash function: SHA-256 [RFC6234]
12.2.2.2. P-256 12.2.2.2. P-256
ID Number: 2 ID Number: 2
Name: P-256 Name: P-256
Specification: Section 2.4.2 of [SEC2] Specification: Section 2.4.2 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format) Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 32 Multiplier Length: 32
Multiplier Conversion: Section 2.3.8 of [SEC1] Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant: SPAKE M Constant:
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
SPAKE N Constant: SPAKE N Constant:
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
Hash function: SHA-256 ([RFC6234]) Hash function: SHA-256 [RFC6234]
12.2.2.3. P-384 12.2.2.3. P-384
ID Number: 3 ID Number: 3
Name: P-384 Name: P-384
Specification: Section 2.5.1 of [SEC2] Specification: Section 2.5.1 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format) Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 48 Multiplier Length: 48
Multiplier Conversion: Section 2.3.8 of [SEC1] Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant: SPAKE M Constant:
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3d 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3d
c36f15314739074d2eb8613fceec2853 c36f15314739074d2eb8613fceec2853
SPAKE N Constant: SPAKE N Constant:
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543b 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543b
b252c5490214cf9aa3f0baab4b665c10 b252c5490214cf9aa3f0baab4b665c10
Hash function: SHA-384 ([RFC6234]) Hash function: SHA-384 [RFC6234]
12.2.2.4. P-521 12.2.2.4. P-521
ID Number: 4 ID Number: 4
Name: P-521 Name: P-521
Specification: Section 2.6.1 of [SEC2] Specification: Section 2.6.1 of [SEC2]
Serialization: Section 2.3.3 of [SEC1] (compressed format) Serialization: Section 2.3.3 of [SEC1] (compressed format)
Multiplier Length: 48 Multiplier Length: 48
Multiplier Conversion: Section 2.3.8 of [SEC1] Multiplier Conversion: Section 2.3.8 of [SEC1]
SPAKE M Constant: SPAKE M Constant:
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d8560 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d8560
8cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7 8cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7
aa aa
SPAKE N Constant: SPAKE N Constant:
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b
2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd 2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd
25 25
Hash function: SHA-512 ([RFC6234]) Hash function: SHA-512 [RFC6234]
13. Normative References 13. References
13.1. Normative References
[ITU-T.X680.2021]
ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021.
[ITU-T.X690.2021]
ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
2005, <https://www.rfc-editor.org/info/rfc3961>. 2005, <https://www.rfc-editor.org/info/rfc3961>.
skipping to change at page 24, line 14 skipping to change at line 1120
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[CCITT.X680.2002]
International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1):
Specification of basic notation", CCITT Recommendation
X.680, July 2002.
[CCITT.X690.2002]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009. Elliptic Curve Cryptography", May 2009.
[SEC2] Standards for Efficient Cryptography Group, "SEC 2: [SEC2] Standards for Efficient Cryptography Group, "SEC 2:
Recommended Elliptic Curve Domain Parameters", January Recommended Elliptic Curve Domain Parameters", January
2010. 2010.
14. Informative References 13.2. Informative References
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[RFC6560] Richards, G., "One-Time Password (OTP) Pre- [RFC6560] Richards, G., "One-Time Password (OTP) Pre-
Authentication", RFC 6560, DOI 10.17487/RFC6560, April Authentication", RFC 6560, DOI 10.17487/RFC6560, April
2012, <https://www.rfc-editor.org/info/rfc6560>. 2012, <https://www.rfc-editor.org/info/rfc6560>.
[RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key [RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key
Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125, Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125,
April 2017, <https://www.rfc-editor.org/info/rfc8125>. April 2017, <https://www.rfc-editor.org/info/rfc8125>.
[SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based
Encrypted Key Exchange Protocols", Cryptography-CT-RSA Encrypted Key Exchange Protocols", CT-RSA 2005, Lecture
2005, Lecture Notes in Computer Science, Volume 3376, Notes in Computer Science, Volume 3376, pages 191-208,
pages 191-208, Springer, DOI 10.1007/978-3-540-30574-3_14, Springer, DOI 10.1007/978-3-540-30574-3_14, February 2005,
February 2005,
<https://doi.org/10.1007/978-3-540-30574-3_14>. <https://doi.org/10.1007/978-3-540-30574-3_14>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
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
skipping to change at page 27, line 5 skipping to change at line 1238
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
The seed initial seed strings are: The initial seed strings are as follows:
* For group 1 M: edwards25519 point generation seed (M) * For group 1 M: edwards25519 point generation seed (M)
* For group 1 N: edwards25519 point generation seed (N) * For group 1 N: edwards25519 point generation seed (N)
* For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M) * For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)
* For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N) * For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)
* For group 3 M: 1.3.132.0.34 point generation seed (M) * For group 3 M: 1.3.132.0.34 point generation seed (M)
skipping to change at page 27, line 32 skipping to change at line 1265
Appendix C. Test Vectors Appendix C. Test Vectors
For the following text vectors: For the following text vectors:
* The key is the string-to-key of "password" with the salt * 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. encryption type.
* x and y were chosen randomly within the order of the designated * x and y were chosen randomly within the order of the designated
group, then multiplied by the cofactor.. group, then multiplied by the cofactor.
* The SPAKESupport message contains only the designated group's * The SPAKESupport message contains only the designated group's
number. number.
* The SPAKEChallenge message offers only the SF-NONE second factor * The SPAKEChallenge message offers only the SF-NONE second-factor
type. type.
* The KDC-REQ-BODY message contains no KDC options, the client * The KDC-REQ-BODY message does not contain KDC options, but does
principal name "raeburn@ATHENA.MIT.EDU", the server principal name contain the client principal name "raeburn@ATHENA.MIT.EDU", the
"krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till server principal name "krbtgt/ATHENA.MIT.EDU", the realm
field "19700101000000Z", the nonce zero, and an etype list "ATHENA.MIT.EDU", the till field "19700101000000Z", the nonce
containing only the designated encryption type. zero, and an etype list containing only the designated encryption
type.
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
skipping to change at page 36, line 40 skipping to change at line 1685
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
Appendix D. Acknowledgements Acknowledgements
Nico Williams (Cryptonector) Nico Williams (Cryptonector)
Taylor Yu (MIT)
Taylor Yu (MIT)
Authors' Addresses Authors' Addresses
Nathaniel McCallum Nathaniel McCallum
Red Hat, Inc. Red Hat, Inc.
Email: nathaniel@mccallum.life Email: nathaniel@mccallum.life
Simo Sorce Simo Sorce
Red Hat, Inc. Red Hat, Inc.
Email: ssorce@redhat.com Email: ssorce@redhat.com
Robbie Harwood Robbie Harwood
Red Hat, Inc. Red Hat, Inc.
Email: rharwood@pm.me Email: rharwood@pm.me
Greg Hudson Greg Hudson
MIT MIT
 End of changes. 139 change blocks. 
384 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.48.