draft-ietf-kitten-krb-spake-preauth-01.txt   draft-ietf-kitten-krb-spake-preauth-02.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 Updates: 3961 (if approved) R. Harwood
Expires: March 19, 2018 Red Hat, Inc. Intended status: Standards Track Red Hat, Inc.
G. Hudson Expires: April 23, 2018 G. Hudson
MIT MIT
September 15, 2017 October 20, 2017
SPAKE Pre-Authentication SPAKE Pre-Authentication
draft-ietf-kitten-krb-spake-preauth-01 draft-ietf-kitten-krb-spake-preauth-02
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 19, 2018. This Internet-Draft will expire on April 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Properties of PAKE . . . . . . . . . . . . . . . . . . . 3 1.1. Properties of PAKE . . . . . . . . . . . . . . . . . . . 3
1.2. PAKE Algorithm Selection . . . . . . . . . . . . . . . . 3 1.2. PAKE Algorithm Selection . . . . . . . . . . . . . . . . 3
1.3. PAKE and Two-Factor Authentication . . . . . . . . . . . 4 1.3. PAKE and Two-Factor Authentication . . . . . . . . . . . 4
1.4. SPAKE Overview . . . . . . . . . . . . . . . . . . . . . 5 1.4. SPAKE Overview . . . . . . . . . . . . . . . . . . . . . 5
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. Update to Checksum Specifications . . . . . . . . . . . . . . 6
4.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7 5. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 7
4.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10 5.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 10 5.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10
4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 10
5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 11 5.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11
6. Transcript Checksum . . . . . . . . . . . . . . . . . . . . . 11 6. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 11
7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 12 7. Transcript Checksum . . . . . . . . . . . . . . . . . . . . . 12
8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 13 8. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 14
9.1. Unauthenticated Plaintext . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.2. Side Channels . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Unauthenticated Plaintext . . . . . . . . . . . . . . . 14
9.3. KDC State . . . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Side Channels . . . . . . . . . . . . . . . . . . . . . 14
9.4. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 15 10.3. KDC State . . . . . . . . . . . . . . . . . . . . . . . 15
9.5. Brute Force Attacks . . . . . . . . . . . . . . . . . . . 15 10.4. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 16
9.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 16 10.5. Brute Force Attacks . . . . . . . . . . . . . . . . . . 16
9.7. Reply-Key Encryption Type . . . . . . . . . . . . . . . . 16 10.6. Denial of Service Attacks . . . . . . . . . . . . . . . 17
9.8. KDC Authentication . . . . . . . . . . . . . . . . . . . 16 10.7. Reply-Key Encryption Type . . . . . . . . . . . . . . . 17
10. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 16 10.8. KDC Authentication . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 17
11.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11.1.1. Registration Template . . . . . . . . . . . . . . . 17 12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 18
11.1.2. Initial Registry Contents . . . . . . . . . . . . . 17 12.1.1. Registration Template . . . . . . . . . . . . . . . 18
11.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 17 12.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
11.2.1. Registration Template . . . . . . . . . . . . . . . 17
11.2.2. Initial Registry Contents . . . . . . . . . . . . . 18 12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.2.1. Registration Template . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2.2. Initial Registry Contents . . . . . . . . . . . . . 19
12.2. Non-normative References . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 23 13.2. Non-normative References . . . . . . . . . . . . . . . . 22
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 23 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 23
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 24
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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", "required checksum mechanism", and The terms "encryption type", "required checksum mechanism", and
"get_mic" are defined in [RFC3961]. "get_mic" 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", "pre-authentication facility", "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre-
and "authentication set" are defined in [RFC6113]. authentication facility", and "authentication set" are defined in
[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". The normative reference for this algorithm
is [I-D.irtf-cfrg-spake2]. 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.
skipping to change at page 6, line 30 skipping to change at page 6, line 33
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 [RFC6113] section 5.2.
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 [RFC6113] section 5.2.
4. SPAKE Pre-Authentication Message Protocol 4. Update to Checksum Specifications
[RFC3961] section 4 specifies the Kerberos checksum algorithm
profile. It does not require checksums to be deterministic. In
practice, DES-based checksum types (deprecated by [RFC6649]) use a
random confounder; all other current checksum types are
deterministic.
Future checksum types required by an encryption type MUST be
deterministic. All future checksum types SHOULD be deterministic.
This mechanism requires a deterministic checksum type for the
transcript checksum. Therefore, a KDC MUST NOT offer this mechanism
if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des-
cbc-md5.
5. 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 ([RFC6113] section 3). 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.
skipping to change at page 7, line 23 skipping to change at page 7, line 47
contain a DER encoding for the ASN.1 type PA-SPAKE. contain a DER encoding for the ASN.1 type PA-SPAKE.
PA-SPAKE ::= CHOICE { PA-SPAKE ::= CHOICE {
support [0] SPAKESupport, support [0] SPAKESupport,
challenge [1] SPAKEChallenge, challenge [1] SPAKEChallenge,
response [2] SPAKEResponse, response [2] SPAKEResponse,
encdata [3] EncryptedData, encdata [3] EncryptedData,
... ...
} }
4.1. First Pass 5.1. First Pass
The SPAKE pre-authentication exchange begins when the client sends an The SPAKE pre-authentication exchange begins when the client sends an
initial authentication service request (AS-REQ) without pre- initial authentication service request (AS-REQ) without pre-
authentication data. Upon receipt of this AS-REQ, a KDC which authentication data. Upon receipt of this AS-REQ, a KDC which
requires pre-authentication and supports SPAKE SHOULD reply with a requires pre-authentication and supports SPAKE SHOULD reply with a
KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty
PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA
elements). This message indicates to the client that the KDC elements). This message indicates to the client that the KDC
supports SPAKE pre-authentication. supports SPAKE pre-authentication.
4.2. Second Pass 5.2. Second Pass
Once the client knows that the KDC supports SPAKE pre-authentication Once the client knows that the KDC supports SPAKE pre-authentication
and the client desires to use it, the client will generate a new AS- and the client desires to use it, the client will generate a new AS-
REQ message containing a PA-SPAKE PA-DATA element using the support REQ message containing a PA-SPAKE PA-DATA element using the support
choice. This message indicates to the KDC which groups the client choice. This message indicates to the KDC which groups the client
prefers for the SPAKE operation. The group numbers are defined in prefers for the SPAKE operation. The group numbers are defined in
the IANA "Kerberos SPAKE Groups" registry created by this document. the IANA "Kerberos SPAKE Groups" registry created by this document.
The groups sequence is ordered from the most preferred group to the The groups sequence is ordered from the most preferred group to the
least preferred group. least preferred group.
SPAKESupport ::= SEQUENCE { SPAKESupport ::= SEQUENCE {
groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32,
... ...
} }
The client and KDC initialize a transcript checksum (Section 6) and The client and KDC initialize a transcript checksum (Section 7) and
update it with the DER-encoded PA-SPAKE message. update it with the DER-encoded PA-SPAKE message.
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. hopes that the client might support it. Otherwise, the KDC MUST
respond with a KDC_ERR_PREAUTH_FAILED error.
Once the KDC has selected a group, the KDC will reply to the client Once the KDC has selected a group, the KDC will reply to the client
with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE
PA-DATA element using the challenge choice. The client and KDC PA-DATA element using the challenge choice. The client and KDC
update the transcript checksum with the DER-encoded PA-SPAKE message. update the transcript checksum with the DER-encoded PA-SPAKE message.
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 generated using the M
constant in the SPAKE algorithm, with inputs and conversions as constant in the SPAKE algorithm, with inputs and conversions as
specified in Section 5. specified in Section 6.
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.
4.3. Third Pass 5.3. Third Pass
Upon receipt of the challenge message, the client will complete its Upon receipt of the challenge message, the client will complete its
part of of the SPAKE algorithm, generating a public key and computing part of of the SPAKE algorithm, generating a public key and computing
the shared secret K. The client will then choose one of the second the shared secret K. The client will then choose one of the second
factor types listed in the factors field of the challenge message and factor types listed in the factors field of the challenge message and
gather whatever data is required for the chosen second factor type, gather whatever data is required for the chosen second factor type,
possibly using the associated challenge data. Finally, the client possibly using the associated challenge data. Finally, the client
will send an AS-REQ containing a PA-SPAKE PA-DATA element using the will send an AS-REQ containing a PA-SPAKE PA-DATA element using the
response choice. response choice.
skipping to change at page 9, line 21 skipping to change at page 9, line 48
factor [1] EncryptedData, -- SPAKESecondFactor factor [1] EncryptedData, -- SPAKESecondFactor
... ...
} }
The client and KDC will update the transcript checksum with the The client and KDC will update the transcript checksum with the
pubkey value, and use the resulting checksum for all encryption key pubkey value, and use the resulting checksum for all encryption key
derivations. derivations.
The pubkey field indicates the client's public key generated using The pubkey field indicates the client's public key generated using
the N constant in the SPAKE algorithm, with inputs and conversions as the N constant in the SPAKE algorithm, with inputs and conversions as
specified in Section 5. specified in Section 6.
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 8. The key
usage number for the encryption is KEY_USAGE_SPAKE_FACTOR. The plain usage number for the encryption is KEY_USAGE_SPAKE_FACTOR. The plain
text inside the EncryptedData is an encoding of SPAKESecondFactor. text inside the EncryptedData is an encoding of SPAKESecondFactor.
Once decoded, the SPAKESecondFactor contains the type of the second Once decoded, the SPAKESecondFactor contains the type of the second
factor and any optional data used. The contents of the data field factor and any optional data used. The contents of the data field
will depend on the second factor type chosen. The client MUST NOT will depend on the second factor type chosen. The client MUST NOT
send a response containing a second factor type which was not listed send a response containing a second factor type which was not listed
in the factors field of the challenge message. 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 will
use the pubkey to compute the SPAKE result, derive K'[1], and decrypt use the pubkey to compute the SPAKE result, derive K'[1], and decrypt
the factors field. If decryption is successful, the first factor is the factors field. If decryption is successful, the first factor is
successfully validated. The KDC then validates the second factor. successfully validated. The KDC then validates the second factor.
If either factor fails to validate, the KDC SHOULD respond with an If either factor fails to validate, the KDC SHOULD respond with a
appropriate KRB-ERROR message. 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, key for the EncryptedData value is K'[2] as specified in Section 8,
and the key usage number is KEY_USAGE_SPAKE_FACTOR. The plain text and the key usage number is KEY_USAGE_SPAKE_FACTOR. The plain text
of this message contains a DER-encoded SPAKESecondFactor message. As of this message contains a DER-encoded SPAKESecondFactor message. As
before, the type field of this message will contain the second factor before, the type field of this message will contain the second factor
type, and the data field will optionally contain second factor type type, and the data field will optionally contain second factor type
specific data. specific data.
KEY_USAGE_SPAKE_FACTOR 65 KEY_USAGE_SPAKE_FACTOR 65
4.4. Subsequent Passes 5.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
exchange. exchange.
The key for client-originated encdata messages in subsequent passes The key for client-originated encdata messages in subsequent passes
is K'[3] as specified in Section 7 for the first subsequent pass, is K'[3] as specified in Section 8 for the first subsequent pass,
K'[5] for the second, and so on. The key for KDC-originated encdata K'[5] for the second, and so on. The key for KDC-originated encdata
messages is K'[4] for the first subsequent pass, K'[6] for the messages is K'[4] for the first subsequent pass, K'[6] for the
second, and so on. second, and so on.
4.5. Reply Key Strengthening 5.5. Reply Key Strengthening
When the KDC has successfully validated both factors, the reply key When the KDC has successfully validated both factors, the reply key
is strengthened and the mechanism is complete. To strengthen the is strengthened and the mechanism is complete. To strengthen the
reply key, the client and KDC replace it with K'[0] as specified in reply key, the client and KDC replace it with K'[0] as specified in
Section 7. The KDC then replies with a KDC-REP message, or continues Section 8. The KDC then replies with a KDC-REP message, or continues
on to the next mechanism in the authentication set. There is no on to the next mechanism in the authentication set. There is no
final PA-SPAKE PA-DATA message from the KDC to the client. final PA-SPAKE PA-DATA message from the KDC to the client.
Reply key strengthening occurs only once at the end of the exchange. Reply key strengthening occurs only once at the end of the exchange.
The client and KDC MUST use the initial reply key as the base key for The client and KDC MUST use the initial reply key as the base key for
all K'[n] derivations. all K'[n] derivations.
4.6. Optimizations 5.6. Optimizations
The full protocol has two possible optimizations. The full protocol has two possible optimizations.
First, the KDC MAY reply to the initial AS-REQ (containing no pre- First, the KDC MAY reply to the initial AS-REQ (containing no pre-
authentication data) with a PA-SPAKE PA-DATA element using the authentication data) with a PA-SPAKE PA-DATA element using the
challenge choice, instead of an empty padata-value. In this case, challenge choice, instead of an empty padata-value. In this case,
the KDC optimistically selects a group which the client may not the KDC optimistically selects a group which the client may not
support. If the group chosen by the challenge message is supported support. If the group chosen by the challenge message is supported
by the client, the client MUST skip to the third pass by issuing an by the client, the client MUST skip to the third pass by issuing an
AS-REQ with a PA-SPAKE message using the response choice. If the AS-REQ with a PA-SPAKE message using the response choice. If the
KDC's chosen group is not supported by the client, the client MUST KDC's chosen group is not supported by the client, the client MUST
initialize and update the transcript checksum with the KDC's initialize and update the transcript checksum with the KDC's
challenge message, and then continue to the second pass. Clients challenge message, and then continue to the second pass. Clients
MUST support this optimization. MUST support this optimization.
Second, clients MAY skip the first pass and send an AS-REQ with a PA- Second, clients MAY skip the first pass and send an AS-REQ with a PA-
SPAKE PA-DATA element using the support choice. The KDC MUST include SPAKE PA-DATA element using the support choice. If the KDC accepts
a PA-ETYPE-INFO2 value within the METHOD-DATA of the the support message and generates a challenge, it MUST include a PA-
ETYPE-INFO2 value within the METHOD-DATA of the
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may
not otherwise be able to compute the initial reply key. KDCs MUST not otherwise be able to compute the initial reply key. If the KDC
support this optimization. cannot continue with SPAKE (either because initial reply key type is
incompatible with SPAKE or because it does not support any of the
client's groups) but can offer other pre-authentication mechanisms,
it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing
METHOD-DATA. A client supporting this optimization MUST continue
after a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113]
section 2. KDCs MUST support this optimization.
5. SPAKE Parameters and Conversions 6. SPAKE Parameters and Conversions
Group elements are converted to octet strings using the serialization Group elements are converted to octet strings using the serialization
method defined in the IANA "Kerberos SPAKE Groups" registry created method defined in the IANA "Kerberos SPAKE Groups" registry created
by this document. 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
skipping to change at page 11, line 41 skipping to change at page 12, line 29
[RFC6113] section 5.1. [RFC6113] section 5.1.
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 9.3). initial reply keys (see Section 10.3).
6. Transcript Checksum 7. Transcript Checksum
The transcript checksum is an octet string of length equal to the The transcript checksum is an octet string of length equal to the
output length of the required checksum type of the encryption type of output length of the required checksum type of the encryption type of
the initial reply key. The initial value consists of all bits set to the initial reply key. The initial value consists of all bits set to
zero. zero.
When the transcript checksum is updated with an octet string input, When the transcript checksum is updated with an octet string input,
the new value is the get_mic result computed over the concatenation the new value is the get_mic result computed over the concatenation
of the old value and the input, for the required checksum type of the of the old value and the input, for the required checksum type of the
initial reply key's encryption type, using the initial reply key and initial reply key's encryption type, using the initial reply key and
the key usage number KEY_USAGE_SPAKE_TRANSCRIPT. the key usage number KEY_USAGE_SPAKE_TRANSCRIPT.
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 checksum is first updated with the in Section 5.6, the transcript checksum is first updated with the
client's support message, then the KDC's challenge message, and client's support message, then the KDC's challenge message, and
finally with the client's pubkey value. It therefore incorporates finally with the client's pubkey value. It therefore incorporates
the client's supported groups, the KDC's chosen group, the KDC's the client's supported groups, the KDC's chosen group, the KDC's
initial second-factor messages, and the client and KDC public values. initial second-factor messages, and the client and KDC public values.
Once the transcript checksum is finalized, it is used without change Once the transcript checksum is finalized, it is used without change
for all key derivations (Section 7). for all key derivations (Section 8).
If the first optimization described in Section 4.6 is used If the first optimization described in Section 5.6 is used
successfully, the transcript checksum is updated only with the KDC's successfully, the transcript checksum is updated only with the KDC's
challenge message and the client's pubkey value. challenge message and 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 checksum is not accept the KDC's selected group), the transcript checksum is
updated with the KDC's optimistic challenge message, then with the updated with the KDC's optimistic challenge message, then with the
client's support message, then the KDC's second challenge message, client's support message, then the KDC's second challenge message,
and finally with the client's pubkey value. and finally with the client's pubkey value.
KEY_USAGE_SPAKE_TRANSCRIPT 66 KEY_USAGE_SPAKE_TRANSCRIPT 66
7. Key Derivation 8. Key Derivation
Implementations MUST NOT use the SPAKE result (denoted by K in Implementations MUST NOT use the SPAKE result (denoted by K in
Section 2 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any Section 2 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any
cryptographic operation. Instead, the SPAKE result is used to derive cryptographic operation. Instead, the SPAKE result is used to derive
keys K'[n] as defined in this section. This method differs slightly keys K'[n] as defined in this section. This method differs slightly
from the method used to generate K' in Section 3 of SPAKE from the method used to generate K' in Section 3 of SPAKE
[I-D.irtf-cfrg-spake2]. [I-D.irtf-cfrg-spake2].
An input string is assembled by concatenating the following values: An input string is assembled by concatenating the following values:
o The fixed string "SPAKEkey". o The fixed string "SPAKEkey".
o The group number as a big-endian four-byte unsigned binary number. o The group number as a big-endian four-byte unsigned binary 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-
byte unsigned binary number. byte unsigned binary number.
o The SPAKE result K, converted to an octet string as specified in o The SPAKE result K, converted to an octet string as specified in
Section 5. Section 6.
o The transcript checksum. o The transcript checksum.
o The KDC-REQ-BODY encoding for the request being sent or responded o The KDC-REQ-BODY encoding for the request being sent or responded
to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST
be used. be used.
o The value n as a big-endian four-byte unsigned binary number. o The value n as a big-endian four-byte unsigned binary number.
The derived key K'[n] has the same encryption type as the initial The derived key K'[n] has the same encryption type as the initial
reply key, and has the value random-to-key(PRF+(initial-reply-key, reply key, and has the value random-to-key(PRF+(initial-reply-key,
input-string)). PRF+ is defined in [RFC6113] section 5.1. input-string)). PRF+ is defined in [RFC6113] section 5.1.
8. Second Factor Types 9. 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. Security Considerations 10. Security Considerations
All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2] All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2]
apply here as well. apply here as well.
9.1. Unauthenticated Plaintext 10.1. 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 checksum this plaintext is ensured by incorporating the transcript checksum
into the derivation of the final reply key and second factor into the derivation of the final reply key and second factor
encryption keys. Downgrade attacks on support and challenge messages encryption keys. Downgrade attacks on support and challenge messages
will result in the client and KDC deriving different reply keys and will 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.
skipping to change at page 14, line 7 skipping to change at page 14, line 46
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.
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, unless the
attacker knows the client's long-term key. attacker knows the client's long-term key.
9.2. Side Channels 10.2. 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 14, line 46 skipping to change at page 15, line 36
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 a minor risk in
all known groups, but is a major risk for P-521 due to the extra all known groups, but is a major risk for P-521 due to the extra
seven high bits in the input octet string. A common solution to this seven high bits in the input octet string. A common solution to this
problem is achieved by reducing the multiplier modulo the group problem is achieved by reducing the multiplier modulo the group
order, taking care to ensure constant time operation. order, taking care to ensure constant time operation.
9.3. KDC State 10.3. 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 value to remember its private scalar value x and the transcript
checksum. The KDC MUST maintain confidentiality and integrity of the checksum. The KDC MUST maintain confidentiality and integrity of the
cookie value, perhaps by encrypting it in a key known only to the cookie value, perhaps by encrypting it in a key known only to the
realm's KDCs. Cookie values may be replayed by attackers. The KDC realm's KDCs. Cookie values may be replayed by attackers. The KDC
SHOULD limit the time window of replays using a timestamp, and SHOULD SHOULD limit the time window of replays using a timestamp, and SHOULD
prevent cookie values from being applied to other pre-authentication prevent cookie values from being applied to other pre-authentication
mechanisms or other client principals. Within the validity period of mechanisms or other client principals. Within the validity period of
a cookie, an attacker can replay the final message of a pre- a cookie, an attacker can replay the final message of a pre-
skipping to change at page 15, line 30 skipping to change at page 16, line 20
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.
9.4. Dictionary Attacks 10.4. 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
encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error
from the KDC, if encrypted timestamp is offered by the KDC and not
disabled by client configuration. This fallback will enable a
passive attacker to mount an offline dictionary attack against the
incorrect password, which may be similar to the correct password.
Client implementations SHOULD assume that encrypted timestamp and
encrypted challenge are unlikely to succeed if SPAKE pre-
authentication fails in the second pass and no second factor was
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 password lockout to
mitigate the risk of online attacks. mitigate the risk of online attacks.
9.5. Brute Force Attacks 10.5. 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.
9.6. Denial of Service Attacks 10.6. 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.
9.7. Reply-Key Encryption Type 10.7. 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.
9.8. KDC Authentication 10.8. 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.
10. Assigned Constants 11. Assigned Constants
The following key usage values are assigned for this mechanism: The following key usage values are assigned for this mechanism:
KEY_USAGE_SPAKE_TRANSCRIPT 65 KEY_USAGE_SPAKE_TRANSCRIPT 65
KEY_USAGE_SPAKE_FACTOR 66 KEY_USAGE_SPAKE_FACTOR 66
11. IANA Considerations 12. IANA Considerations
The notes for the "Kerberos Checksum Type Numbers" registry should be
updated with the following addition: "If the checksum algorithm is
non-deterministic, see [this document] Section 4."
This document establishes two registries with the following This document establishes two registries with the following
procedure, in accordance with [RFC5226]: procedure, in accordance with [RFC5226]:
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. There will be a three-week review period
by Designated Experts on the krb5-spake-review@ietf.org mailing list. by Designated Experts on the krb5-spake-review@ietf.org mailing list.
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 to be conveyed to both
the IANA and the list, and should include reasonably detailed the IANA and the list, and should include reasonably detailed
explanation in the case of a denial as well as whether the request explanation in the case of a denial as well as whether the request
can be resubmitted. can be resubmitted.
11.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.
11.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
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 algorithms only. Zero is reserved and must not be experimental algorithms only. Zero is reserved and must not be
assigned. assigned.
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.
11.1.2. Initial Registry Contents 12.1.2. Initial Registry Contents
o ID Number: 1 o ID Number: 1
o Name: NONE o Name: NONE
o Reference: this draft. o Reference: this draft.
11.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 constant and SPAKE
N constant. N constant.
11.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.
skipping to change at page 18, line 25 skipping to change at page 19, line 35
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.
11.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: [RFC7748] section 4.1 (edwards25519)
o Serialization: [RFC8032] section 3.1 o Serialization: [RFC8032] section 3.1
o Multiplier Length: 32 o Multiplier Length: 32
o Multiplier Conversion: [RFC8032] section 3.1 o Multiplier Conversion: [RFC8032] section 3.1
o SPAKE M Constant: o SPAKE M Constant:
5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e 5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e
o SPAKE N Constant: o SPAKE N Constant:
skipping to change at page 19, line 33 skipping to change at page 20, line 44
o Multiplier Conversion: [SEC1] section 2.3.8. o Multiplier Conversion: [SEC1] section 2.3.8.
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
12. References 13. References
12.1. Normative References 13.1. Normative References
[CCITT.X680.2002] [CCITT.X680.2002]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1): Committee, "Abstract Syntax Notation One (ASN.1):
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
skipping to change at page 20, line 45 skipping to change at page 22, line 9
RFC8032, January 2017, <https://www.rfc-editor.org/info/ RFC8032, January 2017, <https://www.rfc-editor.org/info/
rfc8032>. rfc8032>.
[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.
12.2. Non-normative References 13.2. Non-normative References
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011, <https://www.rfc- 10.17487/RFC6234, May 2011, <https://www.rfc-
editor.org/info/rfc6234>. editor.org/info/rfc6234>.
[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>.
[RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-
EXP, and Other Weak Cryptographic Algorithms in Kerberos",
BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012,
<https://www.rfc-editor.org/info/rfc6649>.
[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
KerberosV5SPAKE { KerberosV5SPAKE {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) spake(8) security(5) kerberosV5(2) modules(4) spake(8)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
 End of changes. 55 change blocks. 
94 lines changed or deleted 141 lines changed or added

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