summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8636.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8636.txt')
-rw-r--r--doc/rfc/rfc8636.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8636.txt b/doc/rfc/rfc8636.txt
new file mode 100644
index 0000000..5227ca0
--- /dev/null
+++ b/doc/rfc/rfc8636.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Hornquist Astrand
+Request for Comments: 8636 Apple, Inc
+Updates: 4556 L. Zhu
+Category: Standards Track Oracle Corporation
+ISSN: 2070-1721 M. Cullen
+ Painless Security
+ G. Hudson
+ MIT
+ July 2019
+
+
+Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
+ Algorithm Agility
+
+Abstract
+
+ This document updates the Public Key Cryptography for Initial
+ Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove
+ protocol structures tied to specific cryptographic algorithms. The
+ PKINIT key derivation function is made negotiable, and the digest
+ algorithms for signing the pre-authentication data and the client's
+ X.509 certificates are made discoverable.
+
+ These changes provide preemptive protection against vulnerabilities
+ discovered in the future in any specific cryptographic algorithm and
+ allow incremental deployment of newer algorithms.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 1]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 2]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
+ 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
+ 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 5
+ 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
+ 6. KDF Agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
+ 8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
+ 8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.3. Test Vector for SHA-256, enctype 18 . . . . . . . . . . . 13
+ 8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
+ 8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
+ 8.4. Test Vector for SHA-512, enctype 16 . . . . . . . . . . . 13
+ 8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
+ 8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 16
+ Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 18
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
+
+1. Introduction
+
+ The Public Key Cryptography for Initial Authentication in Kerberos
+ (PKINIT) standard [RFC4556] defines several protocol structures that
+ are either tied to SHA-1 [RFC6234] or do not support negotiation or
+ discovery but are instead based on local policy:
+
+ o The checksum algorithm in the authentication request is hardwired
+ to use SHA-1.
+
+ o The acceptable digest algorithms for signing the authentication
+ data are not discoverable.
+
+ o The key derivation function in Section 3.2.3.1 of [RFC4556] is
+ hardwired to use SHA-1.
+
+ o The acceptable digest algorithms for signing the client X.509
+ certificates are not discoverable.
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 3]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150]
+ collisions [WANG04], alongside attacks on later hash functions
+ including MD5 [RFC1321] and SHA-1 [RFC6234]. These attacks and their
+ consequences are discussed in [RFC6194]. These discoveries
+ challenged the security of protocols relying on the collision-
+ resistance properties of these hashes.
+
+ The Internet Engineering Task Force (IETF) called for action to
+ update existing protocols to provide crypto algorithm agility so that
+ protocols support multiple cryptographic algorithms (including hash
+ functions) and provide clean, tested transition strategies between
+ algorithms, as recommended by BCP 201 [RFC7696].
+
+ To address these concerns, new key derivation functions (KDFs),
+ identified by object identifiers, are defined. The PKINIT client
+ provides a list of KDFs in the request, and the Key Distribution
+ Center (KDC) picks one in the response. Thus, a mutually supported
+ KDF is negotiated.
+
+ Furthermore, structures are defined to allow the client to discover
+ the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms
+ supported by the KDC for signing the pre-authentication data and the
+ client X.509 certificate.
+
+2. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. paChecksum Agility
+
+ The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
+ cryptographic binding between the client's pre-authentication data
+ and the corresponding Kerberos request body. This also prevents the
+ KDC-REQ body from being tampered with. SHA-1 is the only allowed
+ checksum algorithm defined in [RFC4556]. This facility relies on the
+ collision-resistance properties of the SHA-1 checksum [RFC6234].
+
+ When the reply key delivery mechanism is based on public key
+ encryption as described in Section 3.2.3.2 of [RFC4556], the
+ asChecksum in the KDC reply provides integrity protection for the
+ unauthenticated clear text in these messages and the binding between
+ the pre-authentication and the ticket request and response messages.
+ However, if the reply key delivery mechanism is based on the Diffie-
+ Hellman key agreement as described in Section 3.2.3.1 of [RFC4556],
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 4]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ the security provided by using SHA-1 in the paChecksum is weak, and
+ nothing else cryptographically binds the Authentication Service (AS)
+ request to the ticket response. In this case, the new KDF selected
+ by the KDC, as described in Section 6, provides the cryptographic
+ binding and integrity protection.
+
+4. CMS Digest Algorithm Agility
+
+ 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
+ implementation conforming to this specification returns this error
+ code, it MAY include a list of supported CMS types signifying the
+ digest algorithms supported by the KDC in decreasing order of
+ preference. This is accomplished by including a
+ TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.
+
+ td-cms-digest-algorithms INTEGER ::= 111
+
+ The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
+ the TD-CMS-DIGEST-ALGORITHMS-DATA structure, which is ASN.1
+ Distinguished Encoding Rules (DER) [X680] [X690] encoded and is
+ defined as follows:
+
+ TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
+ AlgorithmIdentifier
+ -- Contains the list of CMS algorithm [RFC5652]
+ -- identifiers indicating the digest algorithms
+ -- acceptable to the KDC for signing CMS data in
+ -- decreasing order of preference.
+
+ The algorithm identifiers in TD-CMS-DIGEST-ALGORITHMS identify the
+ digest algorithms supported by the KDC.
+
+ This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
+ can facilitate troubleshooting when none of the digest algorithms
+ supported by the client is supported by the KDC.
+
+5. X.509 Certificate Signer Algorithm Agility
+
+ 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
+ to this specification returns this error, it MAY send a list of
+ digest algorithms acceptable to the KDC for use by the certification
+ authority (CA) in signing the client's X.509 certificate in
+ decreasing order of preference. This is accomplished by including a
+ TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The
+ corresponding data contains the ASN.1 DER encoding of the TD-CERT-
+ DIGEST-ALGORITHMS-DATA structure defined as follows:
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 5]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ td-cert-digest-algorithms INTEGER ::= 112
+
+ TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
+ allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
+ -- Contains the list of CMS algorithm [RFC5652]
+ -- identifiers indicating the digest algorithms
+ -- that 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
+ -- certificate in decreasing order of
+ -- preference.
+ rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
+ -- This identifies the digest algorithm that was
+ -- used to sign the client's X.509 certificate and
+ -- has been rejected by the KDC in the process of
+ -- validating the client's X.509 certificate
+ -- [RFC5280].
+ ...
+ }
+
+ The KDC fills in the allowedAlgorithm field with the list of
+ algorithm [RFC5652] identifiers indicating digest algorithms that 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
+ certificate in decreasing order of preference. The rejectedAlgorithm
+ field identifies the signing algorithm for use in signing the
+ client's X.509 certificate that has been rejected by the KDC in the
+ process of validating the client's certificate [RFC5280].
+
+6. KDF Agility
+
+ Section 3.2.3.1 of [RFC4556] is updated to define additional key
+ derivation functions (KDFs) to derive a Kerberos protocol key based
+ 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
+ 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
+ the DHRepInfo structure to indicate which KDF is selected by the KDC.
+
+ The KDF algorithm described in this document (based on [SP80056A])
+ can be implemented using any cryptographic hash function.
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 6]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ A new KDF for PKINIT usage is identified by an object identifier.
+ The following KDF object identifiers are defined:
+
+ id-pkinit OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosv5(2) pkinit (3) }
+ -- Defined in RFC 4556 and quoted here for the reader.
+
+ id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
+ -- PKINIT KDFs
+
+ id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha1(1) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-1
+
+ id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha256(2) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-256
+
+ id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha512(3) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-512
+
+ id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha384(4) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-384
+
+ Where id-pkinit is defined in [RFC4556]. All key derivation
+ functions specified above use the one-step key derivation method
+ described in Section 5.8.2.1 of [SP80056A], choosing the ASN.1 format
+ for FixedInfo, and Section 4.1 of [SP80056C], choosing option 1 for
+ the auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234]
+ as the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-
+ sha356, and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384
+ [RFC6234], and SHA-512 [RFC6234], respectively.
+
+ To name the input parameters, an abbreviated version of the key
+ derivation method is described below.
+
+ 1. reps = ceiling(L/H_outputBits)
+
+ 2. Initialize a 32-bit, big-endian bit string counter as 1.
+
+ 3. For i = 1 to reps by 1, do the following:
+
+ 1. Compute Hashi = H(counter || Z || OtherInfo).
+
+ 2. Increment counter (not to exceed 2^32-1)
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 7]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ 4. Set key_material = Hash1 || Hash2 || ... so that the length of
+ 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
+ keying material. The AS reply key is the output of random-to-
+ key() [RFC3961], using that keying material as the input.
+
+ 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
+ id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and
+ 512 bits for id-pkinit-kdf-ah-sha512.
+
+ o max_H_inputBits is 2^64.
+
+ o The secret value (Z) is the shared secret value generated by the
+ Diffie-Hellman exchange. The Diffie-Hellman shared value is first
+ padded with leading zeros such that the size of the secret value
+ in octets is the same as that of the modulus, then represented as
+ a string of octets in big-endian order.
+
+ o The key data length (L) is the key-generation seed length in bits
+ [RFC3961] for the Authentication Service (AS) reply key. The
+ enctype of the AS reply key is selected according to [RFC4120].
+
+ o The algorithm identifier (algorithmID) input parameter is the
+ identifier of the respective KDF. For example, this is id-pkinit-
+ kdf-ah-sha1 if the KDF uses SHA-1 as the hash.
+
+ o The initiator identifier (partyUInfo) contains the ASN.1 DER
+ encoding of the KRB5PrincipalName [RFC4556] that identifies the
+ client as specified in the AS-REQ [RFC4120] in the request.
+
+ o The recipient identifier (partyVInfo) contains the ASN.1 DER
+ encoding of the KRB5PrincipalName [RFC4556] that identifies the
+ 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
+ encoding of the PkinitSuppPubInfo structure, as defined later in
+ this section.
+
+ o The supplemental private information (suppPrivInfo) is absent.
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 8]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ OtherInfo is the ASN.1 DER encoding of the following sequence:
+
+ OtherInfo ::= SEQUENCE {
+ algorithmID AlgorithmIdentifier,
+ partyUInfo [0] OCTET STRING,
+ partyVInfo [1] OCTET STRING,
+ suppPubInfo [2] OCTET STRING OPTIONAL,
+ suppPrivInfo [3] OCTET STRING OPTIONAL
+ }
+
+ The PkinitSuppPubInfo structure is defined as follows:
+
+ PkinitSuppPubInfo ::= SEQUENCE {
+ enctype [0] Int32,
+ -- The enctype of the AS reply key.
+ as-REQ [1] OCTET STRING,
+ -- The DER encoding of the AS-REQ [RFC4120] from the
+ -- client.
+ pk-as-rep [2] OCTET STRING,
+ -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
+ -- KDC reply.
+ ...
+ }
+
+ The PkinitSuppPubInfo structure contains mutually known public
+ information specific to the authentication exchange. The enctype
+ field is the enctype of the AS reply key as selected according to
+ [RFC4120]. The as-REQ field contains the DER encoding of the AS-REQ
+ type [RFC4120] in the request sent from the client to the KDC. Note
+ that the as-REQ field does not include the wrapping 4-octet length
+ when TCP is used. The pk-as-rep field contains the DER encoding of
+ the PA-PK-AS-REP [RFC4556] type in the KDC reply. The
+ PkinitSuppPubInfo provides a cryptographic binding between the pre-
+ authentication data and the corresponding ticket request and
+ response, thus addressing the concerns described in Section 3.
+
+ 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
+ picks one from the set in the reply.
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 9]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ To accomplish this, the AuthPack structure in [RFC4556] is extended
+ as follows:
+
+ AuthPack ::= SEQUENCE {
+ pkAuthenticator [0] PKAuthenticator,
+ clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+ supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+ OPTIONAL,
+ clientDHNonce [3] DHNonce OPTIONAL,
+ ...,
+ supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
+ -- Contains an unordered set of KDFs supported by the
+ -- client.
+ ...
+ }
+
+ KDFAlgorithmId ::= SEQUENCE {
+ kdf-id [0] OBJECT IDENTIFIER,
+ -- The object identifier of the KDF
+ ...
+ }
+
+ The new supportedKDFs field contains an unordered set of KDFs
+ supported by the client.
+
+ The KDFAlgorithmId structure contains an object identifier that
+ identifies a KDF. The algorithm of the KDF and its parameters are
+ defined by the corresponding specification of that KDF.
+
+ The DHRepInfo structure in [RFC4556] is extended as follows:
+
+ DHRepInfo ::= SEQUENCE {
+ dhSignedData [0] IMPLICIT OCTET STRING,
+ serverDHNonce [1] DHNonce OPTIONAL,
+ ...,
+ kdf [2] KDFAlgorithmId OPTIONAL,
+ -- The KDF picked by the KDC.
+ ...
+ }
+
+ The new kdf field in the extended DHRepInfo structure identifies 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
+ 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
+ request, the KDC MUST omit the kdf field in the reply and use the key
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 10]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ 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
+ MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF:
+
+ o KDC_ERR_NO_ACCEPTABLE_KDF 100
+
+ 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
+ KDC is not updated to conform with this specification, or that the
+ 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
+ field is absent in the reply; if compatibility with non-updated KDCs
+ is not a concern, the reply should be rejected.
+
+ Implementations conforming to this specification MUST support
+ id-pkinit-kdf-ah-sha256.
+
+7. Interoperability
+
+ An old client interoperating with a new KDC will not recognize a
+ TD-CMS-DIGEST-ALGORITHMS-DATA element in a
+ KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-
+ ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED
+ error. Because the error data is encoded as typed data, the client
+ will ignore the unrecognized elements.
+
+ An old KDC interoperating with a new client will not include a
+ TD-CMS-DIGEST-ALGORITHMS-DATA element in a
+ KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error or a TD-CERT-DIGEST-
+ ALGORITHMS-DATA element in a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED
+ error. To the client, this appears just as if a new KDC elected not
+ to include a list of digest algorithms.
+
+ An old client interoperating with a new KDC will not include the
+ 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
+ reject the request if local policy forbids use of the old KDF.
+
+ A new client interoperating with an old KDC will include the
+ 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
+ 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
+ specification or that the exchange was subjected to a downgrade
+ attack. The client MUST use the [RFC4556] KDF or reject the reply if
+ local policy forbids the use of the old KDF.
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 11]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+8. Test Vectors
+
+ This section contains test vectors for the KDF defined above.
+
+8.1. Common Inputs
+
+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
+
+client: Length = 9 bytes, ASCII Representation = lha@SU.SE
+
+server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE
+
+as-req: Length = 10 bytes, Hex Representation =
+AAAAAAAA AAAAAAAA AAAA
+
+pk-as-rep: Length = 9 bytes, Hex Representation =
+BBBBBBBB BBBBBBBB BB
+
+ticket: Length = 55 bytes, Hex Representation =
+61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B
+036C6861 A311300F A0030201 12A20804 0668656A 68656A
+
+8.2. Test Vector for SHA-1, enctype 18
+
+8.2.1. Specific Inputs
+
+ algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex
+ Representation = 2B060105 02030601
+
+ enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
+ Representation = 18
+
+8.2.2. Outputs
+
+ key-material: Length = 32 bytes, Hex Representation =
+ E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
+
+ key: Length = 32 bytes, Hex Representation =
+ E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 12]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+8.3. Test Vector for SHA-256, enctype 18
+
+8.3.1. Specific Inputs
+
+ algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex
+ Representation = 2B060105 02030602
+
+ enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
+ Representation = 18
+
+8.3.2. Outputs
+
+ key-material: Length = 32 bytes, Hex Representation =
+ 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
+
+ key: Length = 32 bytes, Hex Representation =
+ 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5
+
+8.4. Test Vector for SHA-512, enctype 16
+
+8.4.1. Specific Inputs
+
+ algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex
+ Representation = 2B060105 02030603
+
+ enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal
+ Representation = 16
+
+8.4.2. Outputs
+
+ key-material: Length = 24 bytes, Hex Representation =
+ D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
+
+ key: Length = 32 bytes, Hex Representation =
+ D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
+
+9. Security Considerations
+
+ This document describes negotiation of checksum types, key derivation
+ functions, and other cryptographic functions. If a given negotiation
+ is unauthenticated, care must be taken to accept only secure values;
+ to do otherwise allows an active attacker to perform a downgrade
+ attack.
+
+ The discovery method described in Section 4 uses a Kerberos error
+ message, which is unauthenticated in a typical exchange. An attacker
+ 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
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 13]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ 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
+ reasonably assume that the real KDC implements all hash functions
+ used in the client's X.509 certificate, and so the client may refuse
+ attempts to downgrade to weaker hash functions.
+
+ The discovery method described in Section 5 also uses a Kerberos
+ error message. An attacker may attempt to downgrade a client to a
+ certificate using a weaker signing algorithm by forging a
+ 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
+ and whether the KDC accepts the weaker certificate. This attack is
+ only possible if the client device possesses multiple client
+ certificates of varying strengths.
+
+ In the KDF negotiation method described in Section 6, the client
+ supportedKDFs value is protected by the signature on the
+ signedAuthPack field in the request. If this signature algorithm is
+ vulnerable to collision attacks, an attacker may attempt to downgrade
+ the negotiation by substituting an AuthPack with a different or
+ absent supportedKDFs value, using a PKINIT freshness token [RFC8070]
+ to partially control the legitimate AuthPack value. A client that is
+ performing anonymous PKINIT [RFC8062] does not sign the AuthPack, so
+ an attacker can easily remove the supportedKDFs value in this case.
+ Finally, the kdf field in the DHRepInfo of the KDC response is
+ unauthenticated and could be altered or removed by an attacker,
+ although this alteration will likely result in a decryption failure
+ by the client rather than a successful downgrade. It is a matter of
+ local policy whether a client accepts a downgrade to the old KDF and
+ whether the KDC allows the use of the old KDF.
+
+ The paChecksum field, which binds the client pre-authentication data
+ 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
+ second preimage attack is likely required as the attacker does not
+ control any part of the legitimate request body), the KDC will not
+ detect the substitution. Instead, if a new KDF is negotiated, the
+ client will detect the substitution by failing to decrypt the reply.
+
+ An attacker may attempt to impersonate the KDC to the client via an
+ attack on the hash function used in the dhSignedData signature,
+ substituting the attacker's subjectPublicKey for the legitimate one
+ without changing the hash value. It is a matter of local policy
+ which hash function the KDC uses in its signature and which hash
+ functions the client will accept in the KDC signature. A KDC may
+ reasonably assume that the client implements all hash functions used
+ in the KDF algorithms listed the supportedKDFs field of the request.
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 14]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+10. IANA Considerations
+
+ IANA has made the following assignments in the Kerberos "Pre-
+ authentication and Typed Data" registry created by Section 7.1 of RFC
+ 6113.
+
+ TD-CMS-DIGEST-ALGORITHMS 111 [RFC8636]
+ TD-CERT-DIGEST-ALGORITHMS 112 [RFC8636]
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
+ Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
+ 2005, <https://www.rfc-editor.org/info/rfc3961>.
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC 4120,
+ DOI 10.17487/RFC4120, July 2005,
+ <https://www.rfc-editor.org/info/rfc4120>.
+
+ [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+ Authentication in Kerberos (PKINIT)", RFC 4556,
+ DOI 10.17487/RFC4556, June 2006,
+ <https://www.rfc-editor.org/info/rfc4556>.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+ RFC 5652, DOI 10.17487/RFC5652, September 2009,
+ <https://www.rfc-editor.org/info/rfc5652>.
+
+ [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and SHA-based HMAC and HKDF)", RFC 6234,
+ DOI 10.17487/RFC6234, May 2011,
+ <https://www.rfc-editor.org/info/rfc6234>.
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 15]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [SP80056A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
+ Davis, "Recommendation for Pair-Wise Key-Establishment
+ Schemes Using Discrete Logarithm Cryptography", NIST
+ Special Publications 800-56A, Revision 3,
+ DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
+ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+ NIST.SP.800-56Ar3.pdf>.
+
+ [SP80056C] Barker, E., Chen, L., and R. Davis, "Recommendation for
+ Key-Derivation Methods in Key-Establishment Schemes", NIST
+ Special Publications 800-56C, Revision 1,
+ DOI 10.6028/NIST.SP.800-56Cr1, April 2018,
+ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+ NIST.SP.800-56Cr1.pdf>.
+
+ [X680] ITU-T, "Information technology - Abstract Syntax Notation
+ One (ASN.1): Specification of basic notation", ITU-T
+ Recommendation X.680, August 2015,
+ <https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
+
+ [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", ITU-T Recommendation X.690, August 2015,
+ <https://www.itu.int/rec/T-REC-X.690-201508-I/en>.
+
+11.2. Informative References
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ DOI 10.17487/RFC1321, April 1992,
+ <https://www.rfc-editor.org/info/rfc1321>.
+
+ [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",
+ RFC 6150, DOI 10.17487/RFC6150, March 2011,
+ <https://www.rfc-editor.org/info/rfc6150>.
+
+ [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
+ Considerations for the SHA-0 and SHA-1 Message-Digest
+ Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
+ <https://www.rfc-editor.org/info/rfc6194>.
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 16]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
+ Agility and Selecting Mandatory-to-Implement Algorithms",
+ BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
+ <https://www.rfc-editor.org/info/rfc7696>.
+
+ [RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
+ "Anonymity Support for Kerberos", RFC 8062,
+ DOI 10.17487/RFC8062, February 2017,
+ <https://www.rfc-editor.org/info/rfc8062>.
+
+ [RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key
+ Cryptography for Initial Authentication in Kerberos
+ (PKINIT) Freshness Extension", RFC 8070,
+ DOI 10.17487/RFC8070, February 2017,
+ <https://www.rfc-editor.org/info/rfc8070>.
+
+ [WANG04] Wang, X., Lai, X., Feng, D., Chen, H., and X. Yu,
+ "Cryptanalysis of the Hash Functions MD4 and RIPEMD",
+ Advances in Cryptology - EUROCRYPT 2005,
+ DOI 10.1007/11426639_1, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 17]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+Appendix A. PKINIT ASN.1 Module
+
+ KerberosV5-PK-INIT-Agility-SPEC {
+ iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
+ } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+ IMPORTS
+ AlgorithmIdentifier, SubjectPublicKeyInfo
+ FROM PKIX1Explicit88 { iso (1)
+ identified-organization (3) dod (6) internet (1)
+ security (5) mechanisms (5) pkix (7) id-mod (0)
+ id-pkix1-explicit (18) }
+ -- As defined in RFC 5280.
+
+ Ticket, Int32, Realm, EncryptionKey, Checksum
+ FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) kerberosV5(2)
+ modules(4) krb5spec2(2) }
+ -- as defined in RFC 4120.
+
+ PKAuthenticator, DHNonce, id-pkinit
+ FROM KerberosV5-PK-INIT-SPEC {
+ iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosV5(2) modules(4) pkinit(5) };
+ -- as defined in RFC 4556.
+
+ id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) }
+ -- PKINIT KDFs
+
+ id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha1(1) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-1
+
+ id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha256(2) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-256
+
+ id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha512(3) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-512
+
+ id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
+ ::= { id-pkinit-kdf sha384(4) }
+ -- SP800-56A ASN.1 structured hash-based KDF using SHA-384
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 18]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
+ AlgorithmIdentifier
+ -- Contains the list of CMS algorithm [RFC5652]
+ -- identifiers indicating the digest algorithms
+ -- acceptable to the KDC for signing CMS data in
+ -- decreasing order of preference.
+
+ TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
+ allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
+ -- Contains the list of CMS algorithm [RFC5652]
+ -- identifiers indicating the digest algorithms
+ -- that 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
+ -- certificate in decreasing order of
+ -- preference.
+ rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
+ -- This identifies the digest algorithm that was
+ -- used to sign the client's X.509 certificate and
+ -- has been rejected by the KDC in the process of
+ -- validating the client's X.509 certificate
+ -- [RFC5280].
+ ...
+ }
+
+ OtherInfo ::= SEQUENCE {
+ algorithmID AlgorithmIdentifier,
+ partyUInfo [0] OCTET STRING,
+ partyVInfo [1] OCTET STRING,
+ suppPubInfo [2] OCTET STRING OPTIONAL,
+ suppPrivInfo [3] OCTET STRING OPTIONAL
+ }
+
+ PkinitSuppPubInfo ::= SEQUENCE {
+ enctype [0] Int32,
+ -- The enctype of the AS reply key.
+ as-REQ [1] OCTET STRING,
+ -- The DER encoding of the AS-REQ [RFC4120] from the
+ -- client.
+ pk-as-rep [2] OCTET STRING,
+ -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the
+ -- KDC reply.
+ ...
+ }
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 19]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+ AuthPack ::= SEQUENCE {
+ pkAuthenticator [0] PKAuthenticator,
+ clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+ supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+ OPTIONAL,
+ clientDHNonce [3] DHNonce OPTIONAL,
+ ...,
+ supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
+ -- Contains an unordered set of KDFs supported by the
+ -- client.
+ ...
+ }
+
+ KDFAlgorithmId ::= SEQUENCE {
+ kdf-id [0] OBJECT IDENTIFIER,
+ -- The object identifier of the KDF
+ ...
+ }
+
+ DHRepInfo ::= SEQUENCE {
+ dhSignedData [0] IMPLICIT OCTET STRING,
+ serverDHNonce [1] DHNonce OPTIONAL,
+ ...,
+ kdf [2] KDFAlgorithmId OPTIONAL,
+ -- The KDF picked by the KDC.
+ ...
+ }
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 20]
+
+RFC 8636 PKINIT Algorithm Agility July 2019
+
+
+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
+
+ Love Hornquist Astrand
+ Apple, Inc
+ Cupertino, CA
+ United States of America
+
+ Email: lha@apple.com
+
+
+ Larry Zhu
+ Oracle Corporation
+ 500 Oracle Parkway
+ Redwood Shores, CA 94065
+ United States of America
+
+ Email: larryzhu@live.com
+
+
+ Margaret Cullen
+ Painless Security
+ 4 High St, Suite 134
+ North Andover, MA 01845
+ United States of America
+
+ Phone: +1 781-405-7464
+ Email: margaret@painless-security.com
+
+
+ Greg Hudson
+ MIT
+
+ Email: ghudson@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand, et al. Standards Track [Page 21]
+