idnits 2.17.1 draft-ietf-krb-wg-pkinit-alg-agility-07.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 -- 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 (October 22, 2012) is 4176 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 707 -- Looks like a reference, but probably isn't: '1' on line 708 -- Looks like a reference, but probably isn't: '2' on line 710 -- Looks like a reference, but probably isn't: '3' on line 692 -- Looks like a reference, but probably isn't: '4' on line 694 == Missing Reference: 'ALG-AGILITY' is mentioned on line 547, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6194 ** 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos 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: April 25, 2013 M. Wasserman 7 Painless Security 8 October 22, 2012 10 PKINIT Algorithm Agility 11 draft-ietf-krb-wg-pkinit-alg-agility-07.txt 13 Abstract 15 This document updates PKINIT, as defined in RFC 4556, to remove 16 protocol structures tied to specific cryptographic algorithms. The 17 PKINIT key derivation function is made negotiable, the digest 18 algorithms for signing the pre-authentication data and the client's 19 X.509 certificates are made discoverable. 21 These changes provide preemptive protection against vulnerabilities 22 discovered in the future against any specific cryptographic 23 algorithm, and allow incremental deployment of newer algorithms. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 73 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . . 5 74 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . . 5 75 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . . 6 76 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 80 7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 81 7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . . 13 83 7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 84 7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . . 13 86 7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 87 7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 This document updates PKINIT [RFC4556] to remove protocol structures 100 tied to specific cryptographic algorithms. The PKINIT key derivation 101 function is made negotiable, the digest algorithms for signing the 102 pre-authentication data and the client's X.509 certificates are made 103 discoverable. 105 These changes provide preemptive protection against vulnerabilities 106 discovered in the future against any specific cryptographic 107 algorithm, and allow incremental deployment of newer algorithms. 109 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] 110 collisions generated using hand calculation [WANG04], alongside 111 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 112 SHA [RFC6234] family. These attacks and their consequences are 113 discussed in [RFC6194]. These discoveries challenged the security of 114 protocols relying on the collision resistance properties of these 115 hashes. 117 The Internet Engineering Task Force (IETF) called for actions to 118 update existing protocols to provide crypto algorithm agility so that 119 protocols support multiple cryptographic algorithms (including hash 120 functions) and provide clean, tested transition strategies between 121 algorithms. 123 This document updates PKINIT to provide crypto algorithm agility. 124 Several protocol structures used in the [RFC4556] protocol are either 125 tied to SHA-1, or do not support negotiation or discovery, but are 126 instead based on local policy. The following concerns have been 127 addressed in this update: 129 o The checksum algorithm in the authentication request is hardwired 130 to use SHA-1 [RFC6234]. 132 o The acceptable digest algorithms for signing the authentication 133 data are not discoverable. 135 o The key derivation function in Section 3.2.3 of [RFC4556] is 136 hardwired to use SHA-1. 138 o The acceptable digest algorithms for signing the client X.509 139 certificates are not discoverable. 141 To address these concerns, new key derivation functions (KDFs), 142 identified by object identifiers, are defined. The PKINIT client 143 provides a list of KDFs in the request and the Key Distribution 144 Center (KDC) picks one in the response, thus a mutually-supported KDF 145 is negotiated. 147 Furthermore, structures are defined to allow the client to discover 148 the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms 149 supported by the KDC for signing the pre-authentication data and 150 signing the client X.509 certificate. 152 2. Requirements Notation 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 3. paChecksum Agility 160 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 161 cryptographic binding between the client's pre-authentication data 162 and the corresponding Kerberos request body. This also prevents the 163 KDC body from being tampered with. SHA-1 is the only allowed 164 checksum algorithm defined in [RFC4556]. This facility relies on the 165 collision resistance properties of the SHA-1 checksum [RFC6234]. 167 When the reply key delivery mechanism is based on public key 168 encryption as described in Section 3.2.3. of [RFC4556], the 169 asChecksum in the KDC reply provides the binding between the pre- 170 authentication and the ticket request and response messages, and 171 integrity protection for the unauthenticated clear text in these 172 messages. However, if the reply key delivery mechanism is based on 173 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 174 [RFC4556], the security provided by using SHA-1 in the paChecksum is 175 weak. In this case, the new KDF selected by the KDC as described in 176 Section 6 provides the cryptographic binding and integrity 177 protection. 179 4. CMS Digest Algorithm Agility 181 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 182 as described In section 3.2.2 of [RFC4556], implementations 183 comforming to this specification can OPTIONALLY send back a list of 184 supported CMS types signifying the digest algorithms supported by the 185 KDC, in the decreasing preference order. This is accomplished by 186 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 187 error data. 189 td-cms-digest-algorithms INTEGER ::= 111 191 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 192 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 193 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 195 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 196 AlgorithmIdentifier 197 -- Contains the list of CMS algorithm [RFC5652] 198 -- identifiers that identify the digest algorithms 199 -- acceptable by the KDC for signing CMS data in 200 -- the order of decreasing preference. 202 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 203 digest algorithms supported by the KDC. 205 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 206 can facilitate trouble-shooting when none of the digest algorithms 207 supported by the client is supported by the KDC. 209 5. X.509 Certificate Signer Algorithm Agility 211 When the client's X.509 certificate is rejected and the 212 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 213 described in section 3.2.2 of [RFC4556], conforming implementations 214 can OPTIONALLY send a list of digest algorithms acceptable by the KDC 215 for use by the Certificate Authority (CA) in signing the client's 216 X.509 certificate, in the decreasing preference order. This is 217 accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data 218 element in the error data. The corresponding data contains the ASN.1 219 DER encoding of the structure TD-CERT-DIGEST-ALGORITHMS-DATA defined 220 as follows: 222 td-cert-digest-algorithms INTEGER ::= 112 224 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 225 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 226 -- Contains the list of CMS algorithm [RFC5652] 227 -- identifiers that identify the digest algorithms 228 -- that are used by the CA to sign the client's 229 -- X.509 certificate and acceptable by the KDC in 230 -- the process of validating the client's X.509 231 -- certificate, in the order of decreasing 232 -- preference. 233 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 234 -- This identifies the digest algorithm that was 235 -- used to sign the client's X.509 certificate and 236 -- has been rejected by the KDC in the process of 237 -- validating the client's X.509 certificate 238 -- [RFC5280]. 239 ... 240 } 242 The KDC fills in allowedAlgorithm field with the list of algorithm 243 [RFC5652] identifiers that identify digest algorithms that are used 244 by the CA to sign the client's X.509 certificate and acceptable by 245 the KDC in the process of validating the client's X.509 certificate, 246 in the order of decreasing preference. The rejectedAlgorithm field 247 identifies the signing algorithm for use in signing the client's 248 X.509 certificate that has been rejected by the KDC in the process of 249 validating the client's certificate [RFC5280]. 251 6. KDF agility 253 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 254 a Key Derivation Function (KDF) that derives a Kerberos protocol key 255 based on the secret value generated by the Diffie-Hellman key 256 exchange. This KDF requires the use of SHA-1 [RFC6234]. 258 New KDFs defined in this document based on [SP80056A] can be used in 259 conjunction with any hash functions. 261 A new KDF is identified by an object identifier. The following KDF 262 object identifiers are defined: 264 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } 265 -- PKINIT KDFs 266 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } 267 -- SP800 56A ASN.1 structured hash based KDF using SHA-1 268 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } 269 -- SP800 56A ASN.1 structured hash based KDF using SHA-256 270 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } 271 -- SP800 56A ASN.1 structured hash based KDF using SHA-512 272 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 } 273 -- SP800 56A ASN.1 structured hash based KDF using SHA-384 275 Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 276 KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that 277 uses SHA-1 [RFC6234] as the hash function. Similarly id-pkinit-kdf- 278 ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF 279 using SHA-256 [RFC6234] and SHA-512 [RFC6234] respectively. 281 To name the input parameters, an abbreviated version of the ASN.1 282 version of the KDF from [SP80056A] is described below, use [SP80056A] 283 for the full reference. 285 1. reps = ceiling (keydatalen/hash length (H)) 287 2. Initialize a 32-bit, big-endian bit string counter as 1. 289 3. For i = 1 to reps by 1, do the following: 291 1. Compute Hashi = H(counter || Z || OtherInfo). 293 2. Increment counter (modulo 2^32) 295 4. Set key_material = Hash1 || Hash2 || ... so that length of key is 296 K bits. 298 5. The above ASN.1 structured [SP80056A] HKDF produces a bit string 299 of length K in bits as the keying material, and then the AS reply 300 key is the output of random-to-key() [RFC3961] using that 301 returned keying material as the input. 303 The input parameters for these KDFs are provided as follows: 305 o The key data length (K) is the key-generation seed length in bits 306 [RFC3961] for the Authentication Service (AS) reply key. The 307 enctype of the AS reply key is selected according to [RFC4120]. 309 o The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1, 256 310 bits for id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah- 311 sha384 and 512 bits for id-pkinit-kdf-ah-sha512. 313 o The secret value (Z) is the shared secret value generated by the 314 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 315 padded with leading zeros such that the size of the secret value 316 in octets is the same as that of the modulus, then represented as 317 a string of octets in big-endian order. 319 o The algorithm identifier (algorithmID) input parameter is the 320 identifier of the respective KDF. For example, this is id-pkinit- 321 kdf-ah-sha1 if the KDF is the [SP80056A] ASN.1 structured HKDF 322 using SHA-1 as the hash. 324 o The initiator identifier (partyUInfo) contains the ASN.1 DER 325 encoding of the KRB5PrincipalName [RFC4556] that identifies the 326 client as specified in the AS-REQ [RFC4120] in the request. 328 o The recipient identifier (partyVInfo) contains the ASN.1 DER 329 encoding of the KRB5PrincipalName [RFC4556] that identifies the 330 TGS as specified in the AS-REQ [RFC4120] in the request. 332 o The supplemental public information (suppPubInfo) is the ASN.1 DER 333 encoding of the structure PkinitSuppPubInfo as defined later in 334 this section. 336 o The supplemental private information (suppPrivInfo) is absent. 338 o The maximum hash input length is 2^64 in bits. 340 The structure for OtherInfo is defined as follows: 342 OtherInfo ::= SEQUENCE { 343 algorithmID AlgorithmIdentifier, 344 partyUInfo [0] OCTET STRING, 345 partyVInfo [1] OCTET STRING, 346 suppPubInfo [2] OCTET STRING OPTIONAL, 347 suppPrivInfo [3] OCTET STRING OPTIONAL 348 } 350 The structure PkinitSuppPubInfo is defined as follows: 352 PkinitSuppPubInfo ::= SEQUENCE { 353 enctype [0] Int32, 354 -- The enctype of the AS reply key 355 as-REQ [1] OCTET STRING, 356 -- This contains the AS-REQ in the request. 357 pk-as-rep [2] OCTET STRING, 358 -- Contains the DER encoding of the type 359 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 360 ... 361 } 363 The PkinitSuppPubInfo structure contains mutually-known public 364 information specific to the authentication exchange. The enctype 365 field is the enctype of the AS reply key as selected according to 366 [RFC4120]. The as-REQ field contains the DER encoding of the type 367 AS-REQ [RFC4120] in the request sent from the client to the KDC. 368 Note that the as-REQ field does not include the wrapping 4 octet 369 length field when TCP is used. The pk-as-rep field contains the DER 370 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 371 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 372 authentication data and the corresponding ticket request and 373 response, thus addressing the concerns described in Section 3. 375 The KDF is negotiated between the client and the KDC. The client 376 sends an unordered set of supported KDFs in the request, and the KDC 377 picks one from the set in the reply. 379 To acomplish this, the AuthPack structure in [RFC4556] is extended as 380 follows: 382 AuthPack ::= SEQUENCE { 383 pkAuthenticator [0] PKAuthenticator, 384 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 385 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 386 OPTIONAL, 387 clientDHNonce [3] DHNonce OPTIONAL, 388 ..., 389 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 390 -- Contains an unordered set of KDFs supported by the 391 -- client. 392 ... 393 } 395 KDFAlgorithmId ::= SEQUENCE { 396 kdf-id [0] OBJECT IDENTIFIER, 397 -- The object identifier of the KDF 398 ... 400 } 402 The new field supportedKDFs contains an unordered set of KDFs 403 supported by the client. 405 The KDFAlgorithmId structure contains an object identifier that 406 identifies a KDF. The algorithm of the KDF and its parameters are 407 defined by the corresponding specification of that KDF. 409 The DHRepInfo structure in [RFC4556] is extended as follows: 411 DHRepInfo ::= SEQUENCE { 412 dhSignedData [0] IMPLICIT OCTET STRING, 413 serverDHNonce [1] DHNonce OPTIONAL, 414 ..., 415 kdf [2] KDFAlgorithmId OPTIONAL, 416 -- The KDF picked by the KDC. 417 ... 418 } 420 The new field kdf in the extended DHRepInfo structure identifies the 421 KDF picked by the KDC. This kdf field MUST be filled by the 422 comforming KDC if the supportedKDFs field is present in the request, 423 and it MUST be one of the KDFs supported by the client as indicated 424 in the request. Which KDF is chosen is a matter of the local policy 425 on the KDC. 427 If the supportedKDFs field is not present in the request, the kdf 428 field in the reply MUST be absent. 430 If the client fills the supportedKDFs field in the request, but the 431 kdf field in the reply is not present, the client can deduce that the 432 KDC is not updated to conform with this specification. In that case, 433 it is a matter of local policy on the client whether to reject the 434 reply when the kdf field is absent in the reply. 436 Implementations comforming to this specification MUST support id- 437 pkinit-kdf-ah-sha256. 439 This document introduces the following new PKINIT error code: 441 o KDC_ERR_NO_ACCEPTABLE_KDF 82 443 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF 444 (82) will be returned.. 446 7. Test vectors 448 This section contains test vectors for the KDF defined above. 450 7.1. Common Inputs 452 Z: Length = 256 bytes, Hex Representation = (All Zeros) 453 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 454 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 455 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 456 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 457 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 458 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 459 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 460 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 462 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 464 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 466 as-req: Length = 10 bytes, Hex Representation = 467 AAAAAAAA AAAAAAAA AAAA 469 pk-as-rep: Length = 9 bytes, Hex Representation = 470 BBBBBBBB BBBBBBBB BB 472 ticket: Length = 55 bytes, Hex Representation = 473 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 474 036C6861 A311300F A0030201 12A20804 0668656A 68656A 476 7.2. Test Vector for SHA-1, enctype 18 478 7.2.1. Specific Inputs 480 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 481 Representation = 2B060105 02030601 483 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 484 Representation = 18 486 7.2.2. Outputs 487 key-material: Length = 32 bytes, Hex Representation = 488 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 490 key: Length = 32 bytes, Hex Representation = 491 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 493 7.3. Test Vector for SHA-256, enctype 495 7.3.1. Specific Inputs 497 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 498 Representation = 2B060105 02030602 500 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 501 Representation = 18 503 7.3.2. Outputs 505 key-material: Length = 32 bytes, Hex Representation = 506 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 508 key: Length = 32 bytes, Hex Representation = 509 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 511 7.4. Test Vector for SHA-512, enctype 513 7.4.1. Specific Inputs 515 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 516 Representation = 2B060105 02030603 518 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 520 7.4.2. Outputs 522 key-material: Length = 24 bytes, Hex Representation = 523 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 525 key: Length = 32 bytes, Hex Representation = 526 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 528 8. Security Considerations 530 This document describes negotiation of checksum types, key derivation 531 functions and other cryptographic functions. If negotiation is done 532 unauthenticated, care MUST be taken to accept only acceptable values. 534 9. Acknowledgements 536 Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed 537 the document and provided suggestions for improvements. 539 10. IANA Considerations 541 IANA is requested to update the following registrations in the 542 Kerberos Pre-authentication and Typed Data Registry created by 543 section 7.1 of RFC 6113 to refer to this specification. These values 544 were reserved for this specification in the initial registrations. 546 TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] 547 TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] 549 11. References 551 11.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 557 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 558 RFC 3766, April 2004. 560 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 561 Kerberos 5", RFC 3961, February 2005. 563 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 564 Kerberos Network Authentication Service (V5)", RFC 4120, 565 July 2005. 567 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 568 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 570 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 571 Housley, R., and W. Polk, "Internet X.509 Public Key 572 Infrastructure Certificate and Certificate Revocation List 573 (CRL) Profile", RFC 5280, May 2008. 575 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 576 RFC 5652, September 2009. 578 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 579 Considerations for the SHA-0 and SHA-1 Message-Digest 580 Algorithms", RFC 6194, March 2011. 582 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 583 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 585 [SP80056A] 586 Barker, E., Don, D., and M. Smid, "Recommendation for 587 Pair-Wise Key Establishment Schemes Using Discrete 588 Logarithm Cryptography", March 2006. 590 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 591 1:2002, Information technology - Abstract Syntax Notation 592 One (ASN.1): Specification of basic notation". 594 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 595 1:2002, Information technology - ASN.1 encoding Rules: 596 Specification of Basic Encoding Rules (BER), Canonical 597 Encoding Rules (CER) and Distinguished Encoding Rules 598 (DER)". 600 11.2. Informative References 602 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 603 April 1992. 605 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 606 RFC 6150, March 2011. 608 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 609 "Cryptanalysis of Hash functions MD4 and RIPEMD", 610 August 2004. 612 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 613 Industry: Agreement of Symmetric Keys Using Discrete 614 Logarithm Cryptography", 2003. 616 Appendix A. PKINIT ASN.1 Module 618 KerberosV5-PK-INIT-Agility-SPEC { 619 iso(1) identified-organization(3) dod(6) internet(1) 620 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 621 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 623 IMPORTS 624 AlgorithmIdentifier, SubjectPublicKeyInfo 625 FROM PKIX1Explicit88 { iso (1) 626 identified-organization (3) dod (6) internet (1) 627 security (5) mechanisms (5) pkix (7) id-mod (0) 628 id-pkix1-explicit (18) } 629 -- As defined in RFC 5280. 631 Ticket, Int32, Realm, EncryptionKey, Checksum 632 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 633 dod(6) internet(1) security(5) kerberosV5(2) 634 modules(4) krb5spec2(2) } 635 -- as defined in RFC 4120. 637 PKAuthenticator, DHNonce 638 FROM KerberosV5-PK-INIT-SPEC { 639 iso(1) identified-organization(3) dod(6) internet(1) 640 security(5) kerberosV5(2) modules(4) pkinit(5) }; 641 -- as defined in RFC 4556. 643 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 644 AlgorithmIdentifier 645 -- Contains the list of CMS algorithm [RFC5652] 646 -- identifiers that identify the digest algorithms 647 -- acceptable by the KDC for signing CMS data in 648 -- the order of decreasing preference. 650 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 651 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 652 -- Contains the list of CMS algorithm [RFC5652] 653 -- identifiers that identify the digest algorithms 654 -- that are used by the CA to sign the client's 655 -- X.509 certificate and acceptable by the KDC in 656 -- the process of validating the client's X.509 657 -- certificate, in the order of decreasing 658 -- preference. 659 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 660 -- This identifies the digest algorithm that was 661 -- used to sign the client's X.509 certificate and 662 -- has been rejected by the KDC in the process of 663 -- validating the client's X.509 certificate 664 -- [RFC5280]. 665 ... 666 } 668 OtherInfo ::= SEQUENCE { 669 algorithmID AlgorithmIdentifier, 670 partyUInfo [0] OCTET STRING, 671 partyVInfo [1] OCTET STRING, 672 suppPubInfo [2] OCTET STRING OPTIONAL, 673 suppPrivInfo [3] OCTET STRING OPTIONAL 674 } 676 PkinitSuppPubInfo ::= SEQUENCE { 677 enctype [0] Int32, 678 -- The enctype of the AS reply key. 679 as-REQ [1] OCTET STRING, 680 -- This contains the AS-REQ in the request. 681 pk-as-rep [2] OCTET STRING, 682 -- Contains the DER encoding of the type 683 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 684 ... 685 } 687 AuthPack ::= SEQUENCE { 688 pkAuthenticator [0] PKAuthenticator, 689 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 690 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 691 OPTIONAL, 692 clientDHNonce [3] DHNonce OPTIONAL, 693 ..., 694 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 695 -- Contains an unordered set of KDFs supported by the 696 -- client. 697 ... 698 } 700 KDFAlgorithmId ::= SEQUENCE { 701 kdf-id [0] OBJECT IDENTIFIER, 702 -- The object identifier of the KDF 703 ... 704 } 706 DHRepInfo ::= SEQUENCE { 707 dhSignedData [0] IMPLICIT OCTET STRING, 708 serverDHNonce [1] DHNonce OPTIONAL, 709 ..., 710 kdf [2] KDFAlgorithmId OPTIONAL, 711 -- The KDF picked by the KDC. 712 ... 713 } 714 END 716 Authors' Addresses 718 Love Hornquist Astrand 719 Apple, Inc 720 Cupertino, CA 721 USA 723 Email: lha@apple.com 725 Larry Zhu 726 Microsoft Corporation 727 One Microsoft Way 728 Redmond, WA 98052 729 USA 731 Email: lzhu@microsoft.com 733 Margaret Wasserman 734 Painless Security 735 356 Abbott Street 736 North Andover, MA 01845 737 USA 739 Phone: +1 781 405-7464 740 Email: mrw@painless-security.com 741 URI: http://www.painless-security.com