idnits 2.17.00 (12 Aug 2021) /tmp/idnits34892/draft-ietf-kitten-pkinit-alg-agility-06.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 == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (March 6, 2019) is 1171 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 789 -- Looks like a reference, but probably isn't: '1' on line 790 -- Looks like a reference, but probably isn't: '2' on line 792 -- Looks like a reference, but probably isn't: '3' on line 774 -- Looks like a reference, but probably isn't: '4' on line 776 == Missing Reference: 'ALG-AGILITY' is mentioned on line 589, 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 (~~), 3 warnings (==), 11 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: September 7, 2019 M. Wasserman 7 Painless Security 8 G. Hudson, Ed. 9 MIT 10 March 6, 2019 12 PKINIT Algorithm Agility 13 draft-ietf-kitten-pkinit-alg-agility-06 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 September 7, 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 . . . . . . . . . . . . . . . . . . . . . . 14 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 97 12.2. Informative References . . . . . . . . . . . . . . . . . 15 98 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 10. Acknowledgements 577 Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, 578 and Scott Bradner reviewed the document and provided suggestions for 579 improvements. 581 11. IANA Considerations 583 IANA is requested to update the following registrations in the 584 Kerberos Pre-authentication and Typed Data Registry created by 585 section 7.1 of RFC 6113 to refer to this specification. These values 586 were reserved for this specification in the initial registrations. 588 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 589 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 591 12. References 593 12.1. Normative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, 597 DOI 10.17487/RFC2119, March 1997, 598 . 600 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 601 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 602 2005, . 604 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 605 Kerberos Network Authentication Service (V5)", RFC 4120, 606 DOI 10.17487/RFC4120, July 2005, 607 . 609 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 610 Authentication in Kerberos (PKINIT)", RFC 4556, 611 DOI 10.17487/RFC4556, June 2006, 612 . 614 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 615 Housley, R., and W. Polk, "Internet X.509 Public Key 616 Infrastructure Certificate and Certificate Revocation List 617 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 618 . 620 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 621 RFC 5652, DOI 10.17487/RFC5652, September 2009, 622 . 624 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 625 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 626 DOI 10.17487/RFC6234, May 2011, 627 . 629 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 630 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 631 May 2017, . 633 [SP80056A] 634 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 635 Davis, "Recommendation for Pair-Wise Key Establishment 636 Schemes Using Discrete Logarithm Cryptography", April 637 2018. 639 [SP80056C] 640 Barker, E., Chen, L., and R. Davis, "Recommendation for 641 Key-Derivation Methods in Key-Establishment Schemes", 642 April 2018. 644 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 645 8824-1:2002, Information technology - Abstract Syntax 646 Notation One (ASN.1): Specification of basic notation", 647 November 2008. 649 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 650 8825-1:2002, Information technology - ASN.1 encoding 651 Rules: Specification of Basic Encoding Rules (BER), 652 Canonical Encoding Rules (CER) and Distinguished Encoding 653 Rules (DER)", November 2008. 655 12.2. Informative References 657 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 658 DOI 10.17487/RFC1321, April 1992, 659 . 661 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 662 RFC 6150, DOI 10.17487/RFC6150, March 2011, 663 . 665 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 666 Considerations for the SHA-0 and SHA-1 Message-Digest 667 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 668 . 670 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 671 Agility and Selecting Mandatory-to-Implement Algorithms", 672 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 673 . 675 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 676 "Cryptanalysis of Hash functions MD4 and RIPEMD", August 677 2004. 679 Appendix A. PKINIT ASN.1 Module 681 KerberosV5-PK-INIT-Agility-SPEC { 682 iso(1) identified-organization(3) dod(6) internet(1) 683 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 684 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 686 IMPORTS 687 AlgorithmIdentifier, SubjectPublicKeyInfo 688 FROM PKIX1Explicit88 { iso (1) 689 identified-organization (3) dod (6) internet (1) 690 security (5) mechanisms (5) pkix (7) id-mod (0) 691 id-pkix1-explicit (18) } 692 -- As defined in RFC 5280. 694 Ticket, Int32, Realm, EncryptionKey, Checksum 695 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 696 dod(6) internet(1) security(5) kerberosV5(2) 697 modules(4) krb5spec2(2) } 698 -- as defined in RFC 4120. 700 PKAuthenticator, DHNonce, id-pkinit 701 FROM KerberosV5-PK-INIT-SPEC { 702 iso(1) identified-organization(3) dod(6) internet(1) 703 security(5) kerberosV5(2) modules(4) pkinit(5) }; 704 -- as defined in RFC 4556. 706 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 707 -- PKINIT KDFs 709 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 710 ::= { id-pkinit-kdf sha1(1) } 711 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 713 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 714 ::= { id-pkinit-kdf sha256(2) } 715 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 717 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 718 ::= { id-pkinit-kdf sha512(3) } 719 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 721 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 722 ::= { id-pkinit-kdf sha384(4) } 723 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 725 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 726 AlgorithmIdentifier 727 -- Contains the list of CMS algorithm [RFC5652] 728 -- identifiers indicating the digest algorithms 729 -- acceptable to the KDC for signing CMS data in 730 -- the order of decreasing preference. 732 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 733 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 734 -- Contains the list of CMS algorithm [RFC5652] 735 -- identifiers indicating the digest algorithms 736 -- that are used by the CA to sign the client's 737 -- X.509 certificate and are acceptable to the KDC 738 -- in the process of validating the client's X.509 739 -- certificate, in the order of decreasing 740 -- preference. 741 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 742 -- This identifies the digest algorithm that was 743 -- used to sign the client's X.509 certificate and 744 -- has been rejected by the KDC in the process of 745 -- validating the client's X.509 certificate 746 -- [RFC5280]. 747 ... 748 } 750 OtherInfo ::= SEQUENCE { 751 algorithmID AlgorithmIdentifier, 752 partyUInfo [0] OCTET STRING, 753 partyVInfo [1] OCTET STRING, 754 suppPubInfo [2] OCTET STRING OPTIONAL, 755 suppPrivInfo [3] OCTET STRING OPTIONAL 756 } 757 PkinitSuppPubInfo ::= SEQUENCE { 758 enctype [0] Int32, 759 -- The enctype of the AS reply key. 760 as-REQ [1] OCTET STRING, 761 -- The DER encoding of the AS-REQ [RFC4120] from the 762 -- client. 763 pk-as-rep [2] OCTET STRING, 764 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 765 -- KDC reply. 766 ... 767 } 769 AuthPack ::= SEQUENCE { 770 pkAuthenticator [0] PKAuthenticator, 771 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 772 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 773 OPTIONAL, 774 clientDHNonce [3] DHNonce OPTIONAL, 775 ..., 776 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 777 -- Contains an unordered set of KDFs supported by the 778 -- client. 779 ... 780 } 782 KDFAlgorithmId ::= SEQUENCE { 783 kdf-id [0] OBJECT IDENTIFIER, 784 -- The object identifier of the KDF 785 ... 786 } 788 DHRepInfo ::= SEQUENCE { 789 dhSignedData [0] IMPLICIT OCTET STRING, 790 serverDHNonce [1] DHNonce OPTIONAL, 791 ..., 792 kdf [2] KDFAlgorithmId OPTIONAL, 793 -- The KDF picked by the KDC. 794 ... 795 } 796 END 798 Authors' Addresses 799 Love Hornquist Astrand 800 Apple, Inc 801 Cupertino, CA 802 USA 804 Email: lha@apple.com 806 Larry Zhu 807 Oracle Corporation 808 500 Oracle Parkway 809 Redwood Shores, CA 94065 810 USA 812 Email: larryzhu@live.com 814 Margaret Wasserman 815 Painless Security 816 356 Abbott Street 817 North Andover, MA 01845 818 USA 820 Phone: +1 781 405-7464 821 Email: mrw@painless-security.com 822 URI: http://www.painless-security.com 824 Greg Hudson (editor) 825 MIT 827 Email: ghudson@mit.edu