idnits 2.17.1 draft-ietf-kitten-pkinit-alg-agility-05.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 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 (February 26, 2019) is 1884 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 793 -- Looks like a reference, but probably isn't: '1' on line 794 -- Looks like a reference, but probably isn't: '2' on line 796 -- Looks like a reference, but probably isn't: '3' on line 778 -- Looks like a reference, but probably isn't: '4' on line 780 == Missing Reference: 'ALG-AGILITY' is mentioned on line 583, 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: 1 error (**), 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 Microsoft Corporation 6 Expires: August 30, 2019 M. Wasserman 7 Painless Security 8 G. Hudson, Ed. 9 MIT 10 February 26, 2019 12 PKINIT Algorithm Agility 13 draft-ietf-kitten-pkinit-alg-agility-05 15 Abstract 17 This document updates PKINIT, as defined in RFC 4556, to remove 18 protocol structures tied to specific cryptographic algorithms. The 19 PKINIT key derivation function is made negotiable, and the digest 20 algorithms for signing the pre-authentication data and the client's 21 X.509 certificates are made discoverable. 23 These changes provide preemptive protection against vulnerabilities 24 discovered in the future against any specific cryptographic 25 algorithm, and allow incremental deployment of newer algorithms. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 30, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 75 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4 76 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4 77 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5 78 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 80 8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11 82 8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 83 8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 84 8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13 86 8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 87 8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13 89 8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 90 8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 12.2. Informative References . . . . . . . . . . . . . . . . . 15 98 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 This document updates PKINIT [RFC4556] to remove protocol structures 104 tied to specific cryptographic algorithms. The PKINIT key derivation 105 function is made negotiable, the digest algorithms for signing the 106 pre-authentication data and the client's X.509 certificates are made 107 discoverable. 109 These changes provide preemptive protection against vulnerabilities 110 discovered in the future against any specific cryptographic 111 algorithm, and allow incremental deployment of newer algorithms. 113 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] 114 collisions generated using hand calculation [WANG04], alongside 115 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 116 SHA [RFC6234] family. These attacks and their consequences are 117 discussed in [RFC6194]. These discoveries challenged the security of 118 protocols relying on the collision resistance properties of these 119 hashes. 121 The Internet Engineering Task Force (IETF) called for actions to 122 update existing protocols to provide crypto algorithm agility so that 123 protocols support multiple cryptographic algorithms (including hash 124 functions) and provide clean, tested transition strategies between 125 algorithms, as recommended by BCP 201 [RFC7696]. 127 This document updates PKINIT to provide crypto algorithm agility. 128 Several protocol structures used in the [RFC4556] protocol are either 129 tied to SHA-1, or do not support negotiation or discovery, but are 130 instead based on local policy. The following concerns have been 131 addressed in this update: 133 o The checksum algorithm in the authentication request is hardwired 134 to use SHA-1 [RFC6234]. 136 o The acceptable digest algorithms for signing the authentication 137 data are not discoverable. 139 o The key derivation function in Section 3.2.3.1 of [RFC4556] is 140 hardwired to use SHA-1. 142 o The acceptable digest algorithms for signing the client X.509 143 certificates are not discoverable. 145 To address these concerns, new key derivation functions (KDFs), 146 identified by object identifiers, are defined. The PKINIT client 147 provides a list of KDFs in the request and the Key Distribution 148 Center (KDC) picks one in the response, thus a mutually-supported KDF 149 is negotiated. 151 Furthermore, structures are defined to allow the client to discover 152 the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms 153 supported by the KDC for signing the pre-authentication data and 154 signing the client X.509 certificate. 156 2. Requirements Notation 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 3. paChecksum Agility 166 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 167 cryptographic binding between the client's pre-authentication data 168 and the corresponding Kerberos request body. This also prevents the 169 KDC-REQ body from being tampered with. SHA-1 is the only allowed 170 checksum algorithm defined in [RFC4556]. This facility relies on the 171 collision resistance properties of the SHA-1 checksum [RFC6234]. 173 When the reply key delivery mechanism is based on public key 174 encryption as described in Section 3.2.3.2 of [RFC4556], the 175 asChecksum in the KDC reply provides the binding between the pre- 176 authentication and the ticket request and response messages, and 177 integrity protection for the unauthenticated clear text in these 178 messages. However, if the reply key delivery mechanism is based on 179 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 180 [RFC4556], the security provided by using SHA-1 in the paChecksum is 181 weak, and nothing else cryptographically binds the AS request to the 182 ticket response. In this case, the new KDF selected by the KDC as 183 described in Section 6 provides the cryptographic binding and 184 integrity protection. 186 4. CMS Digest Algorithm Agility 188 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 189 as described in Section 3.2.2 of [RFC4556], implementations 190 conforming to this specification can OPTIONALLY send back a list of 191 supported CMS types signifying the digest algorithms supported by the 192 KDC, in the decreasing preference order. This is accomplished by 193 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 194 error data. 196 td-cms-digest-algorithms INTEGER ::= 111 198 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 199 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 200 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 202 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 203 AlgorithmIdentifier 204 -- Contains the list of CMS algorithm [RFC5652] 205 -- identifiers indicating the digest algorithms 206 -- acceptable to the KDC for signing CMS data in 207 -- the order of decreasing preference. 209 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 210 digest algorithms supported by the KDC. 212 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 213 can facilitate trouble-shooting when none of the digest algorithms 214 supported by the client is supported by the KDC. 216 5. X.509 Certificate Signer Algorithm Agility 218 When the client's X.509 certificate is rejected and the 219 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 220 described in Section 3.2.2 of [RFC4556], implementations conforming 221 to this specification can OPTIONALLY send a list of digest algorithms 222 acceptable to the KDC for use by the Certificate Authority (CA) in 223 signing the client's X.509 certificate, in the decreasing preference 224 order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS 225 typed data element in the error data. The corresponding data 226 contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST- 227 ALGORITHMS-DATA defined as follows: 229 td-cert-digest-algorithms INTEGER ::= 112 231 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 232 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 233 -- Contains the list of CMS algorithm [RFC5652] 234 -- identifiers indicating the digest algorithms 235 -- that are used by the CA to sign the client's 236 -- X.509 certificate and are acceptable to the KDC 237 -- in the process of validating the client's X.509 238 -- certificate, in the order of decreasing 239 -- preference. 240 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 241 -- This identifies the digest algorithm that was 242 -- used to sign the client's X.509 certificate and 243 -- has been rejected by the KDC in the process of 244 -- validating the client's X.509 certificate 245 -- [RFC5280]. 246 ... 247 } 249 The KDC fills in the allowedAlgorithm field with the list of 250 algorithm [RFC5652] identifiers indicating digest algorithms that are 251 used by the CA to sign the client's X.509 certificate and are 252 acceptable to the KDC in the process of validating the client's X.509 253 certificate, in the order of decreasing preference. The 254 rejectedAlgorithm field identifies the signing algorithm for use in 255 signing the client's X.509 certificate that has been rejected by the 256 KDC in the process of validating the client's certificate [RFC5280]. 258 6. KDF agility 260 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 261 a Key Derivation Function (KDF) that derives a Kerberos protocol key 262 based on the secret value generated by the Diffie-Hellman key 263 exchange. This KDF requires the use of SHA-1 [RFC6234]. 265 The KDF algorithm described in this document (based on [SP80056A]) 266 can be implemented using any cryptographic hash function. 268 A new KDF for PKINIT usage is identified by an object identifier. 269 The following KDF object identifiers are defined: 271 id-pkinit OBJECT IDENTIFIER ::= 272 { iso(1) identified-organization(3) dod(6) internet(1) 273 security(5) kerberosv5(2) pkinit (3) } 274 -- Defined in RFC 4556 and quoted here for the reader. 276 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 277 -- PKINIT KDFs 279 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 280 ::= { id-pkinit-kdf sha1(1) } 281 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 283 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 284 ::= { id-pkinit-kdf sha256(2) } 285 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 287 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 288 ::= { id-pkinit-kdf sha512(3) } 289 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 291 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 292 ::= { id-pkinit-kdf sha384(4) } 293 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 295 Where id-pkinit is defined in [RFC4556]. All key derivation 296 functions specified above use the one-step key derivation method 297 described in Section 5.8.2.1 of [SP80056A], using the ASN.1 format 298 for FixedInfo, and Section 4.1 of [SP80056C], using option 1 for the 299 auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as 300 the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356, 301 and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 ([RFC6234] 302 and SHA-512 [RFC6234] respectively. 304 To name the input parameters, an abbreviated version of the key 305 derivation method is described below. 307 1. reps = ceiling(L/H_outputBits) 309 2. Initialize a 32-bit, big-endian bit string counter as 1. 311 3. For i = 1 to reps by 1, do the following: 313 1. Compute Hashi = H(counter || Z || OtherInfo). 315 2. Increment counter (not to exceed 2^32-1) 317 4. Set key_material = Hash1 || Hash2 || ... so that the length of 318 key_material is L bits, truncating the last block as necessary. 320 5. The above KDF produces a bit string of length L in bits as the 321 keying material. The AS reply key is the output of random-to- 322 key() [RFC3961] using that keying material as the input. 324 The input parameters for these KDFs are provided as follows: 326 o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for 327 id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and 328 512 bits for id-pkinit-kdf-ah-sha512. 330 o max_H_inputBits is 2^64. 332 o The secret value (Z) is the shared secret value generated by the 333 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 334 padded with leading zeros such that the size of the secret value 335 in octets is the same as that of the modulus, then represented as 336 a string of octets in big-endian order. 338 o The key data length (L) is the key-generation seed length in bits 339 [RFC3961] for the Authentication Service (AS) reply key. The 340 enctype of the AS reply key is selected according to [RFC4120]. 342 o The algorithm identifier (algorithmID) input parameter is the 343 identifier of the respective KDF. For example, this is id-pkinit- 344 kdf-ah-sha1 if the KDF uses SHA-1 as the hash. 346 o The initiator identifier (partyUInfo) contains the ASN.1 DER 347 encoding of the KRB5PrincipalName [RFC4556] that identifies the 348 client as specified in the AS-REQ [RFC4120] in the request. 350 o The recipient identifier (partyVInfo) contains the ASN.1 DER 351 encoding of the KRB5PrincipalName [RFC4556] that identifies the 352 TGS as specified in the AS-REQ [RFC4120] in the request. 354 o The supplemental public information (suppPubInfo) is the ASN.1 DER 355 encoding of the structure PkinitSuppPubInfo as defined later in 356 this section. 358 o The supplemental private information (suppPrivInfo) is absent. 360 OtherInfo is the ASN.1 DER encoding of the following sequence: 362 OtherInfo ::= SEQUENCE { 363 algorithmID AlgorithmIdentifier, 364 partyUInfo [0] OCTET STRING, 365 partyVInfo [1] OCTET STRING, 366 suppPubInfo [2] OCTET STRING OPTIONAL, 367 suppPrivInfo [3] OCTET STRING OPTIONAL 368 } 370 The structure PkinitSuppPubInfo is defined as follows: 372 PkinitSuppPubInfo ::= SEQUENCE { 373 enctype [0] Int32, 374 -- The enctype of the AS reply key. 375 as-REQ [1] OCTET STRING, 376 -- The DER encoding of the AS-REQ [RFC4120] from the 377 -- client. 378 pk-as-rep [2] OCTET STRING, 379 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 380 -- KDC reply. 381 ... 382 } 384 The PkinitSuppPubInfo structure contains mutually-known public 385 information specific to the authentication exchange. The enctype 386 field is the enctype of the AS reply key as selected according to 387 [RFC4120]. The as-REQ field contains the DER encoding of the type 388 AS-REQ [RFC4120] in the request sent from the client to the KDC. 389 Note that the as-REQ field does not include the wrapping 4 octet 390 length field when TCP is used. The pk-as-rep field contains the DER 391 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 392 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 393 authentication data and the corresponding ticket request and 394 response, thus addressing the concerns described in Section 3. 396 The KDF is negotiated between the client and the KDC. The client 397 sends an unordered set of supported KDFs in the request, and the KDC 398 picks one from the set in the reply. 400 To accomplish this, the AuthPack structure in [RFC4556] is extended 401 as follows: 403 AuthPack ::= SEQUENCE { 404 pkAuthenticator [0] PKAuthenticator, 405 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 406 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 407 OPTIONAL, 408 clientDHNonce [3] DHNonce OPTIONAL, 409 ..., 410 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 411 -- Contains an unordered set of KDFs supported by the 412 -- client. 413 ... 414 } 416 KDFAlgorithmId ::= SEQUENCE { 417 kdf-id [0] OBJECT IDENTIFIER, 418 -- The object identifier of the KDF 419 ... 420 } 422 The new field supportedKDFs contains an unordered set of KDFs 423 supported by the client. 425 The KDFAlgorithmId structure contains an object identifier that 426 identifies a KDF. The algorithm of the KDF and its parameters are 427 defined by the corresponding specification of that KDF. 429 The DHRepInfo structure in [RFC4556] is extended as follows: 431 DHRepInfo ::= SEQUENCE { 432 dhSignedData [0] IMPLICIT OCTET STRING, 433 serverDHNonce [1] DHNonce OPTIONAL, 434 ..., 435 kdf [2] KDFAlgorithmId OPTIONAL, 436 -- The KDF picked by the KDC. 437 ... 438 } 440 The new field kdf in the extended DHRepInfo structure identifies the 441 KDF picked by the KDC. If the supportedKDFs field is present in the 442 request, a KDC conforming to this specification MUST choose one of 443 the KDFs supported by the client and indicate its selection in the 444 kdf field in the reply. If the supportedKDFs field is absent in the 445 request, the KDC MUST omit the kdf field in the reply and use the key 446 derivation function from Section 3.2.3.1 of [RFC4556]. If none of 447 the KDFs supported by the client is acceptable to the KDC, the KDC 448 MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF: 450 o KDC_ERR_NO_ACCEPTABLE_KDF 100 452 If the client fills the supportedKDFs field in the request, but the 453 kdf field in the reply is not present, the client can deduce that the 454 KDC is not updated to conform with this specification, or that the 455 exchange was subjected to a downgrade attack. It is a matter of 456 local policy on the client whether to reject the reply when the kdf 457 field is absent in the reply; if compatibility with non-updated KDCs 458 is not a concern, the reply should be rejected. 460 Implementations conforming to this specification MUST support id- 461 pkinit-kdf-ah-sha256. 463 7. Interoperability 465 An old client interoperating with a new KDC will not include the 466 supportedKDFs field in the request. The KDC MUST omit the kdf field 467 in the reply and use the [RFC4556] KDF as expected by the client, or 468 reject the request if local policy forbids use of the old KDF. 470 A new client interoperating with an old KDC will include the 471 supportedKDFs field in the request; this field will be ignored as an 472 unknown extension by the KDC. The KDC will omit the kdf field in the 473 reply and will use the [RFC4556] KDF. The client can deduce from the 474 omitted kdf field that the KDC is not updated to conform to this 475 specification, or that the exchange was subjected to a downgrade 476 attack. The client MUST use the [RFC4556] KDF, or reject the reply 477 if local policy forbids the use of the old KDF. 479 8. Test vectors 481 This section contains test vectors for the KDF defined above. 483 8.1. Common Inputs 484 Z: Length = 256 bytes, Hex Representation = (All Zeros) 485 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 486 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 487 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 488 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 489 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 490 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 491 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 492 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 494 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 496 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 498 as-req: Length = 10 bytes, Hex Representation = 499 AAAAAAAA AAAAAAAA AAAA 501 pk-as-rep: Length = 9 bytes, Hex Representation = 502 BBBBBBBB BBBBBBBB BB 504 ticket: Length = 55 bytes, Hex Representation = 505 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 506 036C6861 A311300F A0030201 12A20804 0668656A 68656A 508 8.2. Test Vector for SHA-1, enctype 18 510 8.2.1. Specific Inputs 512 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 513 Representation = 2B060105 02030601 515 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 516 Representation = 18 518 8.2.2. Outputs 520 key-material: Length = 32 bytes, Hex Representation = 521 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 523 key: Length = 32 bytes, Hex Representation = 524 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 526 8.3. Test Vector for SHA-256, enctype 528 8.3.1. Specific Inputs 530 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 531 Representation = 2B060105 02030602 533 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 534 Representation = 18 536 8.3.2. Outputs 538 key-material: Length = 32 bytes, Hex Representation = 539 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 541 key: Length = 32 bytes, Hex Representation = 542 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 544 8.4. Test Vector for SHA-512, enctype 546 8.4.1. Specific Inputs 548 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 549 Representation = 2B060105 02030603 551 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 553 8.4.2. Outputs 555 key-material: Length = 24 bytes, Hex Representation = 556 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 558 key: Length = 32 bytes, Hex Representation = 559 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 561 9. Security Considerations 563 This document describes negotiation of checksum types, key derivation 564 functions and other cryptographic functions. If a given negotiation 565 is unauthenticated, care must be taken to accept only secure values; 566 to do otherwise allows an active attacker to perform a downgrade 567 attack. 569 10. Acknowledgements 571 Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, 572 and Scott Bradner reviewed the document and provided suggestions for 573 improvements. 575 11. IANA Considerations 577 IANA is requested to update the following registrations in the 578 Kerberos Pre-authentication and Typed Data Registry created by 579 section 7.1 of RFC 6113 to refer to this specification. These values 580 were reserved for this specification in the initial registrations. 582 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 583 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 585 12. References 587 12.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 595 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 596 2005, . 598 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 599 Kerberos Network Authentication Service (V5)", RFC 4120, 600 DOI 10.17487/RFC4120, July 2005, 601 . 603 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 604 Authentication in Kerberos (PKINIT)", RFC 4556, 605 DOI 10.17487/RFC4556, June 2006, 606 . 608 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 609 Housley, R., and W. Polk, "Internet X.509 Public Key 610 Infrastructure Certificate and Certificate Revocation List 611 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 612 . 614 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 615 RFC 5652, DOI 10.17487/RFC5652, September 2009, 616 . 618 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 619 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 620 DOI 10.17487/RFC6234, May 2011, 621 . 623 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 624 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 625 May 2017, . 627 [SP80056A] 628 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 629 Davis, "Recommendation for Pair-Wise Key Establishment 630 Schemes Using Discrete Logarithm Cryptography", April 631 2018. 633 [SP80056C] 634 Barker, E., Chen, L., and R. Davis, "Recommendation for 635 Key-Derivation Methods in Key-Establishment Schemes", 636 April 2018. 638 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 639 8824-1:2002, Information technology - Abstract Syntax 640 Notation One (ASN.1): Specification of basic notation", 641 November 2008. 643 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 644 8825-1:2002, Information technology - ASN.1 encoding 645 Rules: Specification of Basic Encoding Rules (BER), 646 Canonical Encoding Rules (CER) and Distinguished Encoding 647 Rules (DER)", November 2008. 649 12.2. Informative References 651 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 652 DOI 10.17487/RFC1321, April 1992, 653 . 655 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 656 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 657 RFC 3766, DOI 10.17487/RFC3766, April 2004, 658 . 660 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 661 RFC 6150, DOI 10.17487/RFC6150, March 2011, 662 . 664 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 665 Considerations for the SHA-0 and SHA-1 Message-Digest 666 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 667 . 669 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 670 Agility and Selecting Mandatory-to-Implement Algorithms", 671 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 672 . 674 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 675 "Cryptanalysis of Hash functions MD4 and RIPEMD", August 676 2004. 678 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 679 Industry: Agreement of Symmetric Keys Using Discrete 680 Logarithm Cryptography", 2003. 682 Appendix A. PKINIT ASN.1 Module 684 KerberosV5-PK-INIT-Agility-SPEC { 685 iso(1) identified-organization(3) dod(6) internet(1) 686 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 687 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 689 IMPORTS 690 AlgorithmIdentifier, SubjectPublicKeyInfo 691 FROM PKIX1Explicit88 { iso (1) 692 identified-organization (3) dod (6) internet (1) 693 security (5) mechanisms (5) pkix (7) id-mod (0) 694 id-pkix1-explicit (18) } 695 -- As defined in RFC 5280. 697 Ticket, Int32, Realm, EncryptionKey, Checksum 698 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 699 dod(6) internet(1) security(5) kerberosV5(2) 700 modules(4) krb5spec2(2) } 701 -- as defined in RFC 4120. 703 PKAuthenticator, DHNonce, id-pkinit 704 FROM KerberosV5-PK-INIT-SPEC { 705 iso(1) identified-organization(3) dod(6) internet(1) 706 security(5) kerberosV5(2) modules(4) pkinit(5) }; 707 -- as defined in RFC 4556. 709 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 710 -- PKINIT KDFs 712 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 713 ::= { id-pkinit-kdf sha1(1) } 714 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 716 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 717 ::= { id-pkinit-kdf sha256(2) } 718 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 720 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 721 ::= { id-pkinit-kdf sha512(3) } 722 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 724 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 725 ::= { id-pkinit-kdf sha384(4) } 726 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 728 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 729 AlgorithmIdentifier 730 -- Contains the list of CMS algorithm [RFC5652] 731 -- identifiers indicating the digest algorithms 732 -- acceptable to the KDC for signing CMS data in 733 -- the order of decreasing preference. 735 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 736 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 737 -- Contains the list of CMS algorithm [RFC5652] 738 -- identifiers indicating the digest algorithms 739 -- that are used by the CA to sign the client's 740 -- X.509 certificate and are acceptable to the KDC 741 -- in the process of validating the client's X.509 742 -- certificate, in the order of decreasing 743 -- preference. 744 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 745 -- This identifies the digest algorithm that was 746 -- used to sign the client's X.509 certificate and 747 -- has been rejected by the KDC in the process of 748 -- validating the client's X.509 certificate 749 -- [RFC5280]. 750 ... 751 } 753 OtherInfo ::= SEQUENCE { 754 algorithmID AlgorithmIdentifier, 755 partyUInfo [0] OCTET STRING, 756 partyVInfo [1] OCTET STRING, 757 suppPubInfo [2] OCTET STRING OPTIONAL, 758 suppPrivInfo [3] OCTET STRING OPTIONAL 759 } 761 PkinitSuppPubInfo ::= SEQUENCE { 762 enctype [0] Int32, 763 -- The enctype of the AS reply key. 764 as-REQ [1] OCTET STRING, 765 -- The DER encoding of the AS-REQ [RFC4120] from the 766 -- client. 767 pk-as-rep [2] OCTET STRING, 768 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 769 -- KDC reply. 770 ... 771 } 773 AuthPack ::= SEQUENCE { 774 pkAuthenticator [0] PKAuthenticator, 775 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 776 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 777 OPTIONAL, 778 clientDHNonce [3] DHNonce OPTIONAL, 779 ..., 780 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 781 -- Contains an unordered set of KDFs supported by the 782 -- client. 783 ... 784 } 786 KDFAlgorithmId ::= SEQUENCE { 787 kdf-id [0] OBJECT IDENTIFIER, 788 -- The object identifier of the KDF 789 ... 790 } 792 DHRepInfo ::= SEQUENCE { 793 dhSignedData [0] IMPLICIT OCTET STRING, 794 serverDHNonce [1] DHNonce OPTIONAL, 795 ..., 796 kdf [2] KDFAlgorithmId OPTIONAL, 797 -- The KDF picked by the KDC. 798 ... 799 } 800 END 802 Authors' Addresses 804 Love Hornquist Astrand 805 Apple, Inc 806 Cupertino, CA 807 USA 809 Email: lha@apple.com 811 Larry Zhu 812 Microsoft Corporation 813 One Microsoft Way 814 Redmond, WA 98052 815 USA 817 Email: lzhu@microsoft.com 819 Margaret Wasserman 820 Painless Security 821 356 Abbott Street 822 North Andover, MA 01845 823 USA 825 Phone: +1 781 405-7464 826 Email: mrw@painless-security.com 827 URI: http://www.painless-security.com 829 Greg Hudson (editor) 830 MIT 832 Email: ghudson@mit.edu