idnits 2.17.1 draft-ietf-krb-wg-pkinit-alg-agility-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2012) is 4424 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 686 -- Looks like a reference, but probably isn't: '1' on line 687 -- Looks like a reference, but probably isn't: '2' on line 689 -- Looks like a reference, but probably isn't: '3' on line 671 -- Looks like a reference, but probably isn't: '4' on line 673 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Downref: Normative reference to an Informational RFC: RFC 6194 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP80056A' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 1320 (Obsoleted by RFC 6150) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Hornquist Astrand 3 Internet-Draft Apple, Inc 4 Intended status: Standards Track L. Zhu 5 Expires: September 8, 2012 Microsoft Corporation 6 M. Wasserman 7 Painless Security 8 March 2012 10 PKINIT Algorithm Agility 11 draft-ietf-krb-wg-pkinit-alg-agility-06.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 July 4, 2012. 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 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 61 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . . 4 62 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . . 4 63 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . . 5 64 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 7.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11 67 7.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 11 68 7.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 11 69 7.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . . 12 71 7.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 72 7.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . . 12 74 7.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 75 7.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 This document updates PKINIT [RFC4556] to remove protocol structures 88 tied to specific cryptographic algorithms. The PKINIT key derivation 89 function is made negotiable, the digest algorithms for signing the 90 pre-authentication data and the client's X.509 certificates are made 91 discoverable. 93 These changes provide preemptive protection against vulnerabilities 94 discovered in the future against any specific cryptographic 95 algorithm, and allow incremental deployment of newer algorithms. 97 In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320] 98 collisions generated using hand calculation [WANG04], alongside 99 attacks on later hash function designs in the MD4, MD5 [RFC1321] and 100 SHA [RFC4634] family. These attacks and their consequences are 101 discussed in [RFC6194]. These discoveries challenged the security of 102 protocols relying on the collision resistance properties of these 103 hashes. 105 The Internet Engineering Task Force (IETF) called for actions to 106 update existing protocols to provide crypto algorithm agility so that 107 protocols support multiple cryptographic algorithms (including hash 108 functions) and provide clean, tested transition strategies between 109 algorithms. 111 This document updates PKINIT to provide crypto algorithm agility. 112 Several protocol structures used in the [RFC4556] protocol are either 113 tied to SHA-1, or do not support negotiation or discovery, but are 114 instead based on local policy. The following concerns have been 115 addressed in this update: 117 o The checksum algorithm in the authentication request is hardwired 118 to use SHA-1 [RFC4634]. 120 o The acceptable digest algorithms for signing the authentication 121 data are not discoverable. 123 o The key derivation function in Section 3.2.3 of [RFC4556] is 124 hardwired to use SHA-1. 126 o The acceptable digest algorithms for signing the client X.509 127 certificates are not discoverable. 129 To address these concerns, new key derivation functions (KDFs), 130 identified by object identifiers, are defined. The PKINIT client 131 provides a list of KDFs in the request and the KDC picks one in the 132 response, thus a mutually-supported KDF is negotiated. 134 Furthermore, structures are defined to allow the client to discover 135 the Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms 136 supported by the KDC for signing the pre-authentication data and 137 signing the client X.509 certificate. 139 2. Requirements Notation 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. paChecksum Agility 147 The paChecksum defined in Section 3.2.1 of [RFC4556] provides a 148 cryptographic binding between the client's pre-authentication data 149 and the corresponding Kerberos request body. This also prevents the 150 KDC body from being tampered with. SHA-1 is the only allowed 151 checksum algorithm defined in [RFC4556]. This facility relies on the 152 collision resistance properties of the SHA-1 checksum [RFC4634]. 154 When the reply key delivery mechanism is based on public key 155 encryption as described in Section 3.2.3. of [RFC4556], the 156 asChecksum in the KDC reply provides the binding between the pre- 157 authentication and the ticket request and response messages, and 158 integrity protection for the unauthenticated clear text in these 159 messages. However, if the reply key delivery mechanism is based on 160 the Diffie-Hellman key agreement as described in Section 3.2.3.1 of 161 [RFC4556], the security provided by using SHA-1 in the paChecksum is 162 weak. In this case, the new KDF selected by the KDC as described in 163 Section 6 provides the cryptographic binding and integrity 164 protection. 166 4. CMS Digest Algorithm Agility 168 When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned 169 as described In section 3.2.2 of [RFC4556], implementations 170 comforming to this specification can OPTIONALLY send back a list of 171 supported CMS types signifying the digest algorithms supported by the 172 KDC, in the decreasing preference order. This is accomplished by 173 including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the 174 error data. 176 TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111 177 The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains 178 the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded 179 TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: 181 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 182 AlgorithmIdentifier 183 -- Contains the list of CMS algorithm [RFC3852] 184 -- identifiers that identify the digest algorithms 185 -- acceptable by the KDC for signing CMS data in 186 -- the order of decreasing preference. 188 The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy 189 digest algorithms supported by the KDC. 191 This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS 192 can facilitate trouble-shooting when none of the digest algorithms 193 supported by the client is supported by the KDC. 195 5. X.509 Certificate Signer Algorithm Agility 197 When the client's X.509 certificate is rejected and the 198 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as 199 described in section 3.2.2 of [RFC4556], conforming implementations 200 can OPTIONALLY send a list of digest algorithms acceptable by the KDC 201 for use by the CA in signing the client's X.509 certificate, in the 202 decreasing preference order. This is accomplished by including a 203 TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The 204 corresponding data contains the ASN.1 DER encoding of the structure 205 TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: 207 TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112 209 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 210 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 211 -- Contains the list of CMS algorithm [RFC3852] 212 -- identifiers that identify the digest algorithms 213 -- that are used by the CA to sign the client's 214 -- X.509 certificate and acceptable by the KDC in 215 -- the process of validating the client's X.509 216 -- certificate, in the order of decreasing 217 -- preference. 218 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 219 -- This identifies the digest algorithm that was 220 -- used to sign the client's X.509 certificate and 221 -- has been rejected by the KDC in the process of 222 -- validating the client's X.509 certificate 223 -- [RFC3280]. 224 ... 225 } 227 The KDC fills in allowedAlgorithm field with the list of algorithm 228 [RFC3852] identifiers that identify digest algorithms that are used 229 by the CA to sign the client's X.509 certificate and acceptable by 230 the KDC in the process of validating the client's X.509 certificate, 231 in the order of decreasing preference. The rejectedAlgorithm field 232 identifies the signing algorithm for use in signing the client's 233 X.509 certificate that has been rejected by the KDC in the process of 234 validating the client's certificate [RFC3280]. 236 6. KDF agility 238 Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines 239 a Key Derivation Function (KDF) that derives a Kerberos protocol key 240 based on the secret value generated by the Diffie-Hellman key 241 exchange. This KDF requires the use of SHA-1 [RFC4634]. 243 New KDFs defined in this document based on [SP80056A] can be used in 244 conjunction with any hash functions. 246 A new KDF is identified by an object identifier. The following KDF 247 object identifiers are defined: 249 id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } 250 -- PKINIT KDFs 251 id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } 252 -- SP800 56A ASN.1 structured hash based KDF using SHA-1 253 id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } 254 -- SP800 56A ASN.1 structured hash based KDF using SHA-256 255 id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } 256 -- SP800 56A ASN.1 structured hash based KDF using SHA-512 257 id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 } 258 -- SP800 56A ASN.1 structured hash based KDF using SHA-384 260 Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 261 KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that 262 uses SHA-1 [RFC4634] as the hash function. Similarly id-pkinit-kdf- 263 ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF 264 using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively. 266 To name the input parameters, an abbreviated version of the ASN.1 267 version of the KDF from [SP80056A] is described below, use [SP80056A] 268 for the full reference. 270 1. reps = ceiling (keydatalen/hash length (H)) 272 2. Initialize a 32-bit, big-endian bit string counter as 1. 274 3. For i = 1 to reps by 1, do the following: 276 1. Compute Hashi = H(counter || Z || OtherInfo). 278 2. Increment counter (modulo 2^32) 280 4. Set key_material = Hash1 || Hash2 || ... so that length of key is 281 K bits. 283 5. The above ASN.1 structured [SP80056A] HKDF produces a bit string 284 of length K in bits as the keying material, and then the AS reply 285 key is the output of random-to-key() [RFC3961] using that 286 returned keying material as the input. 288 The input parameters for these KDFs are provided as follows: 290 o The key data length (K) is the key-generation seed length in bits 291 [RFC3961] for the Authentication Service (AS) reply key. The 292 enctype of the AS reply key is selected according to [RFC4120]. 294 o The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1, 256 295 bytes for id-pkinit-kdf-ah-sha256, 384 bytes for id-pkinit-kdf-ah- 296 sha384 and 512 bits for id-pkinit-kdf-ah-sha512. 298 o The secret value (Z) is the shared secret value generated by the 299 Diffie-Hellman exchange. The Diffie-Hellman shared value is first 300 padded with leading zeros such that the size of the secret value 301 in octets is the same as that of the modulus, then represented as 302 a string of octets in big-endian order. 304 o The algorithm identifier (algorithmID) input parameter is the 305 identifier of the respective KDF. For example, this is id-pkinit- 306 kdf-ah-sha1 if the KDF is the [SP80056A] ASN.1 structured HKDF 307 using SHA-1 as the hash. 309 o The initiator identifier (partyUInfo) contains the ASN.1 DER 310 encoding of the KRB5PrincipalName [RFC4556] that identifies the 311 client as specified in the AS-REQ [RFC4120] in the request. 313 o The recipient identifier (partyVInfo) contains the ASN.1 DER 314 encoding of the KRB5PrincipalName [RFC4556] that identifies the 315 TGS as specified in the AS-REQ [RFC4120] in the request. 317 o The supplemental public information (suppPubInfo) is the ASN.1 DER 318 encoding of the structure PkinitSuppPubInfo as defined later in 319 this section. 321 o The supplemental private information (suppPrivInfo) is absent. 323 o The maximum hash input length is 2^64 in bits. 325 The structure for OtherInfo is defined as follows: 327 OtherInfo ::= SEQUENCE { 328 algorithmID AlgorithmIdentifier, 329 partyUInfo [0] OCTET STRING, 330 partyVInfo [1] OCTET STRING, 331 suppPubInfo [2] OCTET STRING OPTIONAL, 332 suppPrivInfo [3] OCTET STRING OPTIONAL 333 } 335 The structure PkinitSuppPubInfo is defined as follows: 337 PkinitSuppPubInfo ::= SEQUENCE { 338 enctype [0] Int32, 339 -- The enctype of the AS reply key 340 as-REQ [1] OCTET STRING, 341 -- This contains the AS-REQ in the request. 342 pk-as-rep [2] OCTET STRING, 343 -- Contains the DER encoding of the type 344 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 345 ... 346 } 348 The PkinitSuppPubInfo structure contains mutually-known public 349 information specific to the authentication exchange. The enctype 350 field is the enctype of the AS reply key as selected according to 351 [RFC4120]. The as-REQ field contains the DER encoding of the type 352 AS-REQ [RFC4120] in the request sent from the client to the KDC. 353 Note that the as-REQ field does not include the wrapping 4 octet 354 length field when TCP is used. The pk-as-rep field contains the DER 355 encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The 356 PkinitSuppPubInfo provides a cryptographic bindings between the pre- 357 authentication data and the corresponding ticket request and 358 response, thus addressing the concerns described in Section 3. 360 The KDF is negotiated between the client and the KDC. The client 361 sends an unordered set of supported KDFs in the request, and the KDC 362 picks one from the set in the reply. 364 To acomplish this, the AuthPack structure in [RFC4556] is extended as 365 follows: 367 AuthPack ::= SEQUENCE { 368 pkAuthenticator [0] PKAuthenticator, 369 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 370 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 371 OPTIONAL, 372 clientDHNonce [3] DHNonce OPTIONAL, 373 ..., 374 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 375 -- Contains an unordered set of KDFs supported by the 376 -- client. 377 ... 378 } 380 KDFAlgorithmId ::= SEQUENCE { 381 kdf-id [0] OBJECT IDENTIFIER, 382 -- The object identifier of the KDF 383 ... 385 } 387 The new field supportedKDFs contains an unordered set of KDFs 388 supported by the client. 390 The KDFAlgorithmId structure contains an object identifier that 391 identifies a KDF. The algorithm of the KDF and its parameters are 392 defined by the corresponding specification of that KDF. 394 The DHRepInfo structure in [RFC4556] is extended as follows: 396 DHRepInfo ::= SEQUENCE { 397 dhSignedData [0] IMPLICIT OCTET STRING, 398 serverDHNonce [1] DHNonce OPTIONAL, 399 ..., 400 kdf [2] KDFAlgorithmId OPTIONAL, 401 -- The KDF picked by the KDC. 402 ... 403 } 405 The new field kdf in the extended DHRepInfo structure identifies the 406 KDF picked by the KDC. This kdf field MUST be filled by the 407 comforming KDC if the supportedKDFs field is present in the request, 408 and it MUST be one of the KDFs supported by the client as indicated 409 in the request. Which KDF is chosen is a matter of the local policy 410 on the KDC. 412 If the supportedKDFs field is not present in the request, the kdf 413 field in the reply MUST be absent. 415 If the client fills the supportedKDFs field in the request, but the 416 kdf field in the reply is not present, the client can deduce that the 417 KDC is not updated to conform with this specification. In that case, 418 it is a matter of local policy on the client whether to reject the 419 reply when the kdf field is absent in the reply. 421 Implementations comforming to this specification MUST support id- 422 pkinit-kdf-ah-sha256. 424 This document introduces the following new PKINIT error code: 426 o KDC_ERR_NO_ACCEPTABLE_KDF 82 428 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF 429 (82) will be returned.. 431 7. Test vectors 433 This section contains test vectors for the KDF defined above. 435 7.1. Common Inputs 437 Z: Length = 256 bytes, Hex Representation = (All Zeros) 438 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 439 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 440 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 441 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 442 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 443 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 444 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 445 00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000 447 client: Length = 9 bytes, ASCII Representation = lha@SU.SE 449 server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE 451 as-req: Length = 10 bytes, Hex Representation = 452 AAAAAAAA AAAAAAAA AAAA 454 pk-as-rep: Length = 9 bytes, Hex Representation = 455 BBBBBBBB BBBBBBBB BB 457 ticket: Length = 55 bytes, Hex Representation = 458 61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B 459 036C6861 A311300F A0030201 12A20804 0668656A 68656A 461 7.2. Test Vector for SHA-1, enctype 18 463 7.2.1. Specific Inputs 465 algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 466 Representation = 2B060105 02030601 468 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 469 Representation = 18 471 7.2.2. Outputs 472 key-material: Length = 32 bytes, Hex Representation = 473 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 475 key: Length = 32 bytes, Hex Representation = 476 E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD 478 7.3. Test Vector for SHA-256, enctype 480 7.3.1. Specific Inputs 482 algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 483 Representation = 2B060105 02030602 485 enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal 486 Representation = 18 488 7.3.2. Outputs 490 key-material: Length = 32 bytes, Hex Representation = 491 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 493 key: Length = 32 bytes, Hex Representation = 494 77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5 496 7.4. Test Vector for SHA-512, enctype 498 7.4.1. Specific Inputs 500 algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 501 Representation = 2B060105 02030603 503 enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16 505 7.4.2. Outputs 507 key-material: Length = 24 bytes, Hex Representation = 508 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 510 key: Length = 32 bytes, Hex Representation = 511 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 513 8. Security Considerations 515 This document describes negotiation of checksum types, key derivation 516 functions and other cryptographic functions. If negotiation is done 517 unauthenticated, care MUST be taken to accept only acceptable values. 519 9. Acknowledgements 521 Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed 522 the document and provided suggestions for improvements. 524 10. IANA Considerations 526 No IANA considerations. 528 11. References 530 11.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 536 X.509 Public Key Infrastructure Certificate and 537 Certificate Revocation List (CRL) Profile", RFC 3280, 538 April 2002. 540 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 541 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 542 RFC 3766, April 2004. 544 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 545 RFC 3852, July 2004. 547 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 548 Kerberos 5", RFC 3961, February 2005. 550 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 551 Kerberos Network Authentication Service (V5)", RFC 4120, 552 July 2005. 554 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 555 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 557 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 558 (SHA and HMAC-SHA)", RFC 4634, July 2006. 560 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 561 Considerations for the SHA-0 and SHA-1 Message-Digest 562 Algorithms", RFC 6194, March 2011. 564 [SP80056A] 565 Barker, E., Don, D., and M. Smid, "Recommendation for 566 Pair-Wise Key Establishment Schemes Using Discrete 567 Logarithm Cryptography", March 2006. 569 [X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 570 1:2002, Information technology - Abstract Syntax Notation 571 One (ASN.1): Specification of basic notation". 573 [X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 574 1:2002, Information technology - ASN.1 encoding Rules: 575 Specification of Basic Encoding Rules (BER), Canonical 576 Encoding Rules (CER) and Distinguished Encoding Rules 577 (DER)". 579 11.2. Informative References 581 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 582 April 1992. 584 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 585 April 1992. 587 [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, 588 "Cryptanalysis of Hash functions MD4 and RIPEMD", 589 August 2004. 591 [X9.42] ANSI, "Public Key Cryptography for the Financial Services 592 Industry: Agreement of Symmetric Keys Using Discrete 593 Logarithm Cryptography", 2003. 595 Appendix A. PKINIT ASN.1 Module 597 KerberosV5-PK-INIT-Agility-SPEC { 598 iso(1) identified-organization(3) dod(6) internet(1) 599 security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) 600 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 602 IMPORTS 603 AlgorithmIdentifier, SubjectPublicKeyInfo 604 FROM PKIX1Explicit88 { iso (1) 605 identified-organization (3) dod (6) internet (1) 606 security (5) mechanisms (5) pkix (7) id-mod (0) 607 id-pkix1-explicit (18) } 608 -- As defined in RFC 3280. 610 Ticket, Int32, Realm, EncryptionKey, Checksum 611 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 612 dod(6) internet(1) security(5) kerberosV5(2) 613 modules(4) krb5spec2(2) } 614 -- as defined in RFC 4120. 616 PKAuthenticator, DHNonce 617 FROM KerberosV5-PK-INIT-SPEC { 618 iso(1) identified-organization(3) dod(6) internet(1) 619 security(5) kerberosV5(2) modules(4) pkinit(5) }; 620 -- as defined in RFC 4556. 622 TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF 623 AlgorithmIdentifier 624 -- Contains the list of CMS algorithm [RFC3852] 625 -- identifiers that identify the digest algorithms 626 -- acceptable by the KDC for signing CMS data in 627 -- the order of decreasing preference. 629 TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { 630 allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, 631 -- Contains the list of CMS algorithm [RFC3852] 632 -- identifiers that identify the digest algorithms 633 -- that are used by the CA to sign the client's 634 -- X.509 certificate and acceptable by the KDC in 635 -- the process of validating the client's X.509 636 -- certificate, in the order of decreasing 637 -- preference. 638 rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, 639 -- This identifies the digest algorithm that was 640 -- used to sign the client's X.509 certificate and 641 -- has been rejected by the KDC in the process of 642 -- validating the client's X.509 certificate 643 -- [RFC3280]. 644 ... 645 } 647 OtherInfo ::= SEQUENCE { 648 algorithmID AlgorithmIdentifier, 649 partyUInfo [0] OCTET STRING, 650 partyVInfo [1] OCTET STRING, 651 suppPubInfo [2] OCTET STRING OPTIONAL, 652 suppPrivInfo [3] OCTET STRING OPTIONAL 653 } 655 PkinitSuppPubInfo ::= SEQUENCE { 656 enctype [0] Int32, 657 -- The enctype of the AS reply key. 658 as-REQ [1] OCTET STRING, 659 -- This contains the AS-REQ in the request. 660 pk-as-rep [2] OCTET STRING, 661 -- Contains the DER encoding of the type 662 -- PA-PK-AS-REP [RFC4556] in the KDC reply. 663 ... 664 } 666 AuthPack ::= SEQUENCE { 667 pkAuthenticator [0] PKAuthenticator, 668 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 669 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 670 OPTIONAL, 671 clientDHNonce [3] DHNonce OPTIONAL, 672 ..., 673 supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, 674 -- Contains an unordered set of KDFs supported by the 675 -- client. 676 ... 677 } 679 KDFAlgorithmId ::= SEQUENCE { 680 kdf-id [0] OBJECT IDENTIFIER, 681 -- The object identifier of the KDF 682 ... 683 } 685 DHRepInfo ::= SEQUENCE { 686 dhSignedData [0] IMPLICIT OCTET STRING, 687 serverDHNonce [1] DHNonce OPTIONAL, 688 ..., 689 kdf [2] KDFAlgorithmId OPTIONAL, 690 -- The KDF picked by the KDC. 691 ... 692 } 693 END 695 Authors' Addresses 697 Love Hornquist Astrand 698 Apple, Inc 699 Cupertino, CA 700 USA 702 Email: lha@apple.com 704 Larry Zhu 705 Microsoft Corporation 706 One Microsoft Way 707 Redmond, WA 98052 708 USA 710 Email: lzhu@microsoft.com 712 Margaret Wasserman 713 Painless Security 714 356 Abbott Street 715 North Andover, MA 01845 716 USA 718 Phone: +1 781 405-7464 719 Email: mrw@painless-security.com 720 URI: http://www.painless-security.com