draft-ietf-kitten-krb-spake-preauth-06.txt   draft-ietf-kitten-krb-spake-preauth-07.txt 
Internet Engineering Task Force N. McCallum Internet Engineering Task Force N. McCallum
Internet-Draft S. Sorce Internet-Draft S. Sorce
Intended status: Standards Track R. Harwood Intended status: Standards Track R. Harwood
Expires: February 22, 2019 Red Hat, Inc. Expires: November 1, 2020 Red Hat, Inc.
G. Hudson G. Hudson
MIT MIT
August 21, 2018 April 30, 2020
SPAKE Pre-Authentication SPAKE Pre-Authentication
draft-ietf-kitten-krb-spake-preauth-06 draft-ietf-kitten-krb-spake-preauth-07
Abstract Abstract
This document defines a new pre-authentication mechanism for the This document defines a new pre-authentication mechanism for the
Kerberos protocol that uses a password authenticated key exchange. Kerberos protocol that uses a password authenticated key exchange.
This document has three goals. First, increase the security of This document has three goals. First, increase the security of
Kerberos pre-authentication exchanges by making offline brute-force Kerberos pre-authentication exchanges by making offline brute-force
attacks infeasible. Second, enable the use of second factor attacks infeasible. Second, enable the use of second factor
authentication without relying on FAST. This is achieved using the authentication without relying on FAST. This is achieved using the
existing trust relationship established by the shared first factor. existing trust relationship established by the shared first factor.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 22, 2019. This Internet-Draft will expire on November 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 5 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 5
3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . 6 3.1. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Cookie Support . . . . . . . . . . . . . . . . . . . . . 6 3.2. Cookie Support . . . . . . . . . . . . . . . . . . . . . 6
3.3. More Pre-Authentication Data Required . . . . . . . . . . 6 3.3. More Pre-Authentication Data Required . . . . . . . . . . 6
4. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 6 4. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 6
4.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10 4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10
4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 10 4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 11
4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11
5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 11 5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 12
6. Transcript Hash . . . . . . . . . . . . . . . . . . . . . . . 12 6. Transcript Hash . . . . . . . . . . . . . . . . . . . . . . . 12
7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 12 7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 13
8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 13 8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 14
9. Hint for Authentication Sets . . . . . . . . . . . . . . . . 14 9. Hint for Authentication Sets . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Unauthenticated Plaintext . . . . . . . . . . . . . . . 14 10.1. SPAKE Computations . . . . . . . . . . . . . . . . . . . 15
10.2. Side Channels . . . . . . . . . . . . . . . . . . . . . 15 10.2. Unauthenticated Plaintext . . . . . . . . . . . . . . . 15
10.3. KDC State . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. Side Channels . . . . . . . . . . . . . . . . . . . . . 16
10.4. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 16 10.4. KDC State . . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Brute Force Attacks . . . . . . . . . . . . . . . . . . 17 10.5. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 17
10.6. Denial of Service Attacks . . . . . . . . . . . . . . . 17 10.6. Brute Force Attacks . . . . . . . . . . . . . . . . . . 18
10.7. Reply-Key Encryption Type . . . . . . . . . . . . . . . 17 10.7. Denial of Service Attacks . . . . . . . . . . . . . . . 18
10.8. KDC Authentication . . . . . . . . . . . . . . . . . . . 18 10.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . 18
11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 18 10.9. Reply-Key Encryption Type . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.10. KDC Authentication . . . . . . . . . . . . . . . . . . . 19
12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 18 11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 19
12.1.1. Registration Template . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1.2. Initial Registry Contents . . . . . . . . . . . . . 19 12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 20
12.1.1. Registration Template . . . . . . . . . . . . . . . 20
12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 19 12.1.2. Initial Registry Contents . . . . . . . . . . . . . 20
12.2.1. Registration Template . . . . . . . . . . . . . . . 19 12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 20
12.2.2. Initial Registry Contents . . . . . . . . . . . . . 20 12.2.1. Registration Template . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.2.2. Initial Registry Contents . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.2. Non-normative References . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 25 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 25 Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 26
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC
does not require preauthentication), a passive attacker that observes does not require preauthentication), a passive attacker that observes
either the AS-REQ or AS-REP can perform an offline brute-force attack either the AS-REQ or AS-REP can perform an offline brute-force attack
against the transferred ciphertext. When the client principal's against the transferred ciphertext. When the client principal's
long-term key is based on a password, offline dictionary attacks can long-term key is based on a password, offline dictionary attacks can
successfuly recover the key, with only modest effort needed if the successfuly recover the key, with only modest effort needed if the
password is weak. password is weak.
1.1. Properties of PAKE 1.1. Properties of PAKE
Password authenticated key exchange (PAKE) algorithms provide several Password authenticated key exchange (PAKE) algorithms provide several
properties which are useful to overcome this problem and make them properties which defend against offline dictionary attacks and make
ideal for use as a Kerberos pre-authentication mechanism. them ideal for use as a Kerberos pre-authentication 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 man-in-the-middle attack. 3. Active attackers cannot perform a man-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 attack, even when
the passwords used are weak (low-entropy). the passwords used are weak (low-entropy).
skipping to change at page 4, line 8 skipping to change at page 4, line 9
Hellman key exchange with a shared secret. SPAKE was selected for Hellman key exchange with a shared secret. SPAKE was selected for
this pre-authentication mechanism for the following properties: this pre-authentication mechanism for the following properties:
1. Because SPAKE's encryption method ensures that the result is a 1. Because SPAKE's encryption method ensures that the result is a
member of the underlying group, it can be used with elliptic member of the underlying group, it can be used with elliptic
curve cryptography, which is believed to provide equivalent curve cryptography, which is believed to provide equivalent
security levels to finite-field DH key exchange at much smaller security 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. 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, and can therefore
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. Attempting to challenge/response signatures and biometric data. Encrypting this
encrypt this data using the long-term secret results in packets that data using the long-term secret results in packets that are
are vulnerable to offline brute-force attack if either authenticated vulnerable to offline brute-force attack on the password, using
encryption is used or if the plaintext is distinguishable from random either an authentication tag or statistical properties of the 2FA
data. This is a problem that PAKE solves for first factor credentials to determine whether a password guess is correct.
authentication. So a similar technique can be used with PAKE to
encrypt second-factor data.
In the OTP pre-authentication [RFC6560] specification, this problem In the OTP pre-authentication [RFC6560] specification, this problem
is mitigated by using FAST, which uses a secondary trust relationship is mitigated by using FAST, which uses a secondary trust relationship
to create a secure encryption channel within which pre-authentication to create a secure encryption channel within which pre-authentication
data can be sent. However, the requirement for a secondary trust data can be sent. However, the requirement for a secondary trust
relationship has proven to be cumbersome to deploy and often relationship has proven to be cumbersome to deploy and often
introduces third parties into the trust chain (such as certification introduces third parties into the trust chain (such as certification
authorities). These requirements lead to a scenario where FAST authorities). These requirements make it difficult to enable FAST
cannot be enabled by default without sufficient configuration. SPAKE without manual configuration of client hosts. SPAKE pre-
pre-authentication, in contrast, can create a secure encryption authentication, in contrast, can create a secure encryption channel
channel implicitly, using the key exchange to negotiate a high- implicitly, using the key exchange to negotiate a high-entropy
entropy encryption key. This key can then be used to securely encryption key. This key can then be used to securely encrypt 2FA
encrypt 2FA plaintext data without the need for a secondary trust plaintext data without the need for a secondary trust relationship.
relationship. Further, if the second factor verifiers are sent at Further, if the second factor verifiers are sent at the same time as
the same time as the first factor verifier, and the KDC is careful to the first factor verifier, and the KDC is careful to prevent timing
prevent timing attacks, then an online brute-force attack cannot be attacks, then an online brute-force attack cannot be used to attack
used to attack the factors separately. the factors separately.
For these reasons, this draft departs from the advice given in For these reasons, this draft departs from the advice given in
Section 1 of RFC 6113 [RFC6113] which states that "Mechanism Section 1 of RFC 6113 [RFC6113] which states that "Mechanism
designers should design FAST factors, instead of new pre- designers should design FAST factors, instead of new pre-
authentication mechanisms outside of FAST." However, this pre- authentication mechanisms outside of FAST." However, this pre-
authentication mechanism does not intend to replace FAST, and may be authentication mechanism does not intend to replace FAST, and may be
used with it to further conceal the metadata of the Kerberos used with it to further conceal the metadata of the Kerberos
messages. messages.
1.4. SPAKE Overview 1.4. SPAKE Overview
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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')
Higher level protocols must define their own verification step. In In this mechanism, key verification happens implicitly by a
the case of this mechanism, verification happens implicitly by a successful decryption of the 2FA data, or of a placeholder value when
successful decryption of the 2FA data. no second factor is required. This mechanism uses a tailored method
of deriving encryption keys from the calculated shared secret K, for
This mechanism provides its own method of deriving encryption keys several reasons: to fit within the framework of [RFC3961], to ensure
from the calculated shared secret K, for several reasons: to fit negotiation integrity using a transcript hash, to derive different
within the framework of [RFC3961], to ensure negotiation integrity keys for each use, and to bind the KDC-REQ-BODY to the pre-
using a transcript hash, to derive different keys for each use, and authentication exchange.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 The [SPAKE] paper defines SPAKE as a family of two key exchange
algorithms differing only in derivation of the final key. This algorithms differing only in derivation of the final key. This
mechanism uses a derivation similar to the second algorithm (SPAKE2) mechanism uses a derivation similar to the second algorithm (SPAKE2)
with differences in detail. For simplicity, this document refers to with differences in detail. For simplicity, this document refers to
the algorithm as "SPAKE". The normative reference for this algorithm the algorithm as "SPAKE".
is [I-D.irtf-cfrg-spake2].
The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and
[CCITT.X690.2002] respectively. [CCITT.X690.2002] respectively.
When discussing operations within algebraic groups, this document
uses additive notation (as described in Section 2.2 of [RFC6090]).
Group elements are denoted with uppercase letters, while scalar
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 which 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, as described in INFO2 value containing a single ETYPE-INFO2-ENTRY, following the
[RFC6113] section 2.1. PA-ETYPE-INFO2 is specified in [RFC4120] guidance in Section 2.1 of [RFC6113]. PA-ETYPE-INFO2 is specified in
section 5.2.7.5. 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 which implement SPAKE pre-authentication MUST have some secure
mechanism for retaining state between AS-REQs. For stateless KDC mechanism for retaining state between AS-REQs. For stateless KDC
implementations, this method will most commonly be an encrypted PA- implementations, this method will most commonly be an encrypted PA-
FX-COOKIE. Clients which implement SPAKE pre-authentication MUST FX-COOKIE. Clients which implement SPAKE pre-authentication MUST
support PA-FX-COOKIE, as described in [RFC6113] section 5.2. 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 which 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 [RFC6113] section 5.2. 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 ([RFC6113] section 3). 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 IANA "Kerberos SPAKE Groups" registry
created by this document. Each group definition specifies an created by this document. Each group definition specifies an
skipping to change at page 8, line 17 skipping to change at page 8, line 20
... ...
} }
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.
Once the KDC has selected a group, the KDC will reply to the client The group selection determines the group order, which shall be a
with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE large prime p multiplied by a small cofactor h (possibly 1), as well
PA-DATA element using the challenge choice. as a generator P of a prime-order subgroup and two masking points M
and N. The KDC selects a random integer x in the range [0,h*p),
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
to Section 5.
The KDC will reply to the client with a
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-
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 IANA "Kerberos SPAKE Groups" registry
created by this document. created by this document.
The pubkey field indicates the KDC's public key generated using the M The pubkey field indicates the KDC's public key T, serialized
constant in the SPAKE algorithm, with inputs and conversions as according to Section 5.
specified in 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 which 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. this field will depend upon the second factor type chosen. Note that
this challenge is initially transmitted as unauthenticated plaintext;
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 will complete its Upon receipt of the challenge message, the client observes which
part of of the SPAKE algorithm, generating a public key and computing group was selected by the KDC and deserializes the KDC's public key
the shared secret K. The client will then choose one of the second T. The client selects a random integer y in the range [0,h*p), which
factor types listed in the factors field of the challenge message and MUST be divisible by h. The client computes a public key S=y*P+w*N,
gather whatever data is required for the chosen second factor type, where w is computed from the initial reply key according to
possibly using the associated challenge data. Finally, the client Section 5. The client computes a shared group element K=y*(T-w*M).
will send an AS-REQ containing a PA-SPAKE PA-DATA element using the
response choice. The client will then choose one of the second factor types listed in
the factors field of the challenge message and gather whatever data
is required for the chosen second factor type, possibly using the
associated challenge data. Finally, the client will send an AS-REQ
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 generated using The pubkey field indicates the client's public key S, serialized
the N constant in the SPAKE algorithm, with inputs and conversions as according to Section 5.
specified in 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 key The key for this field is K'[1] as specified in Section 7. The kvno
usage number for the encryption is KEY_USAGE_SPAKE. The plain text field of the EncryptedData sequence is omitted. The key usage number
inside the EncryptedData is an encoding of SPAKESecondFactor. Once for the encryption is KEY_USAGE_SPAKE. The plain text inside the
decoded, the SPAKESecondFactor contains the type of the second factor EncryptedData is an encoding of SPAKESecondFactor. Once decoded, the
and any optional data used. The contents of the data field will SPAKESecondFactor contains the type of the second factor and any
depend on the second factor type chosen. The client MUST NOT send a optional data used. The contents of the data field will depend on
response containing a second factor type which was not listed in the the second factor type chosen. The client MUST NOT send a response
factors field of the challenge message. containing a second factor type which was not listed in the factors
field of the challenge message.
When the KDC receives the response message from the client, it will When the KDC receives the response message from the client, it
use the pubkey to compute the SPAKE result, derive K'[1], and decrypt deserializes the client's public key S, and computes the shared group
the factors field. If decryption is successful, the first factor is element K=x*(S-w*N). The KDC derives K'[1] and decrypts the factors
successfully validated. The KDC then validates the second factor. field. If decryption is successful, the first factor is successfully
If either factor fails to validate, the KDC SHOULD respond with a validated. The KDC then validates the second factor. If either
factor fails to validate, the KDC SHOULD 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 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
containing a PA-SPAKE PA-DATA element using the encdata choice. The containing a PA-SPAKE PA-DATA element using the encdata choice. The
key for the EncryptedData value is K'[2] as specified in Section 7, kvno field of the EncryptedData sequence is omitted. The key for the
and the key usage number is KEY_USAGE_SPAKE. The plain text of this EncryptedData value is K'[2] as specified in Section 7, and the key
message contains a DER-encoded SPAKESecondFactor message. As before, usage number is KEY_USAGE_SPAKE. The plain text of this message
the type field of this message will contain the second factor type, contains a DER-encoded SPAKESecondFactor message. As before, the
and the data field will optionally contain second factor type type field of this message will contain the second factor type, and
specific data. the data field will optionally contain second factor type specific
data.
KEY_USAGE_SPAKE 65 KEY_USAGE_SPAKE 65
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 using the encdata choice, or abort the AS
skipping to change at page 11, line 22 skipping to change at page 11, line 46
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 initial reply key type is
incompatible with SPAKE or because it does not support any of the incompatible with SPAKE or because it does not support any of the
client's groups) but can offer other pre-authentication mechanisms, client's groups) but can offer other pre-authentication mechanisms,
it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing
METHOD-DATA. A client supporting this optimization MUST continue METHOD-DATA for the available mechanisms. A client supporting this
after a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113] optimization MUST continue after a KDC_ERR_PREAUTH_FAILED error as
section 2. KDCs MUST support this optimization. described in Section 2 of [RFC6113]. KDCs MUST support this
optimization.
5. SPAKE Parameters and Conversions 5. SPAKE Parameters and Conversions
Group elements are converted to octet strings using the serialization Group elements are converted to and from octet strings using the
method defined in the IANA "Kerberos SPAKE Groups" registry created serialization method defined in the IANA "Kerberos SPAKE Groups"
by this document. registry created by this document.
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 IANA "Kerberos SPAKE Groups" registry
created by this document. created by this document.
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 (see [I-D.irtf-cfrg-spake2] section 3). This value scalar multiplier. This value MUST be produced from the initial
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 IANA "Kerberos SPAKE Groups" registry created by this
document. 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 defined in
[RFC6113] section 5.1. 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 IANA "Kerberos SPAKE
Groups" registry created by this document. Groups" registry created by this document.
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.3). 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. The
initial value consists of all bits set to zero. initial value consists of all bits set to zero.
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 first updated with the
concatenation of the client's support message and the KDC's concatenation of the client's support message and the KDC's
challenge, and then updated a second time with the client's pubkey challenge, and then updated a second time with the client's pubkey
value. It therefore incorporates the client's supported groups, the value. It therefore incorporates the client's supported groups, the
KDC's chosen group, the KDC's initial second-factor messages, and the KDC's chosen group, the KDC's initial second-factor messages, and the
client and KDC public values. Once the transcript hash is finalized, client and KDC public values. Once the transcript hash is finalized,
it is used without change for all key derivations (Section 7). it is used without change for all key derivations (Section 7). In
particular, encrypted second-factor messages are not included in the
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 updated first with the KDC's
challenge message, and second with the client's pubkey value. challenge message, and second with the client's pubkey value.
If first optimization is used unsuccessfully (i.e. the client does If first optimization is used unsuccessfully (i.e. the client does
not accept the KDC's selected group), the transcript hash is computed not accept the KDC's selected group), the transcript hash is computed
as in the normal message flow, without including the KDC's optimistic as in the normal message flow, without including the KDC's optimistic
challenge. challenge.
7. Key Derivation 7. Key Derivation
Implementations MUST NOT use the SPAKE result (denoted by K in Implementations MUST NOT use the shared group element (denoted by K)
Section 3 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any directly for any cryptographic operation. Instead, the SPAKE result
cryptographic operation. Instead, the SPAKE result is used to derive is used to derive keys K'[n] as defined in this section.
keys K'[n] as defined in this section. This method differs slightly
from the method used to generate K' in Section 3 of SPAKE
[I-D.irtf-cfrg-spake2].
First, the hash function associated with the selected group is First, the hash function associated with the selected group is
computed over the concatenation of the following values: computed over the concatenation of the following values:
o The fixed string "SPAKEkey". o The fixed string "SPAKEkey".
o The group number as a big-endian four-byte two's complement binary o The group number as a big-endian four-byte two's complement binary
number. number.
o The encryption type of the initial reply key as a big-endian four- o The encryption type of the initial reply key as a big-endian four-
skipping to change at page 13, line 41 skipping to change at page 14, line 16
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 re-computed 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 [RFC6113] "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in Section 5.1 of
section 5.1. [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 ([RFC6113] section 5.3), it MAY provide a pa-hint value set (Section 5.3 of [RFC6113]), it MAY 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, to help
the client determine whether SPAKE pre-authentication is likely to the client determine whether SPAKE pre-authentication is likely to
succeed if the authentication set is chosen. 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 in a pa-value field; A KDC MUST NOT include a PA-SPAKE-HINT message directly in a pa-value
hints must only be provided within authentication sets. A KDC SHOULD field; hints must only be provided within authentication sets. A KDC
include a hint if SPAKE pre-authentication is offered as the second SHOULD include a hint if SPAKE pre-authentication is offered as the
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 does not
replace any part of the SPAKE message flow. replace any part of the SPAKE message flow.
10. Security Considerations 10. Security Considerations
All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2] 10.1. SPAKE Computations
apply here as well.
10.1. Unauthenticated Plaintext 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
to verify that they are members of the prime-order subgroup, as the
computation of K by both parties involves a multiplication by the
cofactor h.
The aforementioned cofactor multiplication is accomplished by
choosing private scalars x and y which are divisible by the cofactor.
If the client or KDC chooses a scalar which might not be divisible by
the cofactor, an attacker might be able to coerce values of K which
are not members of the prime-order subgroup, and deduce a 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
for different initial reply keys. If an x or y value is reused for
pre-authentications involving two different initial reply keys, an
attacker who observes both authentications and knows one of the
initial reply keys can conduct an offline dictionary attack to
recover the other one.
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
dictionary attack on passwords. It is therefore important to
demonstrate that the M and N values for each group were computed
without multiplying a known value by the generator P.
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. Second factor data in the challenge should not be included in field. Second factor data in the challenge should not be included in
user prompts, as it could be modified by an attacker to contain user prompts, as it could be modified by an attacker to contain
misleading or offensive information. misleading or offensive information.
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
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, unless the turn the client into an encryption or signing oracle for the second
attacker knows the client's long-term key. factor credentials, unless the attacker knows the client's long-term
key.
Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE
is advertised in authentication sets are unauthenticated, and are not is advertised in authentication sets are unauthenticated, and are not
protected by the transcript hash. Since hints do not replace any protected by the transcript hash. Since hints do not replace any
part of the message flow, manipulation of hint messages can only part of the message flow, manipulation of hint messages can only
affect the client's decision to use or not use an authentication set, affect the client's decision to use or not use an authentication set,
which could more easily be accomplished by removing authentication which could more easily be accomplished by removing authentication
sets entirely. sets entirely.
10.2. Side Channels 10.3. Side Channels
An implementation of this pre-authentication mechanism can have the An implementation of this pre-authentication mechanism can have the
property of indistinguishability, meaning that an attacker who 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 processing a response message, whether or
skipping to change at page 16, line 9 skipping to change at page 17, line 12
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 a minor risk in multiplication that is not constant time. This is only a minor risk
all known groups, but is a major risk for P-521 due to the extra in most commonly-used groups, but is a more serious risk for P-521
seven high bits in the input octet string. A common solution to this due to the extra seven high bits in the input octet string. A common
problem is achieved by reducing the multiplier modulo the group solution to this problem is achieved by reducing the multiplier
order, taking care to ensure constant time operation. modulo the group order, taking care to ensure constant time
operation.
10.3. 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. The KDC SHOULD KDCs. Cookie values may be replayed by attackers, perhaps splicing
limit the time window of replays using a timestamp, and SHOULD them into different SPAKE exchanges. The KDC SHOULD limit the time
prevent cookie values from being applied to other pre-authentication window of replays using a timestamp, and SHOULD prevent cookie values
mechanisms or other client principals. Within the validity period of from being applied to other pre-authentication mechanisms or other
a cookie, an attacker can replay the final message of a pre- client principals. Within the validity period of a cookie, an
authentication exchange to any of the realm's KDCs and make it appear attacker can replay the final message of a pre-authentication
that the client has authenticated. exchange to any of the realm's KDCs and make it appear that the
client has authenticated.
If an x or y value is reused for pre-authentications involving two
different client long-term keys, an attacker who observes both
authentications and knows one of the long-term keys can conduct an
offline dictionary attack to recover the other one.
This pre-authentication mechanism is not designed to provide forward This pre-authentication mechanism is not designed to provide forward
secrecy. Nevertheless, some measure of forward secrecy may result secrecy. Nevertheless, some measure of forward secrecy may result
depending on implementation choices. A passive attacker who 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.
The KDC can mitigate this risk by periodically rotating the cookie The KDC can mitigate this risk by periodically rotating the cookie
encryption key. If the KDC or client retains the x or y value for encryption key. If the KDC or client retains the x or y value for
reuse with the same client long-term key, an attacker who recovers reuse with the same client long-term key, an attacker who recovers
the x or y value and the long-term key will be able to recover the the x or y value and the long-term key will be able to recover the
ticket session key. ticket session key.
10.4. Dictionary Attacks 10.5. Dictionary Attacks
Although this pre-authentication mechanism is designed to prevent an Although this pre-authentication mechanism is designed to prevent an
offline dictionary attack by an active attacker posing as the KDC, offline dictionary attack by an active attacker posing as the KDC,
such an attacker can attempt to downgrade the client to encrypted such an attacker can attempt to downgrade the client to encrypted
timestamp. Client implementations SHOULD provide a configuration timestamp. Client implementations SHOULD provide a configuration
option to disable encrypted timestamp on a per-realm basis to option to disable encrypted timestamp on a per-realm basis to
mitigate this attack. 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 encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error
from the KDC, if encrypted timestamp is offered by the KDC and not from the KDC, if encrypted timestamp is offered by the KDC and not
disabled by client configuration. This fallback will enable a disabled by client configuration. This fallback will enable a
passive attacker to mount an offline dictionary attack against the passive attacker to mount an offline dictionary attack against the
incorrect password, which may be similar to the correct password. incorrect password, which may be similar to the correct password.
Client implementations SHOULD assume that encrypted timestamp and Client implementations SHOULD assume that encrypted timestamp and
encrypted challenge are unlikely to succeed if SPAKE pre- encrypted challenge are unlikely to succeed if SPAKE pre-
authentication fails in the second pass and no second factor was authentication fails in the second pass and SF-NONE was used.
used.
Like any other pre-authentication mechanism using the client long- Like any other pre-authentication mechanism using the client long-
term key, this pre-authentication mechanism does not prevent online term key, this pre-authentication mechanism does not prevent online
password guessing attacks. The KDC is made aware of unsuccessful password guessing attacks. The KDC is made aware of unsuccessful
guesses, and can apply facilities such as password lockout to guesses, and can apply facilities such as rate limiting to mitigate
mitigate the risk of online attacks. the risk of online attacks.
10.5. 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.6. 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.7. Reply-Key Encryption Type 10.8. Reflection Attacks
The encdata choice of PA-SPAKE can be used in either direction, and
the factor-specific plaintext does not necessarily indicate a
direction. However, each encdata message is encrypted using a
derived key K'[n], with client-originated messages using only odd
values of n and KDC-originated messages using only even values. An
attempted reflection attack would therefore result in a failed
decryption.
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 pseudo-random 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.8. 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 traditional 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:
skipping to change at page 18, line 35 skipping to change at page 19, line 46
| Type | Value | Reference | | Type | Value | Reference |
+----------+-------+-----------------+ +----------+-------+-----------------+
| PA-SPAKE | 151 | [this document] | | PA-SPAKE | 151 | [this document] |
+----------+-------+-----------------+ +----------+-------+-----------------+
This document establishes two registries with the following This document establishes two registries with the following
procedure, in accordance with [RFC8126]: 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 be published prior to entry
inclusion in the registry. There will be a three-week review period inclusion in the registry. Once published, they can be submitted
by Designated Experts on the krb5-spake-review@ietf.org mailing list. directly to the krb5-spake-review@ietf.org mailing list, where there
will be a three-week long review period by Designated Experts.
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 to be conveyed to both approve or deny the request. This decision is conveyed to both IANA
the IANA and the list, and should include reasonably detailed and the submitter. Since the mailing list archives are not public,
explanation in the case of a denial as well as whether the request it should include both a reasonably detailed explanation in the case
can be resubmitted. of a denial as well as whether the request can be resubmitted.
12.1. Kerberos Second Factor Types 12.1. Kerberos Second Factor Types
This section species the IANA "Kerberos Second Factor Types" This section species the IANA "Kerberos Second Factor Types"
registry. This registry records the number, name, and reference for registry. This registry records the number, name, and reference for
each second factor protocol. each second factor 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: This is a value that uniquely identifies this entry. It
skipping to change at page 19, line 24 skipping to change at page 20, line 33
Name: Brief, unique, human-readable name for this algorithm. Name: Brief, unique, human-readable name for this algorithm.
Reference: URI or otherwise unique identifier for where the details Reference: URI or otherwise unique identifier for where the details
of this algorithm can be found. It should be as specific as of this algorithm can be found. It should be as specific as
reasonably possible. reasonably possible.
12.1.2. Initial Registry Contents 12.1.2. Initial Registry Contents
o ID Number: 1 o ID Number: 1
o Name: NONE o Name: SF-NONE
o Reference: this draft. o Reference: this draft.
12.2. Kerberos SPAKE Groups 12.2. Kerberos SPAKE Groups
This section specifies the IANA "Kerberos SPAKE Groups" registry. This section specifies the IANA "Kerberos SPAKE Groups" registry.
This registry records the number, name, specification, serialization, This registry records the number, name, specification, serialization,
multiplier length, multiplier conversion, SPAKE M constant and SPAKE multiplier length, multiplier conversion, SPAKE M and N constants,
N constant. and associated hash function.
12.2.1. Registration Template 12.2.1. Registration Template
ID Number: This is a value that uniquely identifies this entry. It ID Number: This is a value that uniquely identifies this entry. It
is a signed integer in range -2147483648 to 2147483647, inclusive. is a signed integer in 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: Brief, unique, human readable name for this entry.
Specification: Reference to the definition of the group parameters Specification: Reference to the definition of the group parameters
and operations. and operations.
Serialization: Reference to the definition of the method used to Serialization: Reference to the definition of the method used to
serialize 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: 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.
12.2.2. Initial Registry Contents 12.2.2. Initial Registry Contents
o ID Number: 1 o ID Number: 1
o Name: edwards25519 o Name: edwards25519
o Specification: [RFC7748] section 4.1 (edwards25519) o Specification: Section 4.1 of [RFC7748] (edwards25519)
o Serialization: [RFC8032] section 3.1 o Serialization: Section 3.1 of [RFC8032]
o Multiplier Length: 32 o Multiplier Length: 32
o Multiplier Conversion: [RFC8032] section 3.1 o Multiplier Conversion: Section 3.1 of [RFC8032]
o SPAKE M Constant: o SPAKE M Constant:
d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
o SPAKE N Constant: o SPAKE N Constant:
d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
o Hash function: SHA-256 ([RFC6234]) o Hash function: SHA-256 ([RFC6234])
o ID Number: 2 o ID Number: 2
o Name: P-256 o Name: P-256
o Specification: [SEC2] section 2.4.2 o Specification: Section 2.4.2 of [SEC2]
o Serialization: [SEC1] section 2.3.3 (compressed). o Serialization: Section 2.3.3 of [SEC1] (compressed format)
o Multiplier Length: 32 o Multiplier Length: 32
o Multiplier Conversion: [SEC1] section 2.3.8. o Multiplier Conversion: Section 2.3.8 of [SEC1]
o SPAKE M Constant: o SPAKE M Constant:
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
o SPAKE N Constant: o SPAKE N Constant:
03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
o Hash function: SHA-256 ([RFC6234]) o Hash function: SHA-256 ([RFC6234])
o ID Number: 3 o ID Number: 3
o Name: P-384 o Name: P-384
o Specification: [SEC2] section 2.5.1 o Specification: Section 2.5.1 of [SEC2]
o Serialization: [SEC1] section 2.3.3 (compressed). o Serialization: Section 2.3.3 of [SEC1] (compressed format)
o Multiplier Length: 48 o Multiplier Length: 48
o Multiplier Conversion: [SEC1] section 2.3.8. o Multiplier Conversion: Section 2.3.8 of [SEC1]
o SPAKE M Constant: o SPAKE M Constant:
030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664
34b363d3dc36f15314739074d2eb8613fceec2853 34b363d3dc36f15314739074d2eb8613fceec2853
o SPAKE N Constant: o SPAKE N Constant:
02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215
18f9c543bb252c5490214cf9aa3f0baab4b665c10 18f9c543bb252c5490214cf9aa3f0baab4b665c10
o Hash function: SHA-384 ([RFC6234]) o Hash function: SHA-384 ([RFC6234])
o ID Number: 4 o ID Number: 4
o Name: P-521 o Name: P-521
o Specification: [SEC2] section 2.6.1 o Specification: Section 2.6.1 of [SEC2]
o Serialization: [SEC1] section 2.3.3 (compressed). o Serialization: Section 2.3.3 of [SEC1] (compressed format)
o Multiplier Length: 66 o Multiplier Length: 66
o Multiplier Conversion: [SEC1] section 2.3.8. o Multiplier Conversion: Section 2.3.8 of [SEC1]
o SPAKE M Constant: o SPAKE M Constant:
02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1
8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5
6979962d7aa 6979962d7aa
o SPAKE N Constant: o SPAKE N Constant:
0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b
c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34
9d95575cd25 9d95575cd25
o Hash function: SHA-512 ([RFC6234]) o Hash function: SHA-512 ([RFC6234])
skipping to change at page 22, line 5 skipping to change at page 23, line 5
Specification of basic notation", CCITT Recommendation Specification of basic notation", CCITT Recommendation
X.680, July 2002. X.680, July 2002.
[CCITT.X690.2002] [CCITT.X690.2002]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[I-D.irtf-cfrg-spake2]
Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg-
spake2-06 (work in progress), August 2018.
[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>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
skipping to change at page 22, line 47 skipping to change at page 23, line 43
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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.
13.2. Non-normative References 13.2. Informative References
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<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>.
[SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based
Encrypted Key Exchange Protocols", February 2005. Encrypted Key Exchange Protocols", February 2005.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
skipping to change at page 25, line 11 skipping to change at page 26, line 11
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
} }
END END
Appendix B. SPAKE M and N Value Selection Appendix B. SPAKE M and N Value Selection
The M and N constants for the NIST groups are from The M and N values for the initial contents of the SPAKE group
[I-D.irtf-cfrg-spake2] section 4. registry were generated using the following Python snippet, which
assumes an elliptic curve implementation following the interface of
Edwards25519Point.stdbase() and Edwards448Point.stdbase() in
Appendix A of [RFC8032]:
The M and N constants for the edwards25519 group were generated using def iterhash(seed, n):
the algorithm from [I-D.irtf-cfrg-spake2] section 4 and the seed h = seed
strings "edwards25519 point generation seed (M)" and "edwards25519 for i in range(n):
point generation seed (N)". h = hashlib.sha256(h).digest()
return h
def bighash(seed, start, sz):
n = -(-sz // 32)
hashes = [iterhash(seed, i) for i in range(start, start + n)]
return b''.join(hashes)[:sz]
def canon_pointstr(ecname, s):
if ecname == 'edwards25519':
return s
elif ecname == 'edwards448':
return s[:-1] + bytes([s[-1] & 0x80])
else:
return bytes([(s[0] & 1) | 2]) + s[1:]
def gen_point(seed, ecname, ec):
for i in range(1, 1000):
hval = bighash(seed, i, len(ec.encode()))
pointstr = canon_pointstr(ecname, hval)
try:
p = ec.decode(pointstr)
if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
return pointstr, i
except Exception:
pass
The seed initial seed strings are:
o For group 1 M: edwards25519 point generation seed (M)
o For group 1 N: edwards25519 point generation seed (N)
o For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)
o For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)
o For group 3 M: 1.3.132.0.34 point generation seed (M)
o For group 3 N: 1.3.132.0.34 point generation seed (N)
o For group 4 M: 1.3.132.0.35 point generation seed (M)
o For group 4 N: 1.3.132.0.35 point generation seed (N)
Appendix C. Test Vectors Appendix C. Test Vectors
For the following text vectors: For the following text vectors:
o The key is the string-to-key of "password" with the salt o 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.
o x and y were chosen randomly within the order of the designated o x and y were chosen randomly within the order of the designated
skipping to change at page 25, line 42 skipping to change at page 27, line 39
o The SPAKEChallenge message offers only the SF-NONE second factor o The SPAKEChallenge message offers only the SF-NONE second factor
type. type.
o The KDC-REQ-BODY message contains no KDC options, the client o The KDC-REQ-BODY message contains no KDC options, the client
principal name "raeburn@ATHENA.MIT.EDU", the server principal name principal name "raeburn@ATHENA.MIT.EDU", the server principal name
"krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till "krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till
field "19700101000000Z", the nonce zero, and an etype list field "19700101000000Z", the nonce zero, and an etype list
containing only the designated encryption type. containing only the designated encryption type.
DES3 edwards25519 des3-cbc-sha1 edwards25519
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
w (PRF+ output): 686d84730cb8679ae95416c6567c6a63 w (PRF+ output): 686d84730cb8679ae95416c6567c6a63
f2c9cef124f7a3371ae81e11cad42a37 f2c9cef124f7a3371ae81e11cad42a37
w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24 w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24
f2c9cef124f7a3371ae81e11cad42a07 f2c9cef124f7a3371ae81e11cad42a07
x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723 x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723
y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25 y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25
X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e
Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028 Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028
T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362 T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362
skipping to change at page 26, line 24 skipping to change at page 28, line 22
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
1b077261656275726ea2101b0e415448454e412e4d49542e 1b077261656275726ea2101b0e415448454e412e4d49542e
454455a3233021a003020102a11a30181b066b7262746774 454455a3233021a003020102a11a30181b066b7262746774
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020110 303130313030303030305aa703020100a8053003020110
K'[0]: baf12fae7cd958cbf1a29bfbc71f89ce49e03e295d89dafd K'[0]: baf12fae7cd958cbf1a29bfbc71f89ce49e03e295d89dafd
K'[1]: 64f73dd9c41908206bcec1f719026b574f9d13463d7a2520 K'[1]: 64f73dd9c41908206bcec1f719026b574f9d13463d7a2520
K'[2]: 0454520b086b152c455829e6baeff78a61dfe9e3d04a895d K'[2]: 0454520b086b152c455829e6baeff78a61dfe9e3d04a895d
K'[3]: 4a92260b25e3ef94c125d5c24c3e5bced5b37976e67f25c4 K'[3]: 4a92260b25e3ef94c125d5c24c3e5bced5b37976e67f25c4
RC4 edwards25519 rc4-hmac edwards25519
key: 8846f7eaee8fb117ad06bdd830b7586c key: 8846f7eaee8fb117ad06bdd830b7586c
w (PRF+ output): 7c86659d29cf2b2ea93bfe79c3cefb88 w (PRF+ output): 7c86659d29cf2b2ea93bfe79c3cefb88
50e82215b3ea6fcd896561d48048f49c 50e82215b3ea6fcd896561d48048f49c
w (reduced multiplier): 2713c1583c53861520b849bfef0525cd w (reduced multiplier): 2713c1583c53861520b849bfef0525cd
4fe82215b3ea6fcd896561d48048f40c 4fe82215b3ea6fcd896561d48048f40c
x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754 x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754
y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017 y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017
X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567 X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567
Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5 Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5
T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63 T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63
skipping to change at page 27, line 6 skipping to change at page 29, line 4
6c2af1d291b726860f68bc08bfef440a 6c2af1d291b726860f68bc08bfef440a
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
1b077261656275726ea2101b0e415448454e412e4d49542e 1b077261656275726ea2101b0e415448454e412e4d49542e
454455a3233021a003020102a11a30181b066b7262746774 454455a3233021a003020102a11a30181b066b7262746774
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020117 303130313030303030305aa703020100a8053003020117
K'[0]: 770b720c82384cbb693e85411eedecba K'[0]: 770b720c82384cbb693e85411eedecba
K'[1]: 621deec88e2865837c4d3462bb50a1d5 K'[1]: 621deec88e2865837c4d3462bb50a1d5
K'[2]: 1cc8f6333b9fa3b42662fd9914fbd5bb K'[2]: 1cc8f6333b9fa3b42662fd9914fbd5bb
K'[3]: edb4032b7fc3806d5211a534dcbc390c K'[3]: edb4032b7fc3806d5211a534dcbc390c
aes128-cts-hmac-sha1-96 edwards25519
AES128 edwards25519
key: fca822951813fb252154c883f5ee1cf4 key: fca822951813fb252154c883f5ee1cf4
w (PRF+ output): 0d591b197b667e083c2f5f98ac891d3c w (PRF+ output): 0d591b197b667e083c2f5f98ac891d3c
9f99e710e464e62f1fb7c9b67936f3eb 9f99e710e464e62f1fb7c9b67936f3eb
w (reduced multiplier): 17c2a9030afb7c37839bd4ae7fdfeb17 w (reduced multiplier): 17c2a9030afb7c37839bd4ae7fdfeb17
9e99e710e464e62f1fb7c9b67936f30b 9e99e710e464e62f1fb7c9b67936f30b
x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138 x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138
y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917 y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917
X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd
Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8 Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8
T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da
skipping to change at page 27, line 38 skipping to change at page 29, line 35
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
1b077261656275726ea2101b0e415448454e412e4d49542e 1b077261656275726ea2101b0e415448454e412e4d49542e
454455a3233021a003020102a11a30181b066b7262746774 454455a3233021a003020102a11a30181b066b7262746774
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020111 303130313030303030305aa703020100a8053003020111
K'[0]: 548022d58a7c47eae8c49dccf6baa407 K'[0]: 548022d58a7c47eae8c49dccf6baa407
K'[1]: b2c9ba0e13fc8ab3a9d96b51b601cf4a K'[1]: b2c9ba0e13fc8ab3a9d96b51b601cf4a
K'[2]: 69f0ee5fdb6c237e7fcd38d9f87df1bd K'[2]: 69f0ee5fdb6c237e7fcd38d9f87df1bd
K'[3]: 78f91e2240b5ee528a5cc8d7cbebfba5 K'[3]: 78f91e2240b5ee528a5cc8d7cbebfba5
AES256 edwards25519 aes256-cts-hmac-sha1-96 edwards25519
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3 w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3
f2108f1b6aa97b381012b9400c9e3f4e f2108f1b6aa97b381012b9400c9e3f4e
w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060 w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060
f2108f1b6aa97b381012b9400c9e3f0e f2108f1b6aa97b381012b9400c9e3f0e
x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d
y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55 y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55
X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327 X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327
Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641 Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641
T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5 T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5
skipping to change at page 28, line 25 skipping to change at page 30, line 23
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: a9bfa71c95c575756f922871524b6528 K'[0]: a9bfa71c95c575756f922871524b6528
8b3f695573ccc0633e87449568210c23 8b3f695573ccc0633e87449568210c23
K'[1]: 1865a9ee1ef0640ec28ac007391cac62 K'[1]: 1865a9ee1ef0640ec28ac007391cac62
4c42639c714767a974e99aa10003015f 4c42639c714767a974e99aa10003015f
K'[2]: e57781513fefdb978e374e156b0da0c1 K'[2]: e57781513fefdb978e374e156b0da0c1
a08148f5eb26b8e157ac3c077e28bf49 a08148f5eb26b8e157ac3c077e28bf49
K'[3]: 008e6487293c3cc9fabbbcdd8b392d6d K'[3]: 008e6487293c3cc9fabbbcdd8b392d6d
cb88222317fd7fe52d12fbc44fa047f1 cb88222317fd7fe52d12fbc44fa047f1
AES256 P-256 aes256-cts-hmac-sha1-96 P-256
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): eb2984af18703f94dd5288b8596cd369 w (PRF+ output): eb2984af18703f94dd5288b8596cd369
88d0d4e83bfb2b44de14d0e95e2090bd 88d0d4e83bfb2b44de14d0e95e2090bd
w (reduced multiplier): eb2984af18703f94dd5288b8596cd369 w (reduced multiplier): eb2984af18703f94dd5288b8596cd369
88d0d4e83bfb2b44de14d0e95e2090bd 88d0d4e83bfb2b44de14d0e95e2090bd
x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e
y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33 y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33
X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2 X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2
Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735 Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735
T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d
skipping to change at page 29, line 7 skipping to change at page 31, line 4
b4484d7b6cf07b12d24984f14652de60 b4484d7b6cf07b12d24984f14652de60
KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009
1b077261656275726ea2101b0e415448454e412e4d49542e 1b077261656275726ea2101b0e415448454e412e4d49542e
454455a3233021a003020102a11a30181b066b7262746774 454455a3233021a003020102a11a30181b066b7262746774
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: 7d3b906f7be49932db22cd3463f032d0 K'[0]: 7d3b906f7be49932db22cd3463f032d0
6c9c078be4b1d076d201fc6e61ef531e 6c9c078be4b1d076d201fc6e61ef531e
K'[1]: 17d74e36f8993841fbb7feb12fa4f011 K'[1]: 17d74e36f8993841fbb7feb12fa4f011
243d3ae4d2ace55b39379294bbc4db2c 243d3ae4d2ace55b39379294bbc4db2c
K'[2]: d192c9044081a2aa6a97a6c69e2724e8 K'[2]: d192c9044081a2aa6a97a6c69e2724e8
e5671c2c9ce073dd439cdbaf96d7dab0 e5671c2c9ce073dd439cdbaf96d7dab0
K'[3]: 41e5bad6b67f12c53ce0e2720dd6a988 K'[3]: 41e5bad6b67f12c53ce0e2720dd6a988
7f877bf9463c2d5209c74c36f8d776b7 7f877bf9463c2d5209c74c36f8d776b7
AES256 P-384 aes256-cts-hmac-sha1-96 P-384
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e88 w (PRF+ output): 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e88
40cb3a486f6d80c16e1b8974016aa4b7fa43042a9b3825b1 40cb3a486f6d80c16e1b8974016aa4b7fa43042a9b3825b1
w (reduced multiplier): 0304cfc55151c6bbe889653db96dbfe0 w (reduced multiplier): 0304cfc55151c6bbe889653db96dbfe0
ba4acafc024c1e8840cb3a486f6d80c1 ba4acafc024c1e8840cb3a486f6d80c1
6e1b8974016aa4b7fa43042a9b3825b1 6e1b8974016aa4b7fa43042a9b3825b1
x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f
cfc6e62585940927468ff53d864a7a50 cfc6e62585940927468ff53d864a7a50
y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750 y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750
7e1ea9c573581a81467437419466e472 7e1ea9c573581a81467437419466e472
skipping to change at page 30, line 7 skipping to change at page 32, line 4
1b077261656275726ea2101b0e415448454e412e4d49542e 1b077261656275726ea2101b0e415448454e412e4d49542e
454455a3233021a003020102a11a30181b066b7262746774 454455a3233021a003020102a11a30181b066b7262746774
1b0e415448454e412e4d49542e454455a511180f31393730 1b0e415448454e412e4d49542e454455a511180f31393730
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: b917d37c16dd1d8567fbe379f64e1ee3 K'[0]: b917d37c16dd1d8567fbe379f64e1ee3
6ca3fd127aa4e60f97e4afa3d9e56d91 6ca3fd127aa4e60f97e4afa3d9e56d91
K'[1]: 93d40079dab229b9c79366829f4e7e72 K'[1]: 93d40079dab229b9c79366829f4e7e72
82e6a4b943ac7bac69922d516673f49a 82e6a4b943ac7bac69922d516673f49a
K'[2]: bfc4f16f12f683e71589f9a888e23287 K'[2]: bfc4f16f12f683e71589f9a888e23287
5ef293ac9793db6c919567cd7b94bcd4 5ef293ac9793db6c919567cd7b94bcd4
K'[3]: 3630e2b5b99938e7506733141e8ec344 K'[3]: 3630e2b5b99938e7506733141e8ec344
166f6407e5fc2ef107c156e764d1bc20 166f6407e5fc2ef107c156e764d1bc20
AES256 P-521 aes256-cts-hmac-sha1-96 P-521
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8 w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8
2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45
e85d1a5435d1c8c83662999722d542831f9a e85d1a5435d1c8c83662999722d542831f9a
w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1 w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1
caf95bc8425665d82370aff58b0471f3 caf95bc8425665d82370aff58b0471f3
4cce63791cfed967f0c94c16054b3e17 4cce63791cfed967f0c94c16054b3e17
03133681bece1e05219f5426bc944b0f 03133681bece1e05219f5426bc944b0f
bfb3 bfb3
x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc
skipping to change at page 31, line 20 skipping to change at page 33, line 17
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: 1eb3d10bee8fab483adcd3eb38f3ebf1 K'[0]: 1eb3d10bee8fab483adcd3eb38f3ebf1
f4feb8db96ecc035f563cf2e1115d276 f4feb8db96ecc035f563cf2e1115d276
K'[1]: 482b92781ce57f49176e4c94153cc622 K'[1]: 482b92781ce57f49176e4c94153cc622
fe247a7dbe931d1478315f856f085890 fe247a7dbe931d1478315f856f085890
K'[2]: a2c215126dd3df280aab5a27e1e0fb7e K'[2]: a2c215126dd3df280aab5a27e1e0fb7e
594192cbff8d6d8e1b6f1818d9bb8fac 594192cbff8d6d8e1b6f1818d9bb8fac
K'[3]: cc06603de984324013a01f888de6d43b K'[3]: cc06603de984324013a01f888de6d43b
410a4da2dea53509f30e433c352fb668 410a4da2dea53509f30e433c352fb668
AES256 edwards25519 with accepted optimistic challenge aes256-cts-hmac-sha1-96 edwards25519, accepted optimistic challenge
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3 w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3
f2108f1b6aa97b381012b9400c9e3f4e f2108f1b6aa97b381012b9400c9e3f4e
w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060 w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060
f2108f1b6aa97b381012b9400c9e3f0e f2108f1b6aa97b381012b9400c9e3f0e
x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64 x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64
y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103 y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103
X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c
Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61 Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61
T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118 T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118
skipping to change at page 32, line 6 skipping to change at page 33, line 51
303130313030303030305aa703020100a8053003020112 303130313030303030305aa703020100a8053003020112
K'[0]: 4569ec08b5de5c3cc19d941725913ace K'[0]: 4569ec08b5de5c3cc19d941725913ace
8d74524b521a341dc746acd5c3784d92 8d74524b521a341dc746acd5c3784d92
K'[1]: 0d96ce1a4ac0f2e280a0cfc31742b064 K'[1]: 0d96ce1a4ac0f2e280a0cfc31742b064
61d83d04ae45433db2d80478dd882a4c 61d83d04ae45433db2d80478dd882a4c
K'[2]: 58018c19315a1ba5d5bb9813b58029f0 K'[2]: 58018c19315a1ba5d5bb9813b58029f0
aec18a6f9ca59e0847de1c60bc25945c aec18a6f9ca59e0847de1c60bc25945c
K'[3]: ed7e9bffd68c54d86fb19cd3c03f317f K'[3]: ed7e9bffd68c54d86fb19cd3c03f317f
88a71ad9a5e94c28581d93fc4ec72b6a 88a71ad9a5e94c28581d93fc4ec72b6a
AES256 P-521 with rejected optimistic edwards25519 challenge aes256-cts-hmac-sha1-96 P-521, rejected edwards25519 challenge
key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1
w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8 w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8
2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45
e85d1a5435d1c8c83662999722d542831f9a e85d1a5435d1c8c83662999722d542831f9a
w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1 w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1
caf95bc8425665d82370aff58b0471f3 caf95bc8425665d82370aff58b0471f3
4cce63791cfed967f0c94c16054b3e17 4cce63791cfed967f0c94c16054b3e17
03133681bece1e05219f5426bc944b0f 03133681bece1e05219f5426bc944b0f
bfb3 bfb3
x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2 x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2
 End of changes. 82 change blocks. 
212 lines changed or deleted 320 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/