idnits 2.17.1 draft-ietf-kitten-pkinit-alg-agility-04.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 3, 2019) is 1909 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 780 -- Looks like a reference, but probably isn't: '1' on line 781 -- Looks like a reference, but probably isn't: '2' on line 783 -- Looks like a reference, but probably isn't: '3' on line 765 -- Looks like a reference, but probably isn't: '4' on line 767 == Missing Reference: 'ALG-AGILITY' is mentioned on line 570, 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 7, 2019 M. Wasserman 7 Painless Security 8 G. Hudson, Ed. 9 MIT 10 February 3, 2019 12 PKINIT Algorithm Agility 13 draft-ietf-kitten-pkinit-alg-agility-04 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 7, 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. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11 81 7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 82 7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 83 7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13 85 7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 86 7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 87 7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13 88 7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 89 7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 11.2. Informative References . . . . . . . . . . . . . . . . . 15 96 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 This document updates PKINIT [RFC4556] to remove protocol structures 102 tied to specific cryptographic algorithms. The PKINIT key derivation 103 function is made negotiable, the digest algorithms for signing the 104 pre-authentication data and the client's X.509 certificates are made 105 discoverable. 107 These changes provide preemptive protection against vulnerabilities 108 discovered in the future against any specific cryptographic 109 algorithm, and allow incremental deployment of newer algorithms. 111 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] 112 collisions generated using hand calculation [WANG04], alongside 113 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 114 SHA [RFC6234] family. These attacks and their consequences are 115 discussed in [RFC6194]. These discoveries challenged the security of 116 protocols relying on the collision resistance properties of these 117 hashes. 119 The Internet Engineering Task Force (IETF) called for actions to 120 update existing protocols to provide crypto algorithm agility so that 121 protocols support multiple cryptographic algorithms (including hash 122 functions) and provide clean, tested transition strategies between 123 algorithms, as recommended by BCP 201 [RFC7696]. 125 This document updates PKINIT to provide crypto algorithm agility. 126 Several protocol structures used in the [RFC4556] protocol are either 127 tied to SHA-1, or do not support negotiation or discovery, but are 128 instead based on local policy. The following concerns have been 129 addressed in this update: 131 o The checksum algorithm in the authentication request is hardwired 132 to use SHA-1 [RFC6234]. 134 o The acceptable digest algorithms for signing the authentication 135 data are not discoverable. 137 o The key derivation function in Section 3.2.3.1 of [RFC4556] is 138 hardwired to use SHA-1. 140 o The acceptable digest algorithms for signing the client X.509 141 certificates are not discoverable. 143 To address these concerns, new key derivation functions (KDFs), 144 identified by object identifiers, are defined. The PKINIT client 145 provides a list of KDFs in the request and the Key Distribution 146 Center (KDC) picks one in the response, thus a mutually-supported KDF 147 is negotiated. 149 Furthermore, structures are defined to allow the client to discover 150 the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms 151 supported by the KDC for signing the pre-authentication data and 152 signing the client X.509 certificate. 154 2. Requirements Notation 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 3. paChecksum Agility 164 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 165 cryptographic binding between the client's pre-authentication data 166 and the corresponding Kerberos request body. This also prevents the 167 KDC-REQ body from being tampered with. SHA-1 is the only allowed 168 checksum algorithm defined in [RFC4556]. This facility relies on the 169 collision resistance properties of the SHA-1 checksum [RFC6234]. 171 When the reply key delivery mechanism is based on public key 172 encryption as described in Section 3.2.3.2 of [RFC4556], the 173 asChecksum in the KDC reply provides the binding between the pre- 174 authentication and the ticket request and response messages, and 175 integrity protection for the unauthenticated clear text in these 176 messages. However, if the reply key delivery mechanism is based on 177 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 178 [RFC4556], the security provided by using SHA-1 in the paChecksum is 179 weak, and nothing else cryptographically binds the AS request to the 180 ticket response. In this case, the new KDF selected by the KDC as 181 described in Section 6 provides the cryptographic binding and 182 integrity protection. 184 4. CMS Digest Algorithm Agility 186 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 187 as described in Section 3.2.2 of [RFC4556], implementations 188 conforming to this specification can OPTIONALLY send back a list of 189 supported CMS types signifying the digest algorithms supported by the 190 KDC, in the decreasing preference order. This is accomplished by 191 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 192 error data. 194 td-cms-digest-algorithms INTEGER ::= 111 196 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 197 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 198 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 200 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 201 AlgorithmIdentifier 202 -- Contains the list of CMS algorithm [RFC5652] 203 -- identifiers that indicate the digest algorithms 204 -- acceptable by the KDC for signing CMS data in 205 -- the order of decreasing preference. 207 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 208 digest algorithms supported by the KDC. 210 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 211 can facilitate trouble-shooting when none of the digest algorithms 212 supported by the client is supported by the KDC. 214 5. X.509 Certificate Signer Algorithm Agility 216 When the client's X.509 certificate is rejected and the 217 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 218 described in Section 3.2.2 of [RFC4556], implementations conforming 219 to this specification can OPTIONALLY send a list of digest algorithms 220 acceptable by the KDC for use by the Certificate Authority (CA) in 221 signing the client's X.509 certificate, in the decreasing preference 222 order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS 223 typed data element in the error data. The corresponding data 224 contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST- 225 ALGORITHMS-DATA defined as follows: 227 td-cert-digest-algorithms INTEGER ::= 112 229 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 230 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 231 -- Contains the list of CMS algorithm [RFC5652] 232 -- identifiers that identify the digest algorithms 233 -- that are used by the CA to sign the client's 234 -- X.509 certificate and acceptable by the KDC in 235 -- the process of validating the client's X.509 236 -- certificate, in the order of decreasing 237 -- preference. 238 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 239 -- This identifies the digest algorithm that was 240 -- used to sign the client's X.509 certificate and 241 -- has been rejected by the KDC in the process of 242 -- validating the client's X.509 certificate 243 -- [RFC5280]. 244 ... 245 } 247 The KDC fills in allowedAlgorithm field with the list of algorithm 248 [RFC5652] identifiers that identify digest algorithms that are used 249 by the CA to sign the client's X.509 certificate and acceptable by 250 the KDC in the process of validating the client's X.509 certificate, 251 in the order of decreasing preference. The rejectedAlgorithm field 252 identifies the signing algorithm for use in signing the client's 253 X.509 certificate that has been rejected by the KDC in the process of 254 validating the client's certificate [RFC5280]. 256 6. KDF agility 258 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 259 a Key Derivation Function (KDF) that derives a Kerberos protocol key 260 based on the secret value generated by the Diffie-Hellman key 261 exchange. This KDF requires the use of SHA-1 [RFC6234]. 263 The KDF algorithm described in this document (based on [SP80056A]) 264 can be implemented using any cryptographic hash function. 266 A new KDF for PKINIT usage is identified by an object identifier. 267 The following KDF object identifiers are defined: 269 id-pkinit OBJECT IDENTIFIER ::= 270 { iso(1) identified-organization(3) dod(6) internet(1) 271 security(5) kerberosv5(2) pkinit (3) } 272 -- Defined in RFC 4556 and quoted here for the reader. 274 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 275 -- PKINIT KDFs 277 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 278 ::= { id-pkinit-kdf sha1(1) } 279 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 281 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 282 ::= { id-pkinit-kdf sha256(2) } 283 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 285 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 286 ::= { id-pkinit-kdf sha512(3) } 287 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 289 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 290 ::= { id-pkinit-kdf sha384(4) } 291 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 293 Where id-pkinit is defined in [RFC4556]. All key derivation 294 functions specified above use the one-step key derivation method 295 described in Section 5.8.2.1 of [SP80056A], using the ASN.1 format 296 for FixedInfo, and Section 4.1 of [SP80056C], using option 1 for the 297 auxiliary function H. id-pkinit-kdf-ah-sha1 uses SHA-1 [RFC6234] as 298 the hash function. id-pkinit-kdf-ah-sha256, id-pkinit-kdf-ah-sha356, 299 and id-pkinit-kdf-ah-sha512 use SHA-256 [RFC6234], SHA-384 ([RFC6234] 300 and SHA-512 [RFC6234] respectively. 302 To name the input parameters, an abbreviated version of the key 303 derivation method is described below. 305 1. reps = ceiling(L/H_outputBits) 307 2. Initialize a 32-bit, big-endian bit string counter as 1. 309 3. For i = 1 to reps by 1, do the following: 311 1. Compute Hashi = H(counter || Z || OtherInfo). 313 2. Increment counter (not to exceed 2^32-1) 315 4. Set key_material = Hash1 || Hash2 || ... so that the length of 316 key_material is L bits, truncating the last block as necessary. 318 5. The above KDF produces a bit string of length L in bits as the 319 keying material. The AS reply key is the output of random-to- 320 key() [RFC3961] using that keying material as the input. 322 The input parameters for these KDFs are provided as follows: 324 o H_outputBits is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for 325 id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384, and 326 512 bits for id-pkinit-kdf-ah-sha512. 328 o max_H_inputBits is 2^64. 330 o The secret value (Z) is the shared secret value generated by the 331 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 332 padded with leading zeros such that the size of the secret value 333 in octets is the same as that of the modulus, then represented as 334 a string of octets in big-endian order. 336 o The key data length (L) is the key-generation seed length in bits 337 [RFC3961] for the Authentication Service (AS) reply key. The 338 enctype of the AS reply key is selected according to [RFC4120]. 340 o The algorithm identifier (algorithmID) input parameter is the 341 identifier of the respective KDF. For example, this is id-pkinit- 342 kdf-ah-sha1 if the KDF uses SHA-1 as the hash. 344 o The initiator identifier (partyUInfo) contains the ASN.1 DER 345 encoding of the KRB5PrincipalName [RFC4556] that identifies the 346 client as specified in the AS-REQ [RFC4120] in the request. 348 o The recipient identifier (partyVInfo) contains the ASN.1 DER 349 encoding of the KRB5PrincipalName [RFC4556] that identifies the 350 TGS as specified in the AS-REQ [RFC4120] in the request. 352 o The supplemental public information (suppPubInfo) is the ASN.1 DER 353 encoding of the structure PkinitSuppPubInfo as defined later in 354 this section. 356 o The supplemental private information (suppPrivInfo) is absent. 358 OtherInfo is the ASN.1 DER encoding of the following sequence: 360 OtherInfo ::= SEQUENCE { 361 algorithmID AlgorithmIdentifier, 362 partyUInfo [0] OCTET STRING, 363 partyVInfo [1] OCTET STRING, 364 suppPubInfo [2] OCTET STRING OPTIONAL, 365 suppPrivInfo [3] OCTET STRING OPTIONAL 366 } 368 The structure PkinitSuppPubInfo is defined as follows: 370 PkinitSuppPubInfo ::= SEQUENCE { 371 enctype [0] Int32, 372 -- The enctype of the AS reply key. 373 as-REQ [1] OCTET STRING, 374 -- The DER encoding of the AS-REQ [RFC4120] from the 375 -- client. 376 pk-as-rep [2] OCTET STRING, 377 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 378 -- KDC reply. 379 ... 380 } 382 The PkinitSuppPubInfo structure contains mutually-known public 383 information specific to the authentication exchange. The enctype 384 field is the enctype of the AS reply key as selected according to 385 [RFC4120]. The as-REQ field contains the DER encoding of the type 386 AS-REQ [RFC4120] in the request sent from the client to the KDC. 387 Note that the as-REQ field does not include the wrapping 4 octet 388 length field when TCP is used. The pk-as-rep field contains the DER 389 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 390 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 391 authentication data and the corresponding ticket request and 392 response, thus addressing the concerns described in Section 3. 394 The KDF is negotiated between the client and the KDC. The client 395 sends an unordered set of supported KDFs in the request, and the KDC 396 picks one from the set in the reply. 398 To acomplish this, the AuthPack structure in [RFC4556] is extended as 399 follows: 401 AuthPack ::= SEQUENCE { 402 pkAuthenticator [0] PKAuthenticator, 403 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 404 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 405 OPTIONAL, 406 clientDHNonce [3] DHNonce OPTIONAL, 407 ..., 408 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 409 -- Contains an unordered set of KDFs supported by the 410 -- client. 411 ... 412 } 414 KDFAlgorithmId ::= SEQUENCE { 415 kdf-id [0] OBJECT IDENTIFIER, 416 -- The object identifier of the KDF 417 ... 418 } 420 The new field supportedKDFs contains an unordered set of KDFs 421 supported by the client. 423 The KDFAlgorithmId structure contains an object identifier that 424 identifies a KDF. The algorithm of the KDF and its parameters are 425 defined by the corresponding specification of that KDF. 427 The DHRepInfo structure in [RFC4556] is extended as follows: 429 DHRepInfo ::= SEQUENCE { 430 dhSignedData [0] IMPLICIT OCTET STRING, 431 serverDHNonce [1] DHNonce OPTIONAL, 432 ..., 433 kdf [2] KDFAlgorithmId OPTIONAL, 434 -- The KDF picked by the KDC. 435 ... 436 } 438 The new field kdf in the extended DHRepInfo structure identifies the 439 KDF picked by the KDC. This kdf field MUST be filled by the 440 comforming KDC if the supportedKDFs field is present in the request, 441 and it MUST be one of the KDFs supported by the client as indicated 442 in the request. Which KDF is chosen is a matter of the local policy 443 on the KDC. 445 If the supportedKDFs field is not present in the request, the kdf 446 field in the reply MUST be absent, and the key derivation function 447 from Section 3.2.3.1 of [RFC4556] MUST be used. 449 If the client fills the supportedKDFs field in the request, but the 450 kdf field in the reply is not present, the client can deduce that the 451 KDC is not updated to conform with this specification, or that the 452 exchange was subjected to a downgrade attack. It is a matter of 453 local policy on the client whether to reject the reply when the kdf 454 field is absent in the reply; if compatibility with non-updated KDCs 455 is not a concern, the reply should be rejected. 457 Implementations comforming to this specification MUST support id- 458 pkinit-kdf-ah-sha256. 460 This document introduces the following new PKINIT error code: 462 o KDC_ERR_NO_ACCEPTABLE_KDF 100 464 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF 465 (100) will be returned.. 467 7. Test vectors 469 This section contains test vectors for the KDF defined above. 471 7.1. Common Inputs 472 Z: Length = 256 bytes, Hex Representation = (All Zeros) 473 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 474 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 475 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 476 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 477 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 478 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 479 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 480 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 482 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 484 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 486 as-req: Length = 10 bytes, Hex Representation = 487 AAAAAAAA AAAAAAAA AAAA 489 pk-as-rep: Length = 9 bytes, Hex Representation = 490 BBBBBBBB BBBBBBBB BB 492 ticket: Length = 55 bytes, Hex Representation = 493 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 494 036C6861 A311300F A0030201 12A20804 0668656A 68656A 496 7.2. Test Vector for SHA-1, enctype 18 498 7.2.1. Specific Inputs 500 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 501 Representation = 2B060105 02030601 503 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 504 Representation = 18 506 7.2.2. Outputs 508 key-material: Length = 32 bytes, Hex Representation = 509 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 511 key: Length = 32 bytes, Hex Representation = 512 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 514 7.3. Test Vector for SHA-256, enctype 516 7.3.1. Specific Inputs 518 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 519 Representation = 2B060105 02030602 521 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 522 Representation = 18 524 7.3.2. Outputs 526 key-material: Length = 32 bytes, Hex Representation = 527 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 529 key: Length = 32 bytes, Hex Representation = 530 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 532 7.4. Test Vector for SHA-512, enctype 534 7.4.1. Specific Inputs 536 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 537 Representation = 2B060105 02030603 539 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 541 7.4.2. Outputs 543 key-material: Length = 24 bytes, Hex Representation = 544 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 546 key: Length = 32 bytes, Hex Representation = 547 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 549 8. Security Considerations 551 This document describes negotiation of checksum types, key derivation 552 functions and other cryptographic functions. If a given negotiation 553 is unauthenticated, care must be taken to accept only secure values; 554 to do otherwise allows an active attacker to perform a downgrade 555 attack. 557 9. Acknowledgements 559 Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed 560 the document and provided suggestions for improvements. 562 10. IANA Considerations 564 IANA is requested to update the following registrations in the 565 Kerberos Pre-authentication and Typed Data Registry created by 566 section 7.1 of RFC 6113 to refer to this specification. These values 567 were reserved for this specification in the initial registrations. 569 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 570 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 572 11. References 574 11.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, 579 . 581 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 582 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 583 2005, . 585 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 586 Kerberos Network Authentication Service (V5)", RFC 4120, 587 DOI 10.17487/RFC4120, July 2005, 588 . 590 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 591 Authentication in Kerberos (PKINIT)", RFC 4556, 592 DOI 10.17487/RFC4556, June 2006, 593 . 595 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 596 Housley, R., and W. Polk, "Internet X.509 Public Key 597 Infrastructure Certificate and Certificate Revocation List 598 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 599 . 601 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 602 RFC 5652, DOI 10.17487/RFC5652, September 2009, 603 . 605 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 606 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 607 DOI 10.17487/RFC6234, May 2011, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [SP80056A] 615 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 616 Davis, "Recommendation for Pair-Wise Key Establishment 617 Schemes Using Discrete Logarithm Cryptography", April 618 2018. 620 [SP80056C] 621 Barker, E., Chen, L., and R. Davis, "Recommendation for 622 Key-Derivation Methods in Key-Establishment Schemes", 623 April 2018. 625 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 626 8824-1:2002, Information technology - Abstract Syntax 627 Notation One (ASN.1): Specification of basic notation", 628 November 2008. 630 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 631 8825-1:2002, Information technology - ASN.1 encoding 632 Rules: Specification of Basic Encoding Rules (BER), 633 Canonical Encoding Rules (CER) and Distinguished Encoding 634 Rules (DER)", November 2008. 636 11.2. Informative References 638 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 639 DOI 10.17487/RFC1321, April 1992, 640 . 642 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 643 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 644 RFC 3766, DOI 10.17487/RFC3766, April 2004, 645 . 647 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 648 RFC 6150, DOI 10.17487/RFC6150, March 2011, 649 . 651 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 652 Considerations for the SHA-0 and SHA-1 Message-Digest 653 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 654 . 656 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 657 Agility and Selecting Mandatory-to-Implement Algorithms", 658 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 659 . 661 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 662 "Cryptanalysis of Hash functions MD4 and RIPEMD", August 663 2004. 665 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 666 Industry: Agreement of Symmetric Keys Using Discrete 667 Logarithm Cryptography", 2003. 669 Appendix A. PKINIT ASN.1 Module 671 KerberosV5-PK-INIT-Agility-SPEC { 672 iso(1) identified-organization(3) dod(6) internet(1) 673 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 674 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 676 IMPORTS 677 AlgorithmIdentifier, SubjectPublicKeyInfo 678 FROM PKIX1Explicit88 { iso (1) 679 identified-organization (3) dod (6) internet (1) 680 security (5) mechanisms (5) pkix (7) id-mod (0) 681 id-pkix1-explicit (18) } 682 -- As defined in RFC 5280. 684 Ticket, Int32, Realm, EncryptionKey, Checksum 685 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 686 dod(6) internet(1) security(5) kerberosV5(2) 687 modules(4) krb5spec2(2) } 688 -- as defined in RFC 4120. 690 PKAuthenticator, DHNonce, id-pkinit 691 FROM KerberosV5-PK-INIT-SPEC { 692 iso(1) identified-organization(3) dod(6) internet(1) 693 security(5) kerberosV5(2) modules(4) pkinit(5) }; 694 -- as defined in RFC 4556. 696 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 697 -- PKINIT KDFs 699 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 700 ::= { id-pkinit-kdf sha1(1) } 701 -- SP800-56A ASN.1 structured hash-based KDF using SHA-1 703 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 704 ::= { id-pkinit-kdf sha256(2) } 705 -- SP800-56A ASN.1 structured hash-based KDF using SHA-256 707 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 708 ::= { id-pkinit-kdf sha512(3) } 709 -- SP800-56A ASN.1 structured hash-based KDF using SHA-512 711 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 712 ::= { id-pkinit-kdf sha384(4) } 713 -- SP800-56A ASN.1 structured hash-based KDF using SHA-384 715 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 716 AlgorithmIdentifier 717 -- Contains the list of CMS algorithm [RFC5652] 718 -- identifiers that identify the digest algorithms 719 -- acceptable by the KDC for signing CMS data in 720 -- the order of decreasing preference. 722 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 723 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 724 -- Contains the list of CMS algorithm [RFC5652] 725 -- identifiers that identify the digest algorithms 726 -- that are used by the CA to sign the client's 727 -- X.509 certificate and acceptable by the KDC in 728 -- the process of validating the client's X.509 729 -- certificate, in the order of decreasing 730 -- preference. 731 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 732 -- This identifies the digest algorithm that was 733 -- used to sign the client's X.509 certificate and 734 -- has been rejected by the KDC in the process of 735 -- validating the client's X.509 certificate 736 -- [RFC5280]. 737 ... 738 } 740 OtherInfo ::= SEQUENCE { 741 algorithmID AlgorithmIdentifier, 742 partyUInfo [0] OCTET STRING, 743 partyVInfo [1] OCTET STRING, 744 suppPubInfo [2] OCTET STRING OPTIONAL, 745 suppPrivInfo [3] OCTET STRING OPTIONAL 746 } 748 PkinitSuppPubInfo ::= SEQUENCE { 749 enctype [0] Int32, 750 -- The enctype of the AS reply key. 751 as-REQ [1] OCTET STRING, 752 -- The DER encoding of the AS-REQ [RFC4120] from the 753 -- client. 754 pk-as-rep [2] OCTET STRING, 755 -- The DER encoding of the PA-PK-AS-REP [RFC4556] in the 756 -- KDC reply. 757 ... 758 } 760 AuthPack ::= SEQUENCE { 761 pkAuthenticator [0] PKAuthenticator, 762 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 763 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 764 OPTIONAL, 765 clientDHNonce [3] DHNonce OPTIONAL, 766 ..., 767 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 768 -- Contains an unordered set of KDFs supported by the 769 -- client. 770 ... 771 } 773 KDFAlgorithmId ::= SEQUENCE { 774 kdf-id [0] OBJECT IDENTIFIER, 775 -- The object identifier of the KDF 776 ... 777 } 779 DHRepInfo ::= SEQUENCE { 780 dhSignedData [0] IMPLICIT OCTET STRING, 781 serverDHNonce [1] DHNonce OPTIONAL, 782 ..., 783 kdf [2] KDFAlgorithmId OPTIONAL, 784 -- The KDF picked by the KDC. 785 ... 786 } 787 END 789 Authors' Addresses 791 Love Hornquist Astrand 792 Apple, Inc 793 Cupertino, CA 794 USA 796 Email: lha@apple.com 798 Larry Zhu 799 Microsoft Corporation 800 One Microsoft Way 801 Redmond, WA 98052 802 USA 804 Email: lzhu@microsoft.com 806 Margaret Wasserman 807 Painless Security 808 356 Abbott Street 809 North Andover, MA 01845 810 USA 812 Phone: +1 781 405-7464 813 Email: mrw@painless-security.com 814 URI: http://www.painless-security.com 816 Greg Hudson (editor) 817 MIT 819 Email: ghudson@mit.edu