idnits 2.17.1 draft-ietf-kitten-pkinit-alg-agility-03.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 (November 5, 2018) is 1998 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 754 -- Looks like a reference, but probably isn't: '1' on line 755 -- Looks like a reference, but probably isn't: '2' on line 757 -- Looks like a reference, but probably isn't: '3' on line 739 -- Looks like a reference, but probably isn't: '4' on line 741 == Missing Reference: 'ALG-AGILITY' is mentioned on line 560, 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. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 1 error (**), 0 flaws (~~), 2 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 Microsoft Corporation 6 Expires: May 9, 2019 M. Wasserman 7 Painless Security 8 G. Hudson, Ed. 9 MIT 10 November 5, 2018 12 PKINIT Algorithm Agility 13 draft-ietf-kitten-pkinit-alg-agility-03 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, 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 May 9, 2019. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . 12 85 7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 86 7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 87 7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 12 88 7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 89 7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 11.2. Informative References . . . . . . . . . . . . . . . . . 15 96 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. 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 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", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. paChecksum Agility 162 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 163 cryptographic binding between the client's pre-authentication data 164 and the corresponding Kerberos request body. This also prevents the 165 KDC body from being tampered with. SHA-1 is the only allowed 166 checksum algorithm defined in [RFC4556]. This facility relies on the 167 collision resistance properties of the SHA-1 checksum [RFC6234]. 169 When the reply key delivery mechanism is based on public key 170 encryption as described in Section 3.2.3. of [RFC4556], the 171 asChecksum in the KDC reply provides the binding between the pre- 172 authentication and the ticket request and response messages, and 173 integrity protection for the unauthenticated clear text in these 174 messages. However, if the reply key delivery mechanism is based on 175 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 176 [RFC4556], the security provided by using SHA-1 in the paChecksum is 177 weak. In this case, the new KDF selected by the KDC as described in 178 Section 6 provides the cryptographic binding and integrity 179 protection. 181 4. CMS Digest Algorithm Agility 183 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 184 as described In section 3.2.2 of [RFC4556], implementations 185 comforming to this specification can OPTIONALLY send back a list of 186 supported CMS types signifying the digest algorithms supported by the 187 KDC, in the decreasing preference order. This is accomplished by 188 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 189 error data. 191 td-cms-digest-algorithms INTEGER ::= 111 193 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 194 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 195 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 197 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 198 AlgorithmIdentifier 199 -- Contains the list of CMS algorithm [RFC5652] 200 -- identifiers that identify the digest algorithms 201 -- acceptable by the KDC for signing CMS data in 202 -- the order of decreasing preference. 204 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 205 digest algorithms supported by the KDC. 207 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 208 can facilitate trouble-shooting when none of the digest algorithms 209 supported by the client is supported by the KDC. 211 5. X.509 Certificate Signer Algorithm Agility 213 When the client's X.509 certificate is rejected and the 214 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 215 described in section 3.2.2 of [RFC4556], conforming implementations 216 can OPTIONALLY send a list of digest algorithms acceptable by the KDC 217 for use by the Certificate Authority (CA) in signing the client's 218 X.509 certificate, in the decreasing preference order. This is 219 accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data 220 element in the error data. The corresponding data contains the ASN.1 221 DER encoding of the structure TD-CERT-DIGEST-ALGORITHMS-DATA defined 222 as follows: 224 td-cert-digest-algorithms INTEGER ::= 112 226 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 227 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 228 -- Contains the list of CMS algorithm [RFC5652] 229 -- identifiers that identify the digest algorithms 230 -- that are used by the CA to sign the client's 231 -- X.509 certificate and acceptable by the KDC in 232 -- the process of validating the client's X.509 233 -- certificate, in the order of decreasing 234 -- preference. 235 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 236 -- This identifies the digest algorithm that was 237 -- used to sign the client's X.509 certificate and 238 -- has been rejected by the KDC in the process of 239 -- validating the client's X.509 certificate 240 -- [RFC5280]. 241 ... 242 } 244 The KDC fills in allowedAlgorithm field with the list of algorithm 245 [RFC5652] identifiers that identify digest algorithms that are used 246 by the CA to sign the client's X.509 certificate and acceptable by 247 the KDC in the process of validating the client's X.509 certificate, 248 in the order of decreasing preference. The rejectedAlgorithm field 249 identifies the signing algorithm for use in signing the client's 250 X.509 certificate that has been rejected by the KDC in the process of 251 validating the client's certificate [RFC5280]. 253 6. KDF agility 255 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 256 a Key Derivation Function (KDF) that derives a Kerberos protocol key 257 based on the secret value generated by the Diffie-Hellman key 258 exchange. This KDF requires the use of SHA-1 [RFC6234]. 260 New KDFs defined in this document based on [SP80056A] can be used in 261 conjunction with any hash functions. 263 A new KDF is identified by an object identifier. The following KDF 264 object identifiers are defined: 266 id-pkinit OBJECT IDENTIFIER ::= 267 { iso(1) identified-organization(3) dod(6) internet(1) 268 security(5) kerberosv5(2) pkinit (3) } 269 -- Defined in RFC 4556 and quoted here for the reader. 271 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 272 -- PKINIT KDFs 274 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 275 ::= { id-pkinit-kdf sha1(1) } 276 -- SP800-56A ASN.1 structured hash based KDF using SHA-1 278 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 279 ::= { id-pkinit-kdf sha256(2) } 280 -- SP800-56A ASN.1 structured hash based KDF using SHA-256 282 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 283 ::= { id-pkinit-kdf sha512(3) } 284 -- SP800-56A ASN.1 structured hash based KDF using SHA-512 286 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 287 ::= { id-pkinit-kdf sha384(4) } 288 -- SP800-56A ASN.1 structured hash based KDF using SHA-384 290 Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 291 KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that 292 uses SHA-1 [RFC6234] as the hash function. Similarly id-pkinit-kdf- 293 ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF 294 using SHA-256 [RFC6234] and SHA-512 [RFC6234] respectively. 296 To name the input parameters, an abbreviated version of the ASN.1 297 version of the KDF from [SP80056A] is described below, use [SP80056A] 298 for the full reference. 300 1. reps = ceiling (keydatalen/hash length (H)) 302 2. Initialize a 32-bit, big-endian bit string counter as 1. 304 3. For i = 1 to reps by 1, do the following: 306 1. Compute Hashi = H(counter || Z || OtherInfo). 308 2. Increment counter (modulo 2^32) 310 4. Set key_material = Hash1 || Hash2 || ... so that length of key is 311 K bits. 313 5. The above ASN.1 structured [SP80056A] HKDF produces a bit string 314 of length K in bits as the keying material, and then the AS reply 315 key is the output of random-to-key() [RFC3961] using that 316 returned keying material as the input. 318 The input parameters for these KDFs are provided as follows: 320 o The key data length (K) is the key-generation seed length in bits 321 [RFC3961] for the Authentication Service (AS) reply key. The 322 enctype of the AS reply key is selected according to [RFC4120]. 324 o The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1, 256 325 bits for id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah- 326 sha384 and 512 bits for id-pkinit-kdf-ah-sha512. 328 o The secret value (Z) is the shared secret value generated by the 329 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 330 padded with leading zeros such that the size of the secret value 331 in octets is the same as that of the modulus, then represented as 332 a string of octets in big-endian order. 334 o The algorithm identifier (algorithmID) input parameter is the 335 identifier of the respective KDF. For example, this is id-pkinit- 336 kdf-ah-sha1 if the KDF is the [SP80056A] ASN.1 structured HKDF 337 using SHA-1 as the hash. 339 o The initiator identifier (partyUInfo) contains the ASN.1 DER 340 encoding of the KRB5PrincipalName [RFC4556] that identifies the 341 client as specified in the AS-REQ [RFC4120] in the request. 343 o The recipient identifier (partyVInfo) contains the ASN.1 DER 344 encoding of the KRB5PrincipalName [RFC4556] that identifies the 345 TGS as specified in the AS-REQ [RFC4120] in the request. 347 o The supplemental public information (suppPubInfo) is the ASN.1 DER 348 encoding of the structure PkinitSuppPubInfo as defined later in 349 this section. 351 o The supplemental private information (suppPrivInfo) is absent. 353 o The maximum hash input length is 2^64 in bits. 355 The structure for OtherInfo is defined as follows: 357 OtherInfo ::= SEQUENCE { 358 algorithmID AlgorithmIdentifier, 359 partyUInfo [0] OCTET STRING, 360 partyVInfo [1] OCTET STRING, 361 suppPubInfo [2] OCTET STRING OPTIONAL, 362 suppPrivInfo [3] OCTET STRING OPTIONAL 363 } 365 The structure PkinitSuppPubInfo is defined as follows: 367 PkinitSuppPubInfo ::= SEQUENCE { 368 enctype [0] Int32, 369 -- The enctype of the AS reply key 370 as-REQ [1] OCTET STRING, 371 -- This contains the AS-REQ in the request. 372 pk-as-rep [2] OCTET STRING, 373 -- Contains the DER encoding of the type 374 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 375 ... 376 } 378 The PkinitSuppPubInfo structure contains mutually-known public 379 information specific to the authentication exchange. The enctype 380 field is the enctype of the AS reply key as selected according to 381 [RFC4120]. The as-REQ field contains the DER encoding of the type 382 AS-REQ [RFC4120] in the request sent from the client to the KDC. 383 Note that the as-REQ field does not include the wrapping 4 octet 384 length field when TCP is used. The pk-as-rep field contains the DER 385 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 386 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 387 authentication data and the corresponding ticket request and 388 response, thus addressing the concerns described in Section 3. 390 The KDF is negotiated between the client and the KDC. The client 391 sends an unordered set of supported KDFs in the request, and the KDC 392 picks one from the set in the reply. 394 To acomplish this, the AuthPack structure in [RFC4556] is extended as 395 follows: 397 AuthPack ::= SEQUENCE { 398 pkAuthenticator [0] PKAuthenticator, 399 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 400 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 401 OPTIONAL, 402 clientDHNonce [3] DHNonce OPTIONAL, 403 ..., 404 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 405 -- Contains an unordered set of KDFs supported by the 406 -- client. 407 ... 408 } 410 KDFAlgorithmId ::= SEQUENCE { 411 kdf-id [0] OBJECT IDENTIFIER, 412 -- The object identifier of the KDF 413 ... 414 } 416 The new field supportedKDFs contains an unordered set of KDFs 417 supported by the client. 419 The KDFAlgorithmId structure contains an object identifier that 420 identifies a KDF. The algorithm of the KDF and its parameters are 421 defined by the corresponding specification of that KDF. 423 The DHRepInfo structure in [RFC4556] is extended as follows: 425 DHRepInfo ::= SEQUENCE { 426 dhSignedData [0] IMPLICIT OCTET STRING, 427 serverDHNonce [1] DHNonce OPTIONAL, 428 ..., 429 kdf [2] KDFAlgorithmId OPTIONAL, 430 -- The KDF picked by the KDC. 431 ... 432 } 434 The new field kdf in the extended DHRepInfo structure identifies the 435 KDF picked by the KDC. This kdf field MUST be filled by the 436 comforming KDC if the supportedKDFs field is present in the request, 437 and it MUST be one of the KDFs supported by the client as indicated 438 in the request. Which KDF is chosen is a matter of the local policy 439 on the KDC. 441 If the supportedKDFs field is not present in the request, the kdf 442 field in the reply MUST be absent. 444 If the client fills the supportedKDFs field in the request, but the 445 kdf field in the reply is not present, the client can deduce that the 446 KDC is not updated to conform with this specification. In that case, 447 it is a matter of local policy on the client whether to reject the 448 reply when the kdf field is absent in the reply. 450 Implementations comforming to this specification MUST support id- 451 pkinit-kdf-ah-sha256. 453 This document introduces the following new PKINIT error code: 455 o KDC_ERR_NO_ACCEPTABLE_KDF 100 457 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF 458 (100) will be returned.. 460 7. Test vectors 462 This section contains test vectors for the KDF defined above. 464 7.1. Common Inputs 466 Z: Length = 256 bytes, Hex Representation = (All Zeros) 467 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 468 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 469 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 470 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 471 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 472 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 473 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 474 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 476 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 478 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 480 as-req: Length = 10 bytes, Hex Representation = 481 AAAAAAAA AAAAAAAA AAAA 483 pk-as-rep: Length = 9 bytes, Hex Representation = 484 BBBBBBBB BBBBBBBB BB 486 ticket: Length = 55 bytes, Hex Representation = 487 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 488 036C6861 A311300F A0030201 12A20804 0668656A 68656A 489 7.2. Test Vector for SHA-1, enctype 18 491 7.2.1. Specific Inputs 493 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 494 Representation = 2B060105 02030601 496 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 497 Representation = 18 499 7.2.2. Outputs 501 key-material: Length = 32 bytes, Hex Representation = 502 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 504 key: Length = 32 bytes, Hex Representation = 505 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 507 7.3. Test Vector for SHA-256, enctype 509 7.3.1. Specific Inputs 511 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 512 Representation = 2B060105 02030602 514 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 515 Representation = 18 517 7.3.2. Outputs 519 key-material: Length = 32 bytes, Hex Representation = 520 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 522 key: Length = 32 bytes, Hex Representation = 523 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 525 7.4. Test Vector for SHA-512, enctype 527 7.4.1. Specific Inputs 528 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 529 Representation = 2B060105 02030603 531 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 533 7.4.2. Outputs 535 key-material: Length = 24 bytes, Hex Representation = 536 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 538 key: Length = 32 bytes, Hex Representation = 539 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 541 8. Security Considerations 543 This document describes negotiation of checksum types, key derivation 544 functions and other cryptographic functions. If negotiation is done 545 unauthenticated, care MUST be taken to accept only acceptable values. 547 9. Acknowledgements 549 Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed 550 the document and provided suggestions for improvements. 552 10. IANA Considerations 554 IANA is requested to update the following registrations in the 555 Kerberos Pre-authentication and Typed Data Registry created by 556 section 7.1 of RFC 6113 to refer to this specification. These values 557 were reserved for this specification in the initial registrations. 559 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 560 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 562 11. References 564 11.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 572 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 573 2005, . 575 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 576 Kerberos Network Authentication Service (V5)", RFC 4120, 577 DOI 10.17487/RFC4120, July 2005, 578 . 580 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 581 Authentication in Kerberos (PKINIT)", RFC 4556, 582 DOI 10.17487/RFC4556, June 2006, 583 . 585 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 586 Housley, R., and W. Polk, "Internet X.509 Public Key 587 Infrastructure Certificate and Certificate Revocation List 588 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 589 . 591 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 592 RFC 5652, DOI 10.17487/RFC5652, September 2009, 593 . 595 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 596 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 597 DOI 10.17487/RFC6234, May 2011, 598 . 600 [SP80056A] 601 Barker, E., Don, D., and M. Smid, "Recommendation for 602 Pair-Wise Key Establishment Schemes Using Discrete 603 Logarithm Cryptography", March 2006. 605 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 606 8824-1:2002, Information technology - Abstract Syntax 607 Notation One (ASN.1): Specification of basic notation", 608 November 2008. 610 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 611 8825-1:2002, Information technology - ASN.1 encoding 612 Rules: Specification of Basic Encoding Rules (BER), 613 Canonical Encoding Rules (CER) and Distinguished Encoding 614 Rules (DER)", November 2008. 616 11.2. Informative References 618 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 619 DOI 10.17487/RFC1321, April 1992, 620 . 622 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 623 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 624 RFC 3766, DOI 10.17487/RFC3766, April 2004, 625 . 627 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 628 RFC 6150, DOI 10.17487/RFC6150, March 2011, 629 . 631 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 632 Considerations for the SHA-0 and SHA-1 Message-Digest 633 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 634 . 636 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 637 "Cryptanalysis of Hash functions MD4 and RIPEMD", August 638 2004. 640 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 641 Industry: Agreement of Symmetric Keys Using Discrete 642 Logarithm Cryptography", 2003. 644 Appendix A. PKINIT ASN.1 Module 646 KerberosV5-PK-INIT-Agility-SPEC { 647 iso(1) identified-organization(3) dod(6) internet(1) 648 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 649 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 651 IMPORTS 652 AlgorithmIdentifier, SubjectPublicKeyInfo 653 FROM PKIX1Explicit88 { iso (1) 654 identified-organization (3) dod (6) internet (1) 655 security (5) mechanisms (5) pkix (7) id-mod (0) 656 id-pkix1-explicit (18) } 657 -- As defined in RFC 5280. 659 Ticket, Int32, Realm, EncryptionKey, Checksum 660 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 661 dod(6) internet(1) security(5) kerberosV5(2) 662 modules(4) krb5spec2(2) } 663 -- as defined in RFC 4120. 665 PKAuthenticator, DHNonce, id-pkinit 666 FROM KerberosV5-PK-INIT-SPEC { 667 iso(1) identified-organization(3) dod(6) internet(1) 668 security(5) kerberosV5(2) modules(4) pkinit(5) }; 669 -- as defined in RFC 4556. 671 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } 672 -- PKINIT KDFs 674 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER 675 ::= { id-pkinit-kdf sha1(1) } 676 -- SP800-56A ASN.1 structured hash based KDF using SHA-1 678 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER 679 ::= { id-pkinit-kdf sha256(2) } 680 -- SP800-56A ASN.1 structured hash based KDF using SHA-256 682 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER 683 ::= { id-pkinit-kdf sha512(3) } 684 -- SP800-56A ASN.1 structured hash based KDF using SHA-512 686 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER 687 ::= { id-pkinit-kdf sha384(4) } 688 -- SP800-56A ASN.1 structured hash based KDF using SHA-384 690 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 691 AlgorithmIdentifier 692 -- Contains the list of CMS algorithm [RFC5652] 693 -- identifiers that identify the digest algorithms 694 -- acceptable by the KDC for signing CMS data in 695 -- the order of decreasing preference. 697 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 698 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 699 -- Contains the list of CMS algorithm [RFC5652] 700 -- identifiers that identify the digest algorithms 701 -- that are used by the CA to sign the client's 702 -- X.509 certificate and acceptable by the KDC in 703 -- the process of validating the client's X.509 704 -- certificate, in the order of decreasing 705 -- preference. 706 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 707 -- This identifies the digest algorithm that was 708 -- used to sign the client's X.509 certificate and 709 -- has been rejected by the KDC in the process of 710 -- validating the client's X.509 certificate 711 -- [RFC5280]. 712 ... 713 } 715 OtherInfo ::= SEQUENCE { 716 algorithmID AlgorithmIdentifier, 717 partyUInfo [0] OCTET STRING, 718 partyVInfo [1] OCTET STRING, 719 suppPubInfo [2] OCTET STRING OPTIONAL, 720 suppPrivInfo [3] OCTET STRING OPTIONAL 721 } 723 PkinitSuppPubInfo ::= SEQUENCE { 724 enctype [0] Int32, 725 -- The enctype of the AS reply key. 726 as-REQ [1] OCTET STRING, 727 -- This contains the AS-REQ in the request. 728 pk-as-rep [2] OCTET STRING, 729 -- Contains the DER encoding of the type 730 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 731 ... 732 } 734 AuthPack ::= SEQUENCE { 735 pkAuthenticator [0] PKAuthenticator, 736 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 737 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 738 OPTIONAL, 739 clientDHNonce [3] DHNonce OPTIONAL, 740 ..., 741 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 742 -- Contains an unordered set of KDFs supported by the 743 -- client. 744 ... 745 } 747 KDFAlgorithmId ::= SEQUENCE { 748 kdf-id [0] OBJECT IDENTIFIER, 749 -- The object identifier of the KDF 750 ... 751 } 753 DHRepInfo ::= SEQUENCE { 754 dhSignedData [0] IMPLICIT OCTET STRING, 755 serverDHNonce [1] DHNonce OPTIONAL, 756 ..., 757 kdf [2] KDFAlgorithmId OPTIONAL, 758 -- The KDF picked by the KDC. 760 ... 761 } 762 END 764 Authors' Addresses 766 Love Hornquist Astrand 767 Apple, Inc 768 Cupertino, CA 769 USA 771 Email: lha@apple.com 773 Larry Zhu 774 Microsoft Corporation 775 One Microsoft Way 776 Redmond, WA 98052 777 USA 779 Email: lzhu@microsoft.com 781 Margaret Wasserman 782 Painless Security 783 356 Abbott Street 784 North Andover, MA 01845 785 USA 787 Phone: +1 781 405-7464 788 Email: mrw@painless-security.com 789 URI: http://www.painless-security.com 791 Greg Hudson (editor) 792 MIT 794 Email: ghudson@mit.edu