draft-ietf-kitten-pkinit-alg-agility-08.txt   rfc8636.txt 
Kitten Working Group L. Hornquist Astrand Internet Engineering Task Force (IETF) L. Hornquist Astrand
Internet-Draft Apple, Inc Request for Comments: 8636 Apple, Inc
Updates: 4556 (if approved) L. Zhu Updates: 4556 L. Zhu
Intended status: Standards Track Oracle Corporation Category: Standards Track Oracle Corporation
Expires: October 22, 2019 M. Wasserman ISSN: 2070-1721 M. Cullen
Painless Security Painless Security
G. Hudson G. Hudson
MIT MIT
April 20, 2019 July 2019
PKINIT Algorithm Agility Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
draft-ietf-kitten-pkinit-alg-agility-08 Algorithm Agility
Abstract Abstract
This document updates the Public Key Cryptography for Initial This document updates the Public Key Cryptography for Initial
Authentication in Kerberos standard (PKINIT) [RFC4556], to remove Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove
protocol structures tied to specific cryptographic algorithms. The protocol structures tied to specific cryptographic algorithms. The
PKINIT key derivation function is made negotiable, and the digest PKINIT key derivation function is made negotiable, and the digest
algorithms for signing the pre-authentication data and the client's algorithms for signing the pre-authentication data and the client's
X.509 certificates are made discoverable. X.509 certificates are made discoverable.
These changes provide preemptive protection against vulnerabilities These changes provide preemptive protection against vulnerabilities
discovered in the future against any specific cryptographic discovered in the future in any specific cryptographic algorithm and
algorithm, and allow incremental deployment of newer algorithms. allow incremental deployment of newer algorithms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 22, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8636.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
skipping to change at page 2, line 37 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 5
5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. KDF Agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13 8.3. Test Vector for SHA-256, enctype 18 . . . . . . . . . . . 13
8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13 8.4. Test Vector for SHA-512, enctype 16 . . . . . . . . . . . 13
8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 18
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Public Key Cryptography for Initial Authentication in Kerberos The Public Key Cryptography for Initial Authentication in Kerberos
(PKINIT) standard [RFC4556] defines several protocol structures that (PKINIT) standard [RFC4556] defines several protocol structures that
are either tied to SHA-1 [RFC6234], or do not support negotiation or are either tied to SHA-1 [RFC6234] or do not support negotiation or
discovery, but are instead based on local policy: discovery but are instead based on local policy:
o The checksum algorithm in the authentication request is hardwired o The checksum algorithm in the authentication request is hardwired
to use SHA-1. to use SHA-1.
o The acceptable digest algorithms for signing the authentication o The acceptable digest algorithms for signing the authentication
data are not discoverable. data are not discoverable.
o The key derivation function in Section 3.2.3.1 of [RFC4556] is o The key derivation function in Section 3.2.3.1 of [RFC4556] is
hardwired to use SHA-1. hardwired to use SHA-1.
o The acceptable digest algorithms for signing the client X.509 o The acceptable digest algorithms for signing the client X.509
certificates are not discoverable. certificates are not discoverable.
In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150]
collisions generated using hand calculation [WANG04], alongside collisions [WANG04], alongside attacks on later hash functions
attacks on later hash function designs in the MD4, MD5 [RFC1321] and including MD5 [RFC1321] and SHA-1 [RFC6234]. These attacks and their
SHA [RFC6234] family. These attacks and their consequences are consequences are discussed in [RFC6194]. These discoveries
discussed in [RFC6194]. These discoveries challenged the security of challenged the security of protocols relying on the collision-
protocols relying on the collision resistance properties of these resistance properties of these hashes.
hashes.
The Internet Engineering Task Force (IETF) called for actions to The Internet Engineering Task Force (IETF) called for action to
update existing protocols to provide crypto algorithm agility so that update existing protocols to provide crypto algorithm agility so that
protocols support multiple cryptographic algorithms (including hash protocols support multiple cryptographic algorithms (including hash
functions) and provide clean, tested transition strategies between functions) and provide clean, tested transition strategies between
algorithms, as recommended by BCP 201 [RFC7696]. algorithms, as recommended by BCP 201 [RFC7696].
To address these concerns, new key derivation functions (KDFs), To address these concerns, new key derivation functions (KDFs),
identified by object identifiers, are defined. The PKINIT client identified by object identifiers, are defined. The PKINIT client
provides a list of KDFs in the request and the Key Distribution provides a list of KDFs in the request, and the Key Distribution
Center (KDC) picks one in the response, thus a mutually-supported KDF Center (KDC) picks one in the response. Thus, a mutually supported
is negotiated. KDF is negotiated.
Furthermore, structures are defined to allow the client to discover Furthermore, structures are defined to allow the client to discover
the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms
supported by the KDC for signing the pre-authentication data and supported by the KDC for signing the pre-authentication data and the
signing the client X.509 certificate. client X.509 certificate.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. paChecksum Agility 3. paChecksum Agility
The paChecksum defined in Section 3.2.1 of [RFC4556] provides a The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
cryptographic binding between the client's pre-authentication data cryptographic binding between the client's pre-authentication data
and the corresponding Kerberos request body. This also prevents the and the corresponding Kerberos request body. This also prevents the
KDC-REQ body from being tampered with. SHA-1 is the only allowed KDC-REQ body from being tampered with. SHA-1 is the only allowed
checksum algorithm defined in [RFC4556]. This facility relies on the checksum algorithm defined in [RFC4556]. This facility relies on the
collision resistance properties of the SHA-1 checksum [RFC6234]. collision-resistance properties of the SHA-1 checksum [RFC6234].
When the reply key delivery mechanism is based on public key When the reply key delivery mechanism is based on public key
encryption as described in Section 3.2.3.2 of [RFC4556], the encryption as described in Section 3.2.3.2 of [RFC4556], the
asChecksum in the KDC reply provides the binding between the pre- asChecksum in the KDC reply provides integrity protection for the
authentication and the ticket request and response messages, and unauthenticated clear text in these messages and the binding between
integrity protection for the unauthenticated clear text in these the pre-authentication and the ticket request and response messages.
messages. However, if the reply key delivery mechanism is based on However, if the reply key delivery mechanism is based on the Diffie-
the Diffie-Hellman key agreement as described in Section 3.2.3.1 of Hellman key agreement as described in Section 3.2.3.1 of [RFC4556],
[RFC4556], the security provided by using SHA-1 in the paChecksum is the security provided by using SHA-1 in the paChecksum is weak, and
weak, and nothing else cryptographically binds the AS request to the nothing else cryptographically binds the Authentication Service (AS)
ticket response. In this case, the new KDF selected by the KDC as request to the ticket response. In this case, the new KDF selected
described in Section 6 provides the cryptographic binding and by the KDC, as described in Section 6, provides the cryptographic
integrity protection. binding and integrity protection.
4. CMS Digest Algorithm Agility 4. CMS Digest Algorithm Agility
Section 3.2.2 of [RFC4556] is updated to add optional typed data to Section 3.2.2 of [RFC4556] is updated to add optional typed data to
the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC
implementation conforming to this specification returns this error implementation conforming to this specification returns this error
code, it MAY include in a list of supported CMS types signifying the code, it MAY include a list of supported CMS types signifying the
digest algorithms supported by the KDC, in the decreasing preference digest algorithms supported by the KDC in decreasing order of
order. This is accomplished by including a preference. This is accomplished by including a
TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data. TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.
td-cms-digest-algorithms INTEGER ::= 111 td-cms-digest-algorithms INTEGER ::= 111
The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded the TD-CMS-DIGEST-ALGORITHMS-DATA structure, which is ASN.1
TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: Distinguished Encoding Rules (DER) [X680] [X690] encoded and is
defined as follows:
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in -- acceptable to the KDC for signing CMS data in
-- the order of decreasing preference. -- decreasing order of preference.
The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy The algorithm identifiers in TD-CMS-DIGEST-ALGORITHMS identify the
digest algorithms supported by the KDC. digest algorithms supported by the KDC.
This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
can facilitate trouble-shooting when none of the digest algorithms can facilitate troubleshooting when none of the digest algorithms
supported by the client is supported by the KDC. supported by the client is supported by the KDC.
5. X.509 Certificate Signer Algorithm Agility 5. X.509 Certificate Signer Algorithm Agility
Section 3.2.2 of [RFC4556] is updated to add optional typed data to Section 3.2.2 of [RFC4556] is updated to add optional typed data to
the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming
to this specification returns this error, it MAY send a list of to this specification returns this error, it MAY send a list of
digest algorithms acceptable to the KDC for use by the Certificate digest algorithms acceptable to the KDC for use by the certification
Authority (CA) in signing the client's X.509 certificate, in the authority (CA) in signing the client's X.509 certificate in
decreasing preference order. This is accomplished by including a decreasing order of preference. This is accomplished by including a
TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The
corresponding data contains the ASN.1 DER encoding of the structure corresponding data contains the ASN.1 DER encoding of the TD-CERT-
TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: DIGEST-ALGORITHMS-DATA structure defined as follows:
td-cert-digest-algorithms INTEGER ::= 112 td-cert-digest-algorithms INTEGER ::= 112
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's -- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC -- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509 -- in the process of validating the client's X.509
-- certificate, in the order of decreasing -- certificate in decreasing order of
-- preference. -- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was -- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and -- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of -- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate -- validating the client's X.509 certificate
-- [RFC5280]. -- [RFC5280].
... ...
} }
The KDC fills in the allowedAlgorithm field with the list of The KDC fills in the allowedAlgorithm field with the list of
algorithm [RFC5652] identifiers indicating digest algorithms that are algorithm [RFC5652] identifiers indicating digest algorithms that are
used by the CA to sign the client's X.509 certificate and are used by the CA to sign the client's X.509 certificate and are
acceptable to the KDC in the process of validating the client's X.509 acceptable to the KDC in the process of validating the client's X.509
certificate, in the order of decreasing preference. The certificate in decreasing order of preference. The rejectedAlgorithm
rejectedAlgorithm field identifies the signing algorithm for use in field identifies the signing algorithm for use in signing the
signing the client's X.509 certificate that has been rejected by the client's X.509 certificate that has been rejected by the KDC in the
KDC in the process of validating the client's certificate [RFC5280]. process of validating the client's certificate [RFC5280].
6. KDF agility 6. KDF Agility
Section 3.2.3.1 of [RFC4556] is updated to define additional Key Section 3.2.3.1 of [RFC4556] is updated to define additional key
Derivation Functions (KDFs) to derive a Kerberos protocol key based derivation functions (KDFs) to derive a Kerberos protocol key based
on the secret value generated by the Diffie-Hellman key exchange. on the secret value generated by the Diffie-Hellman key exchange.
Section 3.2.1 of [RFC4556] is updated to add a new field to the Section 3.2.1 of [RFC4556] is updated to add a new field to the
AuthPack structure to indicate which new KDFs are supported by the AuthPack structure to indicate which new KDFs are supported by the
client. Section 3.2.3 of [RFC4556] is updated to add a new field to client. Section 3.2.3 of [RFC4556] is updated to add a new field to
the DHRepInfo structure to indicate which KDF is selected by the KDC. the DHRepInfo structure to indicate which KDF is selected by the KDC.
The KDF algorithm described in this document (based on [SP80056A]) The KDF algorithm described in this document (based on [SP80056A])
can be implemented using any cryptographic hash function. can be implemented using any cryptographic hash function.
A new KDF for PKINIT usage is identified by an object identifier. A new KDF for PKINIT usage is identified by an object identifier.
skipping to change at page 7, line 31 skipping to change at page 7, line 34
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha512(3) } ::= { id-pkinit-kdf sha512(3) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-512 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) } ::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384
Where id-pkinit is defined in [RFC4556]. All key derivation Where id-pkinit is defined in [RFC4556]. All key derivation
functions specified above use the one-step key derivation method functions specified above use the one-step key derivation method
described in Section 5.8.2.1 of [SP80056A], using the ASN.1 format described in Section 5.8.2.1 of [SP80056A], choosing the ASN.1 format
for FixedInfo, and Section 4.1 of [SP80056C], using option 1 for the for FixedInfo, and Section 4.1 of [SP80056C], choosing option 1 for
auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as the auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234]
the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356, as the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-
and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 ([RFC6234] sha356, and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384
and SHA-512 [RFC6234] respectively. [RFC6234], and SHA-512 [RFC6234], respectively.
To name the input parameters, an abbreviated version of the key To name the input parameters, an abbreviated version of the key
derivation method is described below. derivation method is described below.
1. reps = ceiling(L/H_outputBits) 1. reps = ceiling(L/H_outputBits)
2. Initialize a 32-bit, big-endian bit string counter as 1. 2. Initialize a 32-bit, big-endian bit string counter as 1.
3. For i = 1 to reps by 1, do the following: 3. For i = 1 to reps by 1, do the following:
1. Compute Hashi = H(counter || Z || OtherInfo). 1. Compute Hashi = H(counter || Z || OtherInfo).
2. Increment counter (not to exceed 2^32-1) 2. Increment counter (not to exceed 2^32-1)
4. Set key_material = Hash1 || Hash2 || ... so that the length of 4. Set key_material = Hash1 || Hash2 || ... so that the length of
key_material is L bits, truncating the last block as necessary. key_material is L bits, truncating the last block as necessary.
5. The above KDF produces a bit string of length L in bits as the 5. The above KDF produces a bit string of length L in bits as the
keying material. The AS reply key is the output of random-to- keying material. The AS reply key is the output of random-to-
key() [RFC3961] using that keying material as the input. key() [RFC3961], using that keying material as the input.
The input parameters for these KDFs are provided as follows: The input parameters for these KDFs are provided as follows:
o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for
id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and
512 bits for id-pkinit-kdf-ah-sha512. 512 bits for id-pkinit-kdf-ah-sha512.
o max_H_inputBits is 2^64. o max_H_inputBits is 2^64.
o The secret value (Z) is the shared secret value generated by the o The secret value (Z) is the shared secret value generated by the
skipping to change at page 8, line 40 skipping to change at page 8, line 40
o The algorithm identifier (algorithmID) input parameter is the o The algorithm identifier (algorithmID) input parameter is the
identifier of the respective KDF. For example, this is id-pkinit- identifier of the respective KDF. For example, this is id-pkinit-
kdf-ah-sha1 if the KDF uses SHA-1 as the hash. kdf-ah-sha1 if the KDF uses SHA-1 as the hash.
o The initiator identifier (partyUInfo) contains the ASN.1 DER o The initiator identifier (partyUInfo) contains the ASN.1 DER
encoding of the KRB5PrincipalName [RFC4556] that identifies the encoding of the KRB5PrincipalName [RFC4556] that identifies the
client as specified in the AS-REQ [RFC4120] in the request. client as specified in the AS-REQ [RFC4120] in the request.
o The recipient identifier (partyVInfo) contains the ASN.1 DER o The recipient identifier (partyVInfo) contains the ASN.1 DER
encoding of the KRB5PrincipalName [RFC4556] that identifies the encoding of the KRB5PrincipalName [RFC4556] that identifies the
TGS as specified in the AS-REQ [RFC4120] in the request. ticket-granting server (TGS) as specified in the AS-REQ [RFC4120]
in the request.
o The supplemental public information (suppPubInfo) is the ASN.1 DER o The supplemental public information (suppPubInfo) is the ASN.1 DER
encoding of the structure PkinitSuppPubInfo as defined later in encoding of the PkinitSuppPubInfo structure, as defined later in
this section. this section.
o The supplemental private information (suppPrivInfo) is absent. o The supplemental private information (suppPrivInfo) is absent.
OtherInfo is the ASN.1 DER encoding of the following sequence: OtherInfo is the ASN.1 DER encoding of the following sequence:
OtherInfo ::= SEQUENCE { OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier, algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING, partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING, partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL, suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL suppPrivInfo [3] OCTET STRING OPTIONAL
} }
The structure PkinitSuppPubInfo is defined as follows: The PkinitSuppPubInfo structure is defined as follows:
PkinitSuppPubInfo ::= SEQUENCE { PkinitSuppPubInfo ::= SEQUENCE {
enctype [0] Int32, enctype [0] Int32,
-- The enctype of the AS reply key. -- The enctype of the AS reply key.
as-REQ [1] OCTET STRING, as-REQ [1] OCTET STRING,
-- The DER encoding of the AS-REQ [RFC4120] from the -- The DER encoding of the AS-REQ [RFC4120] from the
-- client. -- client.
pk-as-rep [2] OCTET STRING, pk-as-rep [2] OCTET STRING,
-- The DER encoding of the PA-PK-AS-REP [RFC4556] in the -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
-- KDC reply. -- KDC reply.
... ...
} }
The PkinitSuppPubInfo structure contains mutually-known public The PkinitSuppPubInfo structure contains mutually known public
information specific to the authentication exchange. The enctype information specific to the authentication exchange. The enctype
field is the enctype of the AS reply key as selected according to field is the enctype of the AS reply key as selected according to
[RFC4120]. The as-REQ field contains the DER encoding of the type [RFC4120]. The as-REQ field contains the DER encoding of the AS-REQ
AS-REQ [RFC4120] in the request sent from the client to the KDC. type [RFC4120] in the request sent from the client to the KDC. Note
Note that the as-REQ field does not include the wrapping 4 octet that the as-REQ field does not include the wrapping 4-octet length
length field when TCP is used. The pk-as-rep field contains the DER when TCP is used. The pk-as-rep field contains the DER encoding of
encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The the PA-PK-AS-REP [RFC4556] type in the KDC reply. The
PkinitSuppPubInfo provides a cryptographic bindings between the pre- PkinitSuppPubInfo provides a cryptographic binding between the pre-
authentication data and the corresponding ticket request and authentication data and the corresponding ticket request and
response, thus addressing the concerns described in Section 3. response, thus addressing the concerns described in Section 3.
The KDF is negotiated between the client and the KDC. The client The KDF is negotiated between the client and the KDC. The client
sends an unordered set of supported KDFs in the request, and the KDC sends an unordered set of supported KDFs in the request, and the KDC
picks one from the set in the reply. picks one from the set in the reply.
To accomplish this, the AuthPack structure in [RFC4556] is extended To accomplish this, the AuthPack structure in [RFC4556] is extended
as follows: as follows:
skipping to change at page 10, line 24 skipping to change at page 10, line 27
-- client. -- client.
... ...
} }
KDFAlgorithmId ::= SEQUENCE { KDFAlgorithmId ::= SEQUENCE {
kdf-id [0] OBJECT IDENTIFIER, kdf-id [0] OBJECT IDENTIFIER,
-- The object identifier of the KDF -- The object identifier of the KDF
... ...
} }
The new field supportedKDFs contains an unordered set of KDFs The new supportedKDFs field contains an unordered set of KDFs
supported by the client. supported by the client.
The KDFAlgorithmId structure contains an object identifier that The KDFAlgorithmId structure contains an object identifier that
identifies a KDF. The algorithm of the KDF and its parameters are identifies a KDF. The algorithm of the KDF and its parameters are
defined by the corresponding specification of that KDF. defined by the corresponding specification of that KDF.
The DHRepInfo structure in [RFC4556] is extended as follows: The DHRepInfo structure in [RFC4556] is extended as follows:
DHRepInfo ::= SEQUENCE { DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING, dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL, serverDHNonce [1] DHNonce OPTIONAL,
..., ...,
kdf [2] KDFAlgorithmId OPTIONAL, kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC. -- The KDF picked by the KDC.
... ...
} }
The new field kdf in the extended DHRepInfo structure identifies the The new kdf field in the extended DHRepInfo structure identifies the
KDF picked by the KDC. If the supportedKDFs field is present in the KDF picked by the KDC. If the supportedKDFs field is present in the
request, a KDC conforming to this specification MUST choose one of request, a KDC conforming to this specification MUST choose one of
the KDFs supported by the client and indicate its selection in the the KDFs supported by the client and indicate its selection in the
kdf field in the reply. If the supportedKDFs field is absent in the kdf field in the reply. If the supportedKDFs field is absent in the
request, the KDC MUST omit the kdf field in the reply and use the key request, the KDC MUST omit the kdf field in the reply and use the key
derivation function from Section 3.2.3.1 of [RFC4556]. If none of derivation function from Section 3.2.3.1 of [RFC4556]. If none of
the KDFs supported by the client is acceptable to the KDC, the KDC the KDFs supported by the client is acceptable to the KDC, the KDC
MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF: MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF:
o KDC_ERR_NO_ACCEPTABLE_KDF 100 o KDC_ERR_NO_ACCEPTABLE_KDF 100
If the client fills the supportedKDFs field in the request, but the If the client fills the supportedKDFs field in the request but the
kdf field in the reply is not present, the client can deduce that the kdf field in the reply is not present, the client can deduce that the
KDC is not updated to conform with this specification, or that the KDC is not updated to conform with this specification, or that the
exchange was subjected to a downgrade attack. It is a matter of exchange was subjected to a downgrade attack. It is a matter of
local policy on the client whether to reject the reply when the kdf local policy on the client whether to reject the reply when the kdf
field is absent in the reply; if compatibility with non-updated KDCs field is absent in the reply; if compatibility with non-updated KDCs
is not a concern, the reply should be rejected. is not a concern, the reply should be rejected.
Implementations conforming to this specification MUST support id- Implementations conforming to this specification MUST support
pkinit-kdf-ah-sha256. id-pkinit-kdf-ah-sha256.
7. Interoperability 7. Interoperability
An old client interoperating with a new KDC will not recognize a TD- An old client interoperating with a new KDC will not recognize a
CMS-DIGEST-ALGORITHMS-DATA element in a TD-CMS-DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT- KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-
DIGEST-ALGORITHMS-DATA element in a ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. Because the error data is error. Because the error data is encoded as typed data, the client
encoded as typed data, the client will ignore the unrecognized will ignore the unrecognized elements.
elements.
An old KDC interoperating with a new client will not include a TD- An old KDC interoperating with a new client will not include a
CMS-DIGEST-ALGORITHMS-DATA element in a TD-CMS-DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT- KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-
DIGEST-ALGORITHMS-DATA element in a ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. To the client this error. To the client, this appears just as if a new KDC elected not
appears just as if a new KDC elected not to include a list of digest to include a list of digest algorithms.
algorithms.
An old client interoperating with a new KDC will not include the An old client interoperating with a new KDC will not include the
supportedKDFs field in the request. The KDC MUST omit the kdf field supportedKDFs field in the request. The KDC MUST omit the kdf field
in the reply and use the [RFC4556] KDF as expected by the client, or in the reply and use the [RFC4556] KDF as expected by the client or
reject the request if local policy forbids use of the old KDF. reject the request if local policy forbids use of the old KDF.
A new client interoperating with an old KDC will include the A new client interoperating with an old KDC will include the
supportedKDFs field in the request; this field will be ignored as an supportedKDFs field in the request; this field will be ignored as an
unknown extension by the KDC. The KDC will omit the kdf field in the unknown extension by the KDC. The KDC will omit the kdf field in the
reply and will use the [RFC4556] KDF. The client can deduce from the reply and will use the [RFC4556] KDF. The client can deduce from the
omitted kdf field that the KDC is not updated to conform to this omitted kdf field that the KDC is not updated to conform to this
specification, or that the exchange was subjected to a downgrade specification or that the exchange was subjected to a downgrade
attack. The client MUST use the [RFC4556] KDF, or reject the reply attack. The client MUST use the [RFC4556] KDF or reject the reply if
if local policy forbids the use of the old KDF. local policy forbids the use of the old KDF.
8. Test vectors 8. Test Vectors
This section contains test vectors for the KDF defined above. This section contains test vectors for the KDF defined above.
8.1. Common Inputs 8.1. Common Inputs
Z: Length = 256 bytes, Hex Representation = (All Zeros) Z: Length = 256 bytes, Hex Representation = (All Zeros)
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
skipping to change at page 13, line 4 skipping to change at page 12, line 46
8.2.1. Specific Inputs 8.2.1. Specific Inputs
algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex
Representation = 2B060105 02030601 Representation = 2B060105 02030601
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
Representation = 18 Representation = 18
8.2.2. Outputs 8.2.2. Outputs
key-material: Length = 32 bytes, Hex Representation = key-material: Length = 32 bytes, Hex Representation =
E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
key: Length = 32 bytes, Hex Representation = key: Length = 32 bytes, Hex Representation =
E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
8.3. Test Vector for SHA-256, enctype 8.3. Test Vector for SHA-256, enctype 18
8.3.1. Specific Inputs 8.3.1. Specific Inputs
algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex
Representation = 2B060105 02030602 Representation = 2B060105 02030602
enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
Representation = 18 Representation = 18
8.3.2. Outputs 8.3.2. Outputs
key-material: Length = 32 bytes, Hex Representation = key-material: Length = 32 bytes, Hex Representation =
77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
key: Length = 32 bytes, Hex Representation = key: Length = 32 bytes, Hex Representation =
77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
8.4. Test Vector for SHA-512, enctype 8.4. Test Vector for SHA-512, enctype 16
8.4.1. Specific Inputs 8.4.1. Specific Inputs
algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex
Representation = 2B060105 02030603 Representation = 2B060105 02030603
enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal
Representation = 16
8.4.2. Outputs 8.4.2. Outputs
key-material: Length = 24 bytes, Hex Representation = key-material: Length = 24 bytes, Hex Representation =
D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
key: Length = 32 bytes, Hex Representation = key: Length = 32 bytes, Hex Representation =
D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
9. Security Considerations 9. Security Considerations
This document describes negotiation of checksum types, key derivation This document describes negotiation of checksum types, key derivation
functions and other cryptographic functions. If a given negotiation functions, and other cryptographic functions. If a given negotiation
is unauthenticated, care must be taken to accept only secure values; is unauthenticated, care must be taken to accept only secure values;
to do otherwise allows an active attacker to perform a downgrade to do otherwise allows an active attacker to perform a downgrade
attack. attack.
The discovery method described in Section 4 uses a Kerberos error The discovery method described in Section 4 uses a Kerberos error
message, which is unauthenticated in a typical exchange. An attacker message, which is unauthenticated in a typical exchange. An attacker
may attempt to downgrade a client to a weaker CMS type by forging a may attempt to downgrade a client to a weaker CMS type by forging a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of
local policy whether a client accepts a downgrade to a weaker CMS local policy whether a client accepts a downgrade to a weaker CMS
type, and whether the KDC accepts the weaker CMS type. A client may type and whether the KDC accepts the weaker CMS type. A client may
reasonably assume that the real KDC implements all hash functions reasonably assume that the real KDC implements all hash functions
used in the client's X.509 certificate, and refuse attempts to used in the client's X.509 certificate, and so the client may refuse
downgrade to weaker hash functions. attempts to downgrade to weaker hash functions.
The discovery method described in Section 5 also uses a Kerberos The discovery method described in Section 5 also uses a Kerberos
error message. An attacker may attempt to downgrade a client to a error message. An attacker may attempt to downgrade a client to a
certificate using a weaker signing algorithm by forging a certificate using a weaker signing algorithm by forging a
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local
policy whether a client accepts a downgrade to a weaker certificate, policy whether a client accepts a downgrade to a weaker certificate
and whether the KDC accepts the weaker certificate. This attack is and whether the KDC accepts the weaker certificate. This attack is
only possible if the client device possesses multiple client only possible if the client device possesses multiple client
certificates of varying strength. certificates of varying strengths.
In the KDF negotiation method described in Section 6, the client In the KDF negotiation method described in Section 6, the client
supportedKDFs value is protected by the signature on the supportedKDFs value is protected by the signature on the
signedAuthPack field in the request. If this signature algorithm is signedAuthPack field in the request. If this signature algorithm is
weak to collision attacks, an attacker may attempt to downgrade the vulnerable to collision attacks, an attacker may attempt to downgrade
negotiation by substituting an AuthPack with a different or absent the negotiation by substituting an AuthPack with a different or
supportedKDFs value, using a PKINIT freshness token [RFC8070] to absent supportedKDFs value, using a PKINIT freshness token [RFC8070]
partially control the legitimate AuthPack value. A client performing to partially control the legitimate AuthPack value. A client that is
anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker performing anonymous PKINIT [RFC8062] does not sign the AuthPack, so
can easily remove the supportedKDFs value in this case. Finally, the an attacker can easily remove the supportedKDFs value in this case.
kdf field in the DHRepInfo of the KDC response is unauthenticated, so Finally, the kdf field in the DHRepInfo of the KDC response is
could be altered or removed by an attacker, although this alteration unauthenticated and could be altered or removed by an attacker,
will likely result in a decryption failure by the client rather than although this alteration will likely result in a decryption failure
a successful downgrade. It is a matter of local policy whether a by the client rather than a successful downgrade. It is a matter of
client accepts a downgrade to the old KDF, and whether the KDC allows local policy whether a client accepts a downgrade to the old KDF and
the use of the old KDF. whether the KDC allows the use of the old KDF.
The paChecksum field, which binds the client pre-authentication data The paChecksum field, which binds the client pre-authentication data
to the Kerberos request body, remains fixed at SHA-1. If an attacker to the Kerberos request body, remains fixed at SHA-1. If an attacker
substitutes a different request body using an attack against SHA-1 (a substitutes a different request body using an attack against SHA-1 (a
second preimage attack is likely required as the attacker does not second preimage attack is likely required as the attacker does not
control any part of the legitimate request body), the KDC will not control any part of the legitimate request body), the KDC will not
detect the substitution. Instead, if a new KDF is negotiated, the detect the substitution. Instead, if a new KDF is negotiated, the
client will detect the substitution by failing to decrypt the reply. client will detect the substitution by failing to decrypt the reply.
An attacker may attempt to impersonate the KDC to the client via an An attacker may attempt to impersonate the KDC to the client via an
attack on the hash function used in the dhSignedData signature, attack on the hash function used in the dhSignedData signature,
substituting the attacker's subjectPublicKey for the legitimate one substituting the attacker's subjectPublicKey for the legitimate one
without changing the hash value. It is a matter of local policy without changing the hash value. It is a matter of local policy
which hash function the KDC uses in its signature and which hash which hash function the KDC uses in its signature and which hash
functions the client will accept in the KDC signature. A KDC may functions the client will accept in the KDC signature. A KDC may
reasonably assume that the client implements all hash functions used reasonably assume that the client implements all hash functions used
in the KDF algorithms listed the supportedKDFs field of the request. in the KDF algorithms listed the supportedKDFs field of the request.
10. Acknowledgements 10. IANA Considerations
Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk,
Scott Bradner, and Eric Rescorla reviewed the document and provided
suggestions for improvements.
11. IANA Considerations
IANA is requested to update the following registrations in the IANA has made the following assignments in the Kerberos "Pre-
Kerberos Pre-authentication and Typed Data Registry created by authentication and Typed Data" registry created by Section 7.1 of RFC
section 7.1 of RFC 6113 to refer to this specification. These values 6113.
were reserved for this specification in the initial registrations.
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] TD-CMS-DIGEST-ALGORITHMS 111 [RFC8636]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] TD-CERT-DIGEST-ALGORITHMS 112 [RFC8636]
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
2005, <https://www.rfc-editor.org/info/rfc3961>. 2005, <https://www.rfc-editor.org/info/rfc3961>.
skipping to change at page 16, line 29 skipping to change at page 16, line 9
[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, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SP80056A] [SP80056A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment
Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST
Schemes Using Discrete Logarithm Cryptography", April Special Publications 800-56A, Revision 3,
2018. DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>.
[SP80056C] [SP80056C] Barker, E., Chen, L., and R. Davis, "Recommendation for
Barker, E., Chen, L., and R. Davis, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", NIST
Key-Derivation Methods in Key-Establishment Schemes", Special Publications 800-56C, Revision 1,
April 2018. DOI 10.6028/NIST.SP.800-56Cr1, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Cr1.pdf>.
[X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC [X680] ITU-T, "Information technology - Abstract Syntax Notation
8824-1:2002, Information technology - Abstract Syntax One (ASN.1): Specification of basic notation", ITU-T
Notation One (ASN.1): Specification of basic notation", Recommendation X.680, August 2015,
November 2008. <https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
8825-1:2002, Information technology - ASN.1 encoding Specification of Basic Encoding Rules (BER), Canonical
Rules: Specification of Basic Encoding Rules (BER), Encoding Rules (CER) and Distinguished Encoding Rules
Canonical Encoding Rules (CER) and Distinguished Encoding (DER)", ITU-T Recommendation X.690, August 2015,
Rules (DER)", November 2008. <https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
12.2. Informative References 11.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",
RFC 6150, DOI 10.17487/RFC6150, March 2011, RFC 6150, DOI 10.17487/RFC6150, March 2011,
<https://www.rfc-editor.org/info/rfc6150>. <https://www.rfc-editor.org/info/rfc6150>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
skipping to change at page 17, line 36 skipping to change at page 17, line 21
"Anonymity Support for Kerberos", RFC 8062, "Anonymity Support for Kerberos", RFC 8062,
DOI 10.17487/RFC8062, February 2017, DOI 10.17487/RFC8062, February 2017,
<https://www.rfc-editor.org/info/rfc8062>. <https://www.rfc-editor.org/info/rfc8062>.
[RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key [RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key
Cryptography for Initial Authentication in Kerberos Cryptography for Initial Authentication in Kerberos
(PKINIT) Freshness Extension", RFC 8070, (PKINIT) Freshness Extension", RFC 8070,
DOI 10.17487/RFC8070, February 2017, DOI 10.17487/RFC8070, February 2017,
<https://www.rfc-editor.org/info/rfc8070>. <https://www.rfc-editor.org/info/rfc8070>.
[WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, [WANG04] Wang, X., Lai, X., Feng, D., Chen, H., and X. Yu,
"Cryptanalysis of Hash functions MD4 and RIPEMD", August "Cryptanalysis of the Hash Functions MD4 and RIPEMD",
2004. Advances in Cryptology - EUROCRYPT 2005,
DOI 10.1007/11426639_1, August 2004.
Appendix A. PKINIT ASN.1 Module Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-Agility-SPEC { KerberosV5-PK-INIT-Agility-SPEC {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
AlgorithmIdentifier, SubjectPublicKeyInfo AlgorithmIdentifier, SubjectPublicKeyInfo
skipping to change at page 18, line 43 skipping to change at page 19, line 10
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
::= { id-pkinit-kdf sha384(4) } ::= { id-pkinit-kdf sha384(4) }
-- SP800-56A ASN.1 structured hash-based KDF using SHA-384 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in -- acceptable to the KDC for signing CMS data in
-- the order of decreasing preference. -- decreasing order of preference.
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's -- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC -- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509 -- in the process of validating the client's X.509
-- certificate, in the order of decreasing -- certificate in decreasing order of
-- preference. -- preference.
rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-- This identifies the digest algorithm that was -- This identifies the digest algorithm that was
-- used to sign the client's X.509 certificate and -- used to sign the client's X.509 certificate and
-- has been rejected by the KDC in the process of -- has been rejected by the KDC in the process of
-- validating the client's X.509 certificate -- validating the client's X.509 certificate
-- [RFC5280]. -- [RFC5280].
... ...
} }
skipping to change at page 20, line 17 skipping to change at page 21, line 5
DHRepInfo ::= SEQUENCE { DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING, dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL, serverDHNonce [1] DHNonce OPTIONAL,
..., ...,
kdf [2] KDFAlgorithmId OPTIONAL, kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC. -- The KDF picked by the KDC.
... ...
} }
END END
Acknowledgements
Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk,
Scott Bradner, and Eric Rescorla reviewed the document and provided
suggestions for improvements.
Authors' Addresses Authors' Addresses
Love Hornquist Astrand Love Hornquist Astrand
Apple, Inc Apple, Inc
Cupertino, CA Cupertino, CA
USA United States of America
Email: lha@apple.com Email: lha@apple.com
Larry Zhu Larry Zhu
Oracle Corporation Oracle Corporation
500 Oracle Parkway 500 Oracle Parkway
Redwood Shores, CA 94065 Redwood Shores, CA 94065
USA United States of America
Email: larryzhu@live.com Email: larryzhu@live.com
Margaret Wasserman Margaret Cullen
Painless Security Painless Security
356 Abbott Street 4 High St, Suite 134
North Andover, MA 01845 North Andover, MA 01845
USA United States of America
Phone: +1 781 405-7464 Phone: +1 781-405-7464
Email: mrw@painless-security.com Email: margaret@painless-security.com
URI: http://www.painless-security.com
Greg Hudson Greg Hudson
MIT MIT
Email: ghudson@mit.edu Email: ghudson@mit.edu
 End of changes. 82 change blocks. 
195 lines changed or deleted 198 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/