doc: Add RFC documents

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]
+