RFC 8636

Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility

📅 published July 2019, from ietf

RFC 8636 🦋 PKINIT Algorithm Agility

Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility 💖

okay so this one is from the IETF, and it's a Standards Track doc, published July 2019 📅. It has four authors: L. Hornquist Astrand (Apple, Inc), L. Zhu (Oracle Corporation), M. Cullen (Painless Security), and G. Hudson (MIT) 🫶. It's the ISSN 2070-1721 one, and it updates RFC 4556 ✨. The title block doesn't list anything it obsoletes, so nothing gets retired here 🌸.

Abstract

okay so this doc updates the PKINIT standard (that's RFC 4556) to yank out protocol structures that are tied to specific cryptographic algorithms 🔥. The PKINIT key derivation function becomes negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates become discoverable 💅.

these changes give preemptive protection against vulnerabilities that might be found in the future in any specific cryptographic algorithm 🛡️. they also allow newer algorithms to be rolled out incrementally, which is honestly so iconic 😭✨.

Status of This Memo

this is an Internet Standards Track document 🎀.

it's a product of the Internet Engineering Task Force (IETF) 🌈. it represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. if you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.

info about the current status of this document, any errata, and how to send feedback is over at https://www.rfc-editor.org/info/rfc8636 🔗.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stand on the date of publication 📜. please actually read these, bestie, because they explain your rights and restrictions for this doc 🙈.

code components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🍓.

this doc might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. the people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬. so without an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.

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 ✨

okay so the PKINIT standard [RFC4556] defines a bunch of protocol structures that are either tied to SHA-1 [RFC6234] or don't support negotiation or discovery, and instead rely on local policy 🙃. the problem list looks like this:

  • the checksum algorithm in the authentication request is hardwired to use SHA-1 😤.
  • the acceptable digest algorithms for signing the authentication data aren't discoverable 🔍.
  • the key derivation function in Section 3.2.3.1 of [RFC4556] is hardwired to use SHA-1 🔒.
  • the acceptable digest algorithms for signing the client X.509 certificates aren't discoverable either 🙈.

so in August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] collisions [WANG04], plus attacks on later hash functions including MD5 [RFC1321] and SHA-1 [RFC6234] 💀. these attacks and what they cost us are discussed in [RFC6194] 📚. the discoveries put the security of protocols that rely on the collision-resistance properties of these hashes on the line 😭.

the Internet Engineering Task Force (IETF) called for action to update existing protocols with crypto algorithm agility 💜. that means protocols should support multiple cryptographic algorithms (including hash functions) and come with clean, tested transition strategies between algorithms, as recommended by BCP 201 [RFC7696] 🦋.

to deal with this, new key derivation functions (KDFs) get defined, identified by object identifiers 🧚. the PKINIT client sends a list of KDFs in the request, and the Key Distribution Center (KDC) picks one in the response. so a KDF that both sides support gets negotiated 🤝.

on top of that, structures are defined so the client can discover the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms that the KDC supports 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 doc are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅. so the capitals are doing the heavy lifting, bestie, don't ignore them 🫶.

3. paChecksum Agility 🔐

the paChecksum defined in Section 3.2.1 of [RFC4556] gives a cryptographic binding between the client's pre-authentication data and the matching Kerberos request body 💖. it also stops the KDC-REQ body from being tampered with 🛡️. SHA-1 is the only allowed checksum algorithm defined in [RFC4556] 😬. and this facility relies on the collision-resistance properties of the SHA-1 checksum [RFC6234], which, ngl, is the exact weak spot we just talked about 💀.

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 gives integrity protection for the unauthenticated clear text in those messages. it also covers the binding between the pre-authentication and the ticket request and response messages 🧁.

but if the reply key delivery mechanism is based on Diffie-Hellman key agreement, as described in Section 3.2.3.1 of [RFC4556], then using SHA-1 in the paChecksum is weak 😭. nothing else cryptographically binds the Authentication Service (AS) request to the ticket response either 🙅. in that case, the new KDF the KDC selects (see Section 6) is what provides the cryptographic binding and integrity protection 👑✨.

4. CMS Digest Algorithm Agility 🦋

Section 3.2.2 of [RFC4556] gets updated to add optional typed data to the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error 🎀. when a KDC implementation that follows this spec returns this error code, it MAY include a list of supported CMS types. that list signals the digest algorithms the KDC supports, in decreasing order of preference 💅. this is done by including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data 🌸.

the typed data number is defined like this:

td-cms-digest-algorithms INTEGER ::= 111

the data for TD_CMS_DATA_DIGEST_ALGORITHMS holds the TD-CMS-DIGEST-ALGORITHMS-DATA structure 🧚. it's encoded with ASN.1 Distinguished Encoding Rules (DER) [X680] [X690], and it's 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 the KDC supports 🔍. the info the KDC sends through TD_CMS_DATA_DIGEST_ALGORITHMS can make troubleshooting way easier 🙌. that's especially true when none of the digest algorithms the client supports is supported by the KDC 😭✨.

to be continued in part 2 🌈

5. X.509 Certificate Signer Algorithm Agility ✨

Okay bestie, so Section 3.2.2 of [RFC4556] got a glow-up 🎀 It now has optional typed data tucked into the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC that follows this spec sends that error, it MAY send a list of digest algorithms the KDC is cool with the CA using to sign the client's X.509 certificate, ordered from most to least preferred 💅 The KDC does this by including a TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The data inside is the ASN.1 DER encoding of the TD-CERT-DIGEST-ALGORITHMS-DATA structure, and it looks like this:

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].
        ...
}

So the KDC fills in allowedAlgorithm with the list of [RFC5652] algorithm identifiers for the digest algorithms that the CA uses to sign the client's X.509 certificate and that the KDC accepts while validating that certificate, again in decreasing order of preference 🦋 The rejectedAlgorithm field tells the client which signing algorithm (for signing the client's X.509 certificate) the KDC rejected while validating the certificate [RFC5280]. Main character energy for the KDC, honestly 👑

6. KDF Agility 🌈

Okay so Section 3.2.3.1 of [RFC4556] is updated to define extra key derivation functions (KDFs) that turn the secret from the Diffie-Hellman key exchange into a Kerberos protocol key 🔑 Section 3.2.1 of [RFC4556] also gets a new field in the AuthPack structure, which says which new KDFs the client supports. And Section 3.2.3 of [RFC4556] gets a new field in the DHRepInfo structure, which says which KDF the KDC picked ✨

The KDF algorithm described in this document (based on [SP80056A]) can be implemented using any cryptographic hash function 🧚

A new KDF for PKINIT usage gets identified by an object identifier. These are the KDF object identifiers that get 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]. Every KDF above uses the one-step key derivation method from Section 5.8.2.1 of [SP80056A], with the ASN.1 format for FixedInfo, and it uses Section 4.1 of [SP80056C], picking option 1 for the auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as its 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, here's an abbreviated version of the key derivation method:

  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)
  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 work like this:

  • 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.
  • max_H_inputBits is 2^64.
  • The secret value (Z) is the shared secret value generated by the Diffie-Hellman exchange. The Diffie-Hellman shared value gets padded with leading zeros so that its size in octets matches the modulus, then it's represented as a string of octets in big-endian order.
  • 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 gets selected according to [RFC4120].
  • 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.
  • 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.
  • 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.
  • The supplemental public information (suppPubInfo) is the ASN.1 DER encoding of the PkinitSuppPubInfo structure, which is defined later in this section.
  • The supplemental private information (suppPrivInfo) is absent.

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 holds 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] from the request the client sends 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. Put together, the PkinitSuppPubInfo gives a cryptographic binding between the pre-authentication data and the matching ticket request and response, which addresses the concerns described in Section 3 🔐

The KDF gets 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 that set in the reply 🎀

To make that happen, the AuthPack structure in [RFC4556] gets extended like this:

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 that the client supports 💖 The KDFAlgorithmId structure holds an object identifier that identifies a KDF. The algorithm of the KDF and its parameters are defined by that KDF's own specification ✨

The DHRepInfo structure in [RFC4556] gets extended like this:

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 the KDC picked. If the supportedKDFs field is present in the request, a KDC conforming to this specification MUST choose one of the KDFs the client supports 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 derivation function from Section 3.2.3.1 of [RFC4556]. If none of the KDFs the client supports is acceptable to the KDC, the KDC MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF:

  • KDC_ERR_NO_ACCEPTABLE_KDF 100

If the client fills in the supportedKDFs field in the request but the kdf field is not present in the reply, 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. No cap, that one's non-negotiable 💅🌸

7. Interoperability 🤝

okay so bestie, this is the part where old and new versions meet and we find out if they can still vibe 🥹

An old client talking to a new KDC won't 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. But the error data is encoded as typed data, so the client just ignores the stuff it doesn't recognize. no drama 💅

An old KDC talking to a new client won't 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 looks exactly like a new KDC choosing not to include a list of digest algorithms 🙈

An old client talking to a new KDC won't include the supportedKDFs field in the request. So the KDC MUST omit the kdf field in the reply and use the [RFC4556] KDF as the client expects, or reject the request if local policy forbids use of the old KDF. the KDC has to pick one of those two paths 🌈

A new client talking to an old KDC will include the supportedKDFs field in the request. The old KDC will ignore it as an unknown extension ✨ 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.

8. Test Vectors 🧪

this section has the test vectors for the KDF we just talked about, so you can check your work bestie 💜

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 BBBBBBBBBB

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

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 🚨

okay bestie, this section is seriously important, so put the phone down for a sec 📱🚫 this doc covers negotiating checksum types, KDFs, and other crypto functions. if a negotiation isn't authenticated, you have to be super careful to accept only secure values, or an active attacker can pull a downgrade attack on you 😱

The discovery method in Section 4 uses a Kerberos error message, which is unauthenticated in a typical exchange. An attacker may try 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 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, so the client may refuse attempts to downgrade to weaker hash functions 🛡️

The discovery method in Section 5 also uses a Kerberos error message. An attacker may try 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 try 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. 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 try 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 in the supportedKDFs field of the request 🔐

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>.

[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

okay so these are the "good to know" sources, bestie 📚✨ they're not required reading, but they're the receipts for everything above 💅

Appendix A. PKINIT ASN.1 Module 🎀

this is the formal ASN.1 module, the exact typed blueprint for all the new structures, so it has to be copied exactly 🤓 no touching, no "fixing" the spacing 😭

   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

   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.
          ...
   }
   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

Acknowledgements 🫶

huge thanks to the squad who reviewed the document and dropped suggestions for making it better 💖

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 🦋

and here are the people who wrote it, with where to find them 🧚✨

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

📦 where this page comes from