idnits 2.17.1 draft-ietf-kitten-pkinit-alg-agility-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4556]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4556, but the abstract doesn't seem to directly say this. It does mention RFC4556 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4556, updated by this document, for RFC5378 checks: 2006-06-30) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2019) is 1804 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 854 -- Looks like a reference, but probably isn't: '1' on line 855 -- Looks like a reference, but probably isn't: '2' on line 857 -- Looks like a reference, but probably isn't: '3' on line 838 -- Looks like a reference, but probably isn't: '4' on line 840 == Missing Reference: 'ALG-AGILITY' is mentioned on line 641, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP80056A' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP80056C' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kitten Working Group L. Hornquist Astrand 3 Internet-Draft Apple, Inc 4 Updates: 4556 (if approved) L. Zhu 5 Intended status: Standards Track Oracle Corporation 6 Expires: October 22, 2019 M. Wasserman 7 Painless Security 8 G. Hudson 9 MIT 10 April 20, 2019 12 PKINIT Algorithm Agility 13 draft-ietf-kitten-pkinit-alg-agility-08 15 Abstract 17 This document updates the Public Key Cryptography for Initial 18 Authentication in Kerberos standard (PKINIT) [RFC4556], to remove 19 protocol structures tied to specific cryptographic algorithms. The 20 PKINIT key derivation function is made negotiable, and the digest 21 algorithms for signing the pre-authentication data and the client's 22 X.509 certificates are made discoverable. 24 These changes provide preemptive protection against vulnerabilities 25 discovered in the future against any specific cryptographic 26 algorithm, and allow incremental deployment of newer algorithms. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 22, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 76 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4 77 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4 78 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5 79 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 81 8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12 83 8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 84 8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 85 8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13 87 8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 88 8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13 90 8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 91 8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 12.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 The Public Key Cryptography for Initial Authentication in Kerberos 104 (PKINIT) standard [RFC4556] defines several protocol structures that 105 are either tied to SHA-1 [RFC6234], or do not support negotiation or 106 discovery, but are instead based on local policy: 108 o The checksum algorithm in the authentication request is hardwired 109 to use SHA-1. 111 o The acceptable digest algorithms for signing the authentication 112 data are not discoverable. 114 o The key derivation function in Section 3.2.3.1 of [RFC4556] is 115 hardwired to use SHA-1. 117 o The acceptable digest algorithms for signing the client X.509 118 certificates are not discoverable. 120 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] 121 collisions generated using hand calculation [WANG04], alongside 122 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 123 SHA [RFC6234] family. These attacks and their consequences are 124 discussed in [RFC6194]. These discoveries challenged the security of 125 protocols relying on the collision resistance properties of these 126 hashes. 128 The Internet Engineering Task Force (IETF) called for actions to 129 update existing protocols to provide crypto algorithm agility so that 130 protocols support multiple cryptographic algorithms (including hash 131 functions) and provide clean, tested transition strategies between 132 algorithms, as recommended by BCP 201 [RFC7696]. 134 To address these concerns, new key derivation functions (KDFs), 135 identified by object identifiers, are defined. The PKINIT client 136 provides a list of KDFs in the request and the Key Distribution 137 Center (KDC) picks one in the response, thus a mutually-supported KDF 138 is negotiated. 140 Furthermore, structures are defined to allow the client to discover 141 the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms 142 supported by the KDC for signing the pre-authentication data and 143 signing the client X.509 certificate. 145 2. Requirements Notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 3. paChecksum Agility 155 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 156 cryptographic binding between the client's pre-authentication data 157 and the corresponding Kerberos request body. This also prevents the 158 KDC-REQ body from being tampered with. SHA-1 is the only allowed 159 checksum algorithm defined in [RFC4556]. This facility relies on the 160 collision resistance properties of the SHA-1 checksum [RFC6234]. 162 When the reply key delivery mechanism is based on public key 163 encryption as described in Section 3.2.3.2 of [RFC4556], the 164 asChecksum in the KDC reply provides the binding between the pre- 165 authentication and the ticket request and response messages, and 166 integrity protection for the unauthenticated clear text in these 167 messages. However, if the reply key delivery mechanism is based on 168 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 169 [RFC4556], the security provided by using SHA-1 in the paChecksum is 170 weak, and nothing else cryptographically binds the AS request to the 171 ticket response. In this case, the new KDF selected by the KDC as 172 described in Section 6 provides the cryptographic binding and 173 integrity protection. 175 4. CMS Digest Algorithm Agility 177 Section 3.2.2 of [RFC4556] is updated to add optional typed data to 178 the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC 179 implementation conforming to this specification returns this error 180 code, it MAY include in a list of supported CMS types signifying the 181 digest algorithms supported by the KDC, in the decreasing preference 182 order. This is accomplished by including a 183 TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data. 185 td-cms-digest-algorithms INTEGER ::= 111 186 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 187 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 188 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 190 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 191 AlgorithmIdentifier 192 -- Contains the list of CMS algorithm [RFC5652] 193 -- identifiers indicating the digest algorithms 194 -- acceptable to the KDC for signing CMS data in 195 -- the order of decreasing preference. 197 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 198 digest algorithms supported by the KDC. 200 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 201 can facilitate trouble-shooting when none of the digest algorithms 202 supported by the client is supported by the KDC. 204 5. X.509 Certificate Signer Algorithm Agility 206 Section 3.2.2 of [RFC4556] is updated to add optional typed data to 207 the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming 208 to this specification returns this error, it MAY send a list of 209 digest algorithms acceptable to the KDC for use by the Certificate 210 Authority (CA) in signing the client's X.509 certificate, in the 211 decreasing preference order. This is accomplished by including a 212 TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The 213 corresponding data contains the ASN.1 DER encoding of the structure 214 TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: 216 td-cert-digest-algorithms INTEGER ::= 112 218 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 219 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 220 -- Contains the list of CMS algorithm [RFC5652] 221 -- identifiers indicating the digest algorithms 222 -- that are used by the CA to sign the client's 223 -- X.509 certificate and are acceptable to the KDC 224 -- in the process of validating the client's X.509 225 -- certificate, in the order of decreasing 226 -- preference. 227 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 228 -- This identifies the digest algorithm that was 229 -- used to sign the client's X.509 certificate and 230 -- has been rejected by the KDC in the process of 231 -- validating the client's X.509 certificate 232 -- [RFC5280]. 233 ... 234 } 236 The KDC fills in the allowedAlgorithm field with the list of 237 algorithm [RFC5652] identifiers indicating digest algorithms that are 238 used by the CA to sign the client's X.509 certificate and are 239 acceptable to the KDC in the process of validating the client's X.509 240 certificate, in the order of decreasing preference. The 241 rejectedAlgorithm field identifies the signing algorithm for use in 242 signing the client's X.509 certificate that has been rejected by the 243 KDC in the process of validating the client's certificate [RFC5280]. 245 6. KDF agility 247 Section 3.2.3.1 of [RFC4556] is updated to define additional Key 248 Derivation Functions (KDFs) to derive a Kerberos protocol key based 249 on the secret value generated by the Diffie-Hellman key exchange. 250 Section 3.2.1 of [RFC4556] is updated to add a new field to the 251 AuthPack structure to indicate which new KDFs are supported by the 252 client. Section 3.2.3 of [RFC4556] is updated to add a new field to 253 the DHRepInfo structure to indicate which KDF is selected by the KDC. 255 The KDF algorithm described in this document (based on [SP80056A]) 256 can be implemented using any cryptographic hash function. 258 A new KDF for PKINIT usage is identified by an object identifier. 259 The following KDF object identifiers are defined: 261 id-pkinit OBJECT IDENTIFIER ::= 262 { iso(1) identified-organization(3) dod(6) internet(1) 263 security(5) kerberosv5(2) pkinit (3) } 264 -- Defined in RFC 4556 and quoted here for the reader. 266 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 267 -- PKINIT KDFs 269 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 270 ::= { id-pkinit-kdf sha1(1) } 271 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 273 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 274 ::= { id-pkinit-kdf sha256(2) } 275 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 277 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 278 ::= { id-pkinit-kdf sha512(3) } 279 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 281 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 282 ::= { id-pkinit-kdf sha384(4) } 283 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 285 Where id-pkinit is defined in [RFC4556]. All key derivation 286 functions specified above use the one-step key derivation method 287 described in Section 5.8.2.1 of [SP80056A], using the ASN.1 format 288 for FixedInfo, and Section 4.1 of [SP80056C], using option 1 for the 289 auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as 290 the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356, 291 and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 ([RFC6234] 292 and SHA-512 [RFC6234] respectively. 294 To name the input parameters, an abbreviated version of the key 295 derivation method is described below. 297 1. reps = ceiling(L/H_outputBits) 299 2. Initialize a 32-bit, big-endian bit string counter as 1. 301 3. For i = 1 to reps by 1, do the following: 303 1. Compute Hashi = H(counter || Z || OtherInfo). 305 2. Increment counter (not to exceed 2^32-1) 307 4. Set key_material = Hash1 || Hash2 || ... so that the length of 308 key_material is L bits, truncating the last block as necessary. 310 5. The above KDF produces a bit string of length L in bits as the 311 keying material. The AS reply key is the output of random-to- 312 key() [RFC3961] using that keying material as the input. 314 The input parameters for these KDFs are provided as follows: 316 o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for 317 id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and 318 512 bits for id-pkinit-kdf-ah-sha512. 320 o max_H_inputBits is 2^64. 322 o The secret value (Z) is the shared secret value generated by the 323 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 324 padded with leading zeros such that the size of the secret value 325 in octets is the same as that of the modulus, then represented as 326 a string of octets in big-endian order. 328 o The key data length (L) is the key-generation seed length in bits 329 [RFC3961] for the Authentication Service (AS) reply key. The 330 enctype of the AS reply key is selected according to [RFC4120]. 332 o The algorithm identifier (algorithmID) input parameter is the 333 identifier of the respective KDF. For example, this is id-pkinit- 334 kdf-ah-sha1 if the KDF uses SHA-1 as the hash. 336 o The initiator identifier (partyUInfo) contains the ASN.1 DER 337 encoding of the KRB5PrincipalName [RFC4556] that identifies the 338 client as specified in the AS-REQ [RFC4120] in the request. 340 o The recipient identifier (partyVInfo) contains the ASN.1 DER 341 encoding of the KRB5PrincipalName [RFC4556] that identifies the 342 TGS as specified in the AS-REQ [RFC4120] in the request. 344 o The supplemental public information (suppPubInfo) is the ASN.1 DER 345 encoding of the structure PkinitSuppPubInfo as defined later in 346 this section. 348 o The supplemental private information (suppPrivInfo) is absent. 350 OtherInfo is the ASN.1 DER encoding of the following sequence: 352 OtherInfo ::= SEQUENCE { 353 algorithmID AlgorithmIdentifier, 354 partyUInfo [0] OCTET STRING, 355 partyVInfo [1] OCTET STRING, 356 suppPubInfo [2] OCTET STRING OPTIONAL, 357 suppPrivInfo [3] OCTET STRING OPTIONAL 358 } 360 The structure PkinitSuppPubInfo is defined as follows: 362 PkinitSuppPubInfo ::= SEQUENCE { 363 enctype [0] Int32, 364 -- The enctype of the AS reply key. 365 as-REQ [1] OCTET STRING, 366 -- The DER encoding of the AS-REQ [RFC4120] from the 367 -- client. 368 pk-as-rep [2] OCTET STRING, 369 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 370 -- KDC reply. 371 ... 372 } 374 The PkinitSuppPubInfo structure contains mutually-known public 375 information specific to the authentication exchange. The enctype 376 field is the enctype of the AS reply key as selected according to 377 [RFC4120]. The as-REQ field contains the DER encoding of the type 378 AS-REQ [RFC4120] in the request sent from the client to the KDC. 379 Note that the as-REQ field does not include the wrapping 4 octet 380 length field when TCP is used. The pk-as-rep field contains the DER 381 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 382 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 383 authentication data and the corresponding ticket request and 384 response, thus addressing the concerns described in Section 3. 386 The KDF is negotiated between the client and the KDC. The client 387 sends an unordered set of supported KDFs in the request, and the KDC 388 picks one from the set in the reply. 390 To accomplish this, the AuthPack structure in [RFC4556] is extended 391 as follows: 393 AuthPack ::= SEQUENCE { 394 pkAuthenticator [0] PKAuthenticator, 395 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 396 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 397 OPTIONAL, 398 clientDHNonce [3] DHNonce OPTIONAL, 399 ..., 400 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 401 -- Contains an unordered set of KDFs supported by the 402 -- client. 403 ... 404 } 406 KDFAlgorithmId ::= SEQUENCE { 407 kdf-id [0] OBJECT IDENTIFIER, 408 -- The object identifier of the KDF 409 ... 410 } 412 The new field supportedKDFs contains an unordered set of KDFs 413 supported by the client. 415 The KDFAlgorithmId structure contains an object identifier that 416 identifies a KDF. The algorithm of the KDF and its parameters are 417 defined by the corresponding specification of that KDF. 419 The DHRepInfo structure in [RFC4556] is extended as follows: 421 DHRepInfo ::= SEQUENCE { 422 dhSignedData [0] IMPLICIT OCTET STRING, 423 serverDHNonce [1] DHNonce OPTIONAL, 424 ..., 425 kdf [2] KDFAlgorithmId OPTIONAL, 426 -- The KDF picked by the KDC. 427 ... 428 } 430 The new field kdf in the extended DHRepInfo structure identifies the 431 KDF picked by the KDC. If the supportedKDFs field is present in the 432 request, a KDC conforming to this specification MUST choose one of 433 the KDFs supported by the client and indicate its selection in the 434 kdf field in the reply. If the supportedKDFs field is absent in the 435 request, the KDC MUST omit the kdf field in the reply and use the key 436 derivation function from Section 3.2.3.1 of [RFC4556]. If none of 437 the KDFs supported by the client is acceptable to the KDC, the KDC 438 MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF: 440 o KDC_ERR_NO_ACCEPTABLE_KDF 100 442 If the client fills the supportedKDFs field in the request, but the 443 kdf field in the reply is not present, the client can deduce that the 444 KDC is not updated to conform with this specification, or that the 445 exchange was subjected to a downgrade attack. It is a matter of 446 local policy on the client whether to reject the reply when the kdf 447 field is absent in the reply; if compatibility with non-updated KDCs 448 is not a concern, the reply should be rejected. 450 Implementations conforming to this specification MUST support id- 451 pkinit-kdf-ah-sha256. 453 7. Interoperability 455 An old client interoperating with a new KDC will not recognize a TD- 456 CMS-DIGEST-ALGORITHMS-DATA element in a 457 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT- 458 DIGEST-ALGORITHMS-DATA element in a 459 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. Because the error data is 460 encoded as typed data, the client will ignore the unrecognized 461 elements. 463 An old KDC interoperating with a new client will not include a TD- 464 CMS-DIGEST-ALGORITHMS-DATA element in a 465 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT- 466 DIGEST-ALGORITHMS-DATA element in a 467 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. To the client this 468 appears just as if a new KDC elected not to include a list of digest 469 algorithms. 471 An old client interoperating with a new KDC will not include the 472 supportedKDFs field in the request. The KDC MUST omit the kdf field 473 in the reply and use the [RFC4556] KDF as expected by the client, or 474 reject the request if local policy forbids use of the old KDF. 476 A new client interoperating with an old KDC will include the 477 supportedKDFs field in the request; this field will be ignored as an 478 unknown extension by the KDC. The KDC will omit the kdf field in the 479 reply and will use the [RFC4556] KDF. The client can deduce from the 480 omitted kdf field that the KDC is not updated to conform to this 481 specification, or that the exchange was subjected to a downgrade 482 attack. The client MUST use the [RFC4556] KDF, or reject the reply 483 if local policy forbids the use of the old KDF. 485 8. Test vectors 487 This section contains test vectors for the KDF defined above. 489 8.1. Common Inputs 491 Z: Length = 256 bytes, Hex Representation = (All Zeros) 492 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 493 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 494 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 495 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 496 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 497 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 498 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 499 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 501 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 503 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 505 as-req: Length = 10 bytes, Hex Representation = 506 AAAAAAAA AAAAAAAA AAAA 508 pk-as-rep: Length = 9 bytes, Hex Representation = 509 BBBBBBBB BBBBBBBB BB 511 ticket: Length = 55 bytes, Hex Representation = 512 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 513 036C6861 A311300F A0030201 12A20804 0668656A 68656A 515 8.2. Test Vector for SHA-1, enctype 18 517 8.2.1. Specific Inputs 519 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 520 Representation = 2B060105 02030601 522 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 523 Representation = 18 525 8.2.2. Outputs 526 key-material: Length = 32 bytes, Hex Representation = 527 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 529 key: Length = 32 bytes, Hex Representation = 530 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 532 8.3. Test Vector for SHA-256, enctype 534 8.3.1. Specific Inputs 536 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 537 Representation = 2B060105 02030602 539 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 540 Representation = 18 542 8.3.2. Outputs 544 key-material: Length = 32 bytes, Hex Representation = 545 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 547 key: Length = 32 bytes, Hex Representation = 548 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 550 8.4. Test Vector for SHA-512, enctype 552 8.4.1. Specific Inputs 554 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 555 Representation = 2B060105 02030603 557 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 559 8.4.2. Outputs 561 key-material: Length = 24 bytes, Hex Representation = 562 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 564 key: Length = 32 bytes, Hex Representation = 565 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 567 9. Security Considerations 569 This document describes negotiation of checksum types, key derivation 570 functions and other cryptographic functions. If a given negotiation 571 is unauthenticated, care must be taken to accept only secure values; 572 to do otherwise allows an active attacker to perform a downgrade 573 attack. 575 The discovery method described in Section 4 uses a Kerberos error 576 message, which is unauthenticated in a typical exchange. An attacker 577 may attempt to downgrade a client to a weaker CMS type by forging a 578 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of 579 local policy whether a client accepts a downgrade to a weaker CMS 580 type, and whether the KDC accepts the weaker CMS type. A client may 581 reasonably assume that the real KDC implements all hash functions 582 used in the client's X.509 certificate, and refuse attempts to 583 downgrade to weaker hash functions. 585 The discovery method described in Section 5 also uses a Kerberos 586 error message. An attacker may attempt to downgrade a client to a 587 certificate using a weaker signing algorithm by forging a 588 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local 589 policy whether a client accepts a downgrade to a weaker certificate, 590 and whether the KDC accepts the weaker certificate. This attack is 591 only possible if the client device possesses multiple client 592 certificates of varying strength. 594 In the KDF negotiation method described in Section 6, the client 595 supportedKDFs value is protected by the signature on the 596 signedAuthPack field in the request. If this signature algorithm is 597 weak to collision attacks, an attacker may attempt to downgrade the 598 negotiation by substituting an AuthPack with a different or absent 599 supportedKDFs value, using a PKINIT freshness token [RFC8070] to 600 partially control the legitimate AuthPack value. A client performing 601 anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker 602 can easily remove the supportedKDFs value in this case. Finally, the 603 kdf field in the DHRepInfo of the KDC response is unauthenticated, so 604 could be altered or removed by an attacker, although this alteration 605 will likely result in a decryption failure by the client rather than 606 a successful downgrade. It is a matter of local policy whether a 607 client accepts a downgrade to the old KDF, and whether the KDC allows 608 the use of the old KDF. 610 The paChecksum field, which binds the client pre-authentication data 611 to the Kerberos request body, remains fixed at SHA-1. If an attacker 612 substitutes a different request body using an attack against SHA-1 (a 613 second preimage attack is likely required as the attacker does not 614 control any part of the legitimate request body), the KDC will not 615 detect the substitution. Instead, if a new KDF is negotiated, the 616 client will detect the substitution by failing to decrypt the reply. 618 An attacker may attempt to impersonate the KDC to the client via an 619 attack on the hash function used in the dhSignedData signature, 620 substituting the attacker's subjectPublicKey for the legitimate one 621 without changing the hash value. It is a matter of local policy 622 which hash function the KDC uses in its signature and which hash 623 functions the client will accept in the KDC signature. A KDC may 624 reasonably assume that the client implements all hash functions used 625 in the KDF algorithms listed the supportedKDFs field of the request. 627 10. Acknowledgements 629 Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, 630 Scott Bradner, and Eric Rescorla reviewed the document and provided 631 suggestions for improvements. 633 11. IANA Considerations 635 IANA is requested to update the following registrations in the 636 Kerberos Pre-authentication and Typed Data Registry created by 637 section 7.1 of RFC 6113 to refer to this specification. These values 638 were reserved for this specification in the initial registrations. 640 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 641 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 643 12. References 645 12.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 653 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 654 2005, . 656 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 657 Kerberos Network Authentication Service (V5)", RFC 4120, 658 DOI 10.17487/RFC4120, July 2005, 659 . 661 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 662 Authentication in Kerberos (PKINIT)", RFC 4556, 663 DOI 10.17487/RFC4556, June 2006, 664 . 666 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 667 Housley, R., and W. Polk, "Internet X.509 Public Key 668 Infrastructure Certificate and Certificate Revocation List 669 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 670 . 672 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 673 RFC 5652, DOI 10.17487/RFC5652, September 2009, 674 . 676 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 677 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 678 DOI 10.17487/RFC6234, May 2011, 679 . 681 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 682 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 683 May 2017, . 685 [SP80056A] 686 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 687 Davis, "Recommendation for Pair-Wise Key Establishment 688 Schemes Using Discrete Logarithm Cryptography", April 689 2018. 691 [SP80056C] 692 Barker, E., Chen, L., and R. Davis, "Recommendation for 693 Key-Derivation Methods in Key-Establishment Schemes", 694 April 2018. 696 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 697 8824-1:2002, Information technology - Abstract Syntax 698 Notation One (ASN.1): Specification of basic notation", 699 November 2008. 701 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 702 8825-1:2002, Information technology - ASN.1 encoding 703 Rules: Specification of Basic Encoding Rules (BER), 704 Canonical Encoding Rules (CER) and Distinguished Encoding 705 Rules (DER)", November 2008. 707 12.2. Informative References 709 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 710 DOI 10.17487/RFC1321, April 1992, 711 . 713 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 714 RFC 6150, DOI 10.17487/RFC6150, March 2011, 715 . 717 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 718 Considerations for the SHA-0 and SHA-1 Message-Digest 719 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 720 . 722 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 723 Agility and Selecting Mandatory-to-Implement Algorithms", 724 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 725 . 727 [RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed., 728 "Anonymity Support for Kerberos", RFC 8062, 729 DOI 10.17487/RFC8062, February 2017, 730 . 732 [RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key 733 Cryptography for Initial Authentication in Kerberos 734 (PKINIT) Freshness Extension", RFC 8070, 735 DOI 10.17487/RFC8070, February 2017, 736 . 738 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 739 "Cryptanalysis of Hash functions MD4 and RIPEMD", August 740 2004. 742 Appendix A. PKINIT ASN.1 Module 744 KerberosV5-PK-INIT-Agility-SPEC { 745 iso(1) identified-organization(3) dod(6) internet(1) 746 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 747 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 749 IMPORTS 750 AlgorithmIdentifier, SubjectPublicKeyInfo 751 FROM PKIX1Explicit88 { iso (1) 752 identified-organization (3) dod (6) internet (1) 753 security (5) mechanisms (5) pkix (7) id-mod (0) 754 id-pkix1-explicit (18) } 755 -- As defined in RFC 5280. 757 Ticket, Int32, Realm, EncryptionKey, Checksum 758 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 759 dod(6) internet(1) security(5) kerberosV5(2) 760 modules(4) krb5spec2(2) } 761 -- as defined in RFC 4120. 763 PKAuthenticator, DHNonce, id-pkinit 764 FROM KerberosV5-PK-INIT-SPEC { 765 iso(1) identified-organization(3) dod(6) internet(1) 766 security(5) kerberosV5(2) modules(4) pkinit(5) }; 767 -- as defined in RFC 4556. 769 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 770 -- PKINIT KDFs 772 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 773 ::= { id-pkinit-kdf sha1(1) } 774 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 776 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 777 ::= { id-pkinit-kdf sha256(2) } 778 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 780 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 781 ::= { id-pkinit-kdf sha512(3) } 782 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 784 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 785 ::= { id-pkinit-kdf sha384(4) } 786 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 788 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 789 AlgorithmIdentifier 790 -- Contains the list of CMS algorithm [RFC5652] 791 -- identifiers indicating the digest algorithms 792 -- acceptable to the KDC for signing CMS data in 793 -- the order of decreasing preference. 795 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 796 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 797 -- Contains the list of CMS algorithm [RFC5652] 798 -- identifiers indicating the digest algorithms 799 -- that are used by the CA to sign the client's 800 -- X.509 certificate and are acceptable to the KDC 801 -- in the process of validating the client's X.509 802 -- certificate, in the order of decreasing 803 -- preference. 804 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 805 -- This identifies the digest algorithm that was 806 -- used to sign the client's X.509 certificate and 807 -- has been rejected by the KDC in the process of 808 -- validating the client's X.509 certificate 809 -- [RFC5280]. 810 ... 811 } 813 OtherInfo ::= SEQUENCE { 814 algorithmID AlgorithmIdentifier, 815 partyUInfo [0] OCTET STRING, 816 partyVInfo [1] OCTET STRING, 817 suppPubInfo [2] OCTET STRING OPTIONAL, 818 suppPrivInfo [3] OCTET STRING OPTIONAL 819 } 821 PkinitSuppPubInfo ::= SEQUENCE { 822 enctype [0] Int32, 823 -- The enctype of the AS reply key. 824 as-REQ [1] OCTET STRING, 825 -- The DER encoding of the AS-REQ [RFC4120] from the 826 -- client. 827 pk-as-rep [2] OCTET STRING, 828 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 829 -- KDC reply. 830 ... 831 } 833 AuthPack ::= SEQUENCE { 834 pkAuthenticator [0] PKAuthenticator, 835 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 836 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 837 OPTIONAL, 838 clientDHNonce [3] DHNonce OPTIONAL, 839 ..., 840 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 841 -- Contains an unordered set of KDFs supported by the 842 -- client. 843 ... 844 } 846 KDFAlgorithmId ::= SEQUENCE { 847 kdf-id [0] OBJECT IDENTIFIER, 848 -- The object identifier of the KDF 849 ... 851 } 853 DHRepInfo ::= SEQUENCE { 854 dhSignedData [0] IMPLICIT OCTET STRING, 855 serverDHNonce [1] DHNonce OPTIONAL, 856 ..., 857 kdf [2] KDFAlgorithmId OPTIONAL, 858 -- The KDF picked by the KDC. 859 ... 860 } 861 END 863 Authors' Addresses 865 Love Hornquist Astrand 866 Apple, Inc 867 Cupertino, CA 868 USA 870 Email: lha@apple.com 872 Larry Zhu 873 Oracle Corporation 874 500 Oracle Parkway 875 Redwood Shores, CA 94065 876 USA 878 Email: larryzhu@live.com 880 Margaret Wasserman 881 Painless Security 882 356 Abbott Street 883 North Andover, MA 01845 884 USA 886 Phone: +1 781 405-7464 887 Email: mrw@painless-security.com 888 URI: http://www.painless-security.com 890 Greg Hudson 891 MIT 893 Email: ghudson@mit.edu