1NETWORK WORKING GROUP L. Zhu 2Internet-Draft Microsoft Corporation 3Expires: June 2, 2006 B. Tung 4 USC Information Sciences Institute 5 November 29, 2005 6 7 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-30 10 11Status of this Memo 12 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 34 This Internet-Draft will expire on June 2, 2006. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2005). 39 40Abstract 41 42 This document describes protocol extensions (hereafter called PKINIT) 43 to the Kerberos protocol specification. These extensions provide a 44 method for integrating public key cryptography into the initial 45 authentication exchange, by using asymmetric-key signature and/or 46 encryption algorithms in pre-authentication data fields. 47 48 49 50 51 52Zhu & Tung Expires June 2, 2006 [Page 1] 53 54Internet-Draft PKINIT November 2005 55 56 57Table of Contents 58 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5 63 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5 64 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 65 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 66 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 67 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 68 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12 69 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16 70 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22 71 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24 72 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 79 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29 80 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 81 Appendix C. Miscellaneous Information about Microsoft Windows 82 PKINIT Implementations . . . . . . . . . . . . . . . 36 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 84 Intellectual Property and Copyright Statements . . . . . . . . . . 39 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108Zhu & Tung Expires June 2, 2006 [Page 2] 109 110Internet-Draft PKINIT November 2005 111 112 1131. Introduction 114 115 A client typically authenticates itself to a service in Kerberos 116 using three distinct though related exchanges. First, the client 117 requests a ticket-granting ticket (TGT) from the Kerberos 118 authentication server (AS). Then, it uses the TGT to request a 119 service ticket from the Kerberos ticket-granting server (TGS). 120 Usually, the AS and TGS are integrated in a single device known as a 121 Kerberos Key Distribution Center, or KDC. Finally, the client uses 122 the service ticket to authenticate itself to the service. 123 124 The advantage afforded by the TGT is that the client exposes his 125 long-term secrets only once. The TGT and its associated session key 126 can then be used for any subsequent service ticket requests. One 127 result of this is that all further authentication is independent of 128 the method by which the initial authentication was performed. 129 Consequently, initial authentication provides a convenient place to 130 integrate public-key cryptography into Kerberos authentication. 131 132 As defined in [RFC4120], Kerberos authentication exchanges use 133 symmetric-key cryptography, in part for performance. One 134 disadvantage of using symmetric-key cryptography is that the keys 135 must be shared, so that before a client can authenticate itself, he 136 must already be registered with the KDC. 137 138 Conversely, public-key cryptography (in conjunction with an 139 established Public Key Infrastructure) permits authentication without 140 prior registration with a KDC. Adding it to Kerberos allows the 141 widespread use of Kerberized applications by clients without 142 requiring them to register first with a KDC--a requirement that has 143 no inherent security benefit. 144 145 As noted above, a convenient and efficient place to introduce public- 146 key cryptography into Kerberos is in the initial authentication 147 exchange. This document describes the methods and data formats for 148 integrating public-key cryptography into Kerberos initial 149 authentication. 150 151 1522. Conventions Used in This Document 153 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]. 157 158 Both the AS and the TGS are referred to as the KDC. 159 160 In this document, the encryption key used to encrypt the enc-part 161 162 163 164Zhu & Tung Expires June 2, 2006 [Page 3] 165 166Internet-Draft PKINIT November 2005 167 168 169 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS 170 reply key. 171 172 In this document, an empty sequence in an optional field can be 173 either included or omitted: both encodings are permitted and 174 considered equivalent. 175 176 In this document, the term "Modular Exponential Diffie-Hellman" is 177 used to refer to the Diffie-Hellman key exchange as described in 178 [RFC2631], in order to differentiate it from other equivalent 179 representations of the same key agreement algorithm. 180 181 1823. Extensions 183 184 This section describes extensions to [RFC4120] for supporting the use 185 of public-key cryptography in the initial request for a ticket. 186 187 Briefly, this document defines the following extensions to [RFC4120]: 188 189 1. The client indicates the use of public-key authentication by 190 including a special preauthenticator in the initial request. This 191 preauthenticator contains the client's public-key data and a 192 signature. 193 194 2. The KDC tests the client's request against its authentication 195 policy and trusted Certification Authorities (CAs). 196 197 3. If the request passes the verification tests, the KDC replies as 198 usual, but the reply is encrypted using either: 199 200 a. a key generated through a Diffie-Hellman (DH) key exchange 201 [RFC2631] [IEEE1363] with the client, signed using the KDC's 202 signature key; or 203 204 b. a symmetric encryption key, signed using the KDC's signature 205 key and encrypted using the client's public key. 206 207 Any keying material required by the client to obtain the 208 encryption key for decrypting the KDC reply is returned in a pre- 209 authentication field accompanying the usual reply. 210 211 4. The client validates the KDC's signature, obtains the encryption 212 key, decrypts the reply, and then proceeds as usual. 213 214 Section 3.1 of this document enumerates the required algorithms and 215 necessary extension message types. Section 3.2 describes the 216 extension messages in greater detail. 217 218 219 220Zhu & Tung Expires June 2, 2006 [Page 4] 221 222Internet-Draft PKINIT November 2005 223 224 2253.1. Definitions, Requirements, and Constants 226 2273.1.1. Required Algorithms 228 229 All PKINIT implementations MUST support the following algorithms: 230 231 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 232 sha1-96 [RFC3962]. 233 234 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 235 236 o AS reply key delivery method: Diffie-Hellman key exchange 237 [RFC2631]. 238 239 In addition, implementations of this specification MUST be capable of 240 processing the Extended Key Usage (EKU) extension and the id-pkinit- 241 san (as defined in Section 3.2.2) otherName of the Subject 242 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if 243 present. 244 2453.1.2. Defined Message and Encryption Types 246 247 PKINIT makes use of the following new pre-authentication types: 248 249 PA_PK_AS_REQ 16 250 PA_PK_AS_REP 17 251 252 PKINIT also makes use of the following new authorization data type: 253 254 AD_INITIAL_VERIFIED_CAS 9 255 256 PKINIT introduces the following new error codes: 257 258 KDC_ERR_CLIENT_NOT_TRUSTED 62 259 KDC_ERR_INVALID_SIG 64 260 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 261 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 262 KDC_ERR_INVALID_CERTIFICATE 71 263 KDC_ERR_REVOKED_CERTIFICATE 72 264 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 265 KDC_ERR_CLIENT_NAME_MISMATCH 75 266 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 267 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77 268 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78 269 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79 270 271 PKINIT uses the following typed data types for errors: 272 273 274 275 276Zhu & Tung Expires June 2, 2006 [Page 5] 277 278Internet-Draft PKINIT November 2005 279 280 281 TD_TRUSTED_CERTIFIERS 104 282 TD_INVALID_CERTIFICATES 105 283 TD_DH_PARAMETERS 109 284 285 The ASN.1 module for all structures defined in this document (plus 286 IMPORT statements for all imported structures) is given in 287 Appendix A. 288 289 All structures defined in or imported into this document MUST be 290 encoded using Distinguished Encoding Rules (DER) [X680] [X690] 291 (unless otherwise noted). All data structures carried in OCTET 292 STRINGs must be encoded according to the rules specified in 293 corresponding specifications. 294 295 Interoperability note: Some implementations may not be able to decode 296 wrapped CMS objects encoded with BER but not DER; specifically, they 297 may not be able to decode indefinite length encodings. To maximize 298 interoperability, implementers SHOULD encode CMS objects used in 299 PKINIT with DER. 300 3013.1.3. Algorithm Identifiers 302 303 PKINIT does not define, but does make use of, the following algorithm 304 identifiers. 305 306 PKINIT uses the following algorithm identifier(s) for Modular 307 Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]: 308 309 dhpublicnumber (as described in [RFC3279]) 310 311 PKINIT uses the following signature algorithm identifiers as defined 312 in [RFC3279]: 313 314 sha-1WithRSAEncryption (RSA with SHA1) 315 md5WithRSAEncryption (RSA with MD5) 316 id-dsa-with-sha1 (DSA with SHA1) 317 318 PKINIT uses the following encryption algorithm identifiers as defined 319 in [RFC3447] for encrypting the temporary key with a public key: 320 321 rsaEncryption 322 id-RSAES-OAEP 323 324 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 325 for encrypting the AS reply key with the temporary key: 326 327 des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370]) 328 rc2-cbc (RC2, CBC mode, as defined in [RFC3370]) 329 330 331 332Zhu & Tung Expires June 2, 2006 [Page 6] 333 334Internet-Draft PKINIT November 2005 335 336 337 id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565]) 338 339 PKINIT defines the following encryption types, for use in the etype 340 field of the AS-REQ [RFC4120] message to indicate acceptance of the 341 corresponding algorithms that can used by Cryptographic Message 342 Syntax (CMS) [RFC3852] messages in the reply: 343 344 id-dsa-with-sha1-CmsOID 9 345 -- Indicates that the client supports id-dsa-with-sha1. 346 md5WithRSAEncryption-CmsOID 10 347 -- Indicates that the client supports md5WithRSAEncryption. 348 sha-1WithRSAEncryption-CmsOID 11 349 -- Indicates that the client supports sha-1WithRSAEncryption. 350 rc2-cbc-EnvOID 12 351 -- Indicates that the client supports rc2-cbc. 352 rsaEncryption-EnvOID 13 353 -- Indicates that the client supports rsaEncryption. 354 id-RSAES-OAEP-EnvOID 14 355 -- Indicates that the client supports id-RSAES-OAEP. 356 des-ede3-cbc-EnvOID 15 357 -- Indicates that the client supports des-ede3-cbc. 358 3593.2. PKINIT Pre-authentication Syntax and Use 360 361 This section defines the syntax and use of the various pre- 362 authentication fields employed by PKINIT. 363 3643.2.1. Generation of Client Request 365 366 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 367 in addition, a pre-authentication data element, whose padata-type is 368 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 369 type PA-PK-AS-REQ, is included. 370 371 PA-PK-AS-REQ ::= SEQUENCE { 372 signedAuthPack [0] IMPLICIT OCTET STRING, 373 -- Contains a CMS type ContentInfo encoded 374 -- according to [RFC3852]. 375 -- The contentType field of the type ContentInfo 376 -- is id-signedData (1.2.840.113549.1.7.2), 377 -- and the content field is a SignedData. 378 -- The eContentType field for the type SignedData is 379 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 380 -- eContent field contains the DER encoding of the 381 -- type AuthPack. 382 -- AuthPack is defined below. 383 trustedCertifiers [1] SEQUENCE OF 384 ExternalPrincipalIdentifier OPTIONAL, 385 386 387 388Zhu & Tung Expires June 2, 2006 [Page 7] 389 390Internet-Draft PKINIT November 2005 391 392 393 -- Contains a list of CAs, trusted by the client, 394 -- that can be used to certify the KDC. 395 -- Each ExternalPrincipalIdentifier identifies a CA 396 -- or a CA certificate (thereby its public key). 397 -- The information contained in the 398 -- trustedCertifiers SHOULD be used by the KDC as 399 -- hints to guide its selection of an appropriate 400 -- certificate chain to return to the client. 401 kdcPkId [2] IMPLICIT OCTET STRING 402 OPTIONAL, 403 -- Contains a CMS type SignerIdentifier encoded 404 -- according to [RFC3852]. 405 -- Identifies, if present, a particular KDC 406 -- public key that the client already has. 407 ... 408 } 409 410 DHNonce ::= OCTET STRING 411 412 ExternalPrincipalIdentifier ::= SEQUENCE { 413 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 414 -- Contains a PKIX type Name encoded according to 415 -- [RFC3280]. 416 -- Identifies the certificate subject by the 417 -- distinguished subject name. 418 -- REQUIRED when there is a distinguished subject 419 -- name present in the certificate. 420 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 421 -- Contains a CMS type IssuerAndSerialNumber encoded 422 -- according to [RFC3852]. 423 -- Identifies a certificate of the subject. 424 -- REQUIRED for TD-INVALID-CERTIFICATES and 425 -- TD-TRUSTED-CERTIFIERS. 426 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 427 -- Identifies the subject's public key by a key 428 -- identifier. When an X.509 certificate is 429 -- referenced, this key identifier matches the X.509 430 -- subjectKeyIdentifier extension value. When other 431 -- certificate formats are referenced, the documents 432 -- that specify the certificate format and their use 433 -- with the CMS must include details on matching the 434 -- key identifier to the appropriate certificate 435 -- field. 436 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 437 ... 438 } 439 440 AuthPack ::= SEQUENCE { 441 442 443 444Zhu & Tung Expires June 2, 2006 [Page 8] 445 446Internet-Draft PKINIT November 2005 447 448 449 pkAuthenticator [0] PKAuthenticator, 450 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 451 -- Type SubjectPublicKeyInfo is defined in 452 -- [RFC3280]. 453 -- Specifies Diffie-Hellman domain parameters 454 -- and the client's public key value [IEEE1363]. 455 -- The DH public key value is encoded as a BIT 456 -- STRING according to [RFC3279]. 457 -- This field is present only if the client wishes 458 -- to use the Diffie-Hellman key agreement method. 459 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 460 OPTIONAL, 461 -- Type AlgorithmIdentifier is defined in 462 -- [RFC3280]. 463 -- List of CMS encryption types supported by the 464 -- client in order of (decreasing) preference. 465 clientDHNonce [3] DHNonce OPTIONAL, 466 -- Present only if the client indicates that it 467 -- wishes to reuse DH keys or to allow the KDC to 468 -- do so (see Section 3.2.3.1). 469 ... 470 } 471 472 PKAuthenticator ::= SEQUENCE { 473 cusec [0] INTEGER (0..999999), 474 ctime [1] KerberosTime, 475 -- cusec and ctime are used as in [RFC4120], for 476 -- replay prevention. 477 nonce [2] INTEGER (0..4294967295), 478 -- Chosen randomly; This nonce does not need to 479 -- match with the nonce in the KDC-REQ-BODY. 480 paChecksum [3] OCTET STRING, 481 -- Contains the SHA1 checksum, performed over 482 -- KDC-REQ-BODY. 483 ... 484 } 485 486 The ContentInfo [RFC3852] structure contained in the signedAuthPack 487 field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and 488 is filled out as follows: 489 490 1. The contentType field of the type ContentInfo is id-signedData 491 (as defined in [RFC3852]), and the content field is a SignedData 492 (as defined in [RFC3852]). 493 494 2. The eContentType field for the type SignedData is id-pkinit- 495 authData: { iso(1) org(3) dod(6) internet(1) security(5) 496 kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS 497 498 499 500Zhu & Tung Expires June 2, 2006 [Page 9] 501 502Internet-Draft PKINIT November 2005 503 504 505 implementers: the signed attribute content-type MUST be present 506 in this SignedData instance and its value is id-pkinit-authData 507 according to [RFC3852]. 508 509 3. The eContent field for the type SignedData contains the DER 510 encoding of the type AuthPack. 511 512 4. The signerInfos field of the type SignedData contains a single 513 signerInfo, which contains the signature over the type AuthPack. 514 515 5. The AuthPack structure contains a PKAuthenticator, the client 516 public key information, the CMS encryption types supported by the 517 client and a DHNonce. The pkAuthenticator field certifies to the 518 KDC that the client has recent knowledge of the signing key that 519 authenticates the client. The clientPublicValue field specifies 520 Diffie-Hellman domain parameters and the client's public key 521 value. The DH public key value is encoded as a BIT STRING 522 according to [RFC3279]. The clientPublicValue field is present 523 only if the client wishes to use the Diffie-Hellman key agreement 524 method. The supportedCMSTypes field specifies the list of CMS 525 encryption types supported by the client in order of (decreasing) 526 preference. The clientDHNonce field is described later in this 527 section. 528 529 6. The ctime field in the PKAuthenticator structure contains the 530 current time on the client's host, and the cusec field contains 531 the microsecond part of the client's timestamp. The ctime and 532 cusec fields are used together to specify a reasonably accurate 533 timestamp [RFC4120]. The nonce field is chosen randomly. The 534 paChecksum field contains a SHA1 checksum that is performed over 535 the KDC-REQ-BODY [RFC4120]. 536 537 7. The certificates field of the type SignedData contains 538 certificates intended to facilitate certification path 539 construction, so that the KDC can verify the signature over the 540 type AuthPack. For path validation, these certificates SHOULD be 541 sufficient to construct at least one certification path from the 542 client certificate to one trust anchor acceptable by the KDC 543 [RFC4158]. The client MUST be capable of including such a set of 544 certificates if configured to do so. The certificates field MUST 545 NOT contain "root" CA certificates. 546 547 8. The client's Diffie-Hellman public value (clientPublicValue) is 548 included if and only if the client wishes to use the Diffie- 549 Hellman key agreement method. The Diffie-Hellman domain 550 parameters [IEEE1363] for the client's public key are specified 551 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 552 and the client's Diffie-Hellman public key value is mapped to a 553 554 555 556Zhu & Tung Expires June 2, 2006 [Page 10] 557 558Internet-Draft PKINIT November 2005 559 560 561 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 562 using the Diffie-Hellman key agreement method, implementations 563 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 564 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 565 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 566 group 16 [RFC3526]. 567 568 The Diffie-Hellman field size should be chosen so as to provide 569 sufficient cryptographic security [RFC3766]. 570 571 When MODP Diffie-Hellman is used, the exponents should have at 572 least twice as many bits as the symmetric keys that will be 573 derived from them [ODL99]. 574 575 9. The client may wish to reuse DH keys or to allow the KDC to do so 576 (see Section 3.2.3.1). If so, then the client includes the 577 clientDHNonce field. This nonce string MUST be as long as the 578 longest key length of the symmetric key types that the client 579 supports. This nonce MUST be chosen randomly. 580 581 The ExternalPrincipalIdentifier structure is used in this document to 582 identify the subject's public key thereby the subject principal. 583 This structure is filled out as follows: 584 585 1. The subjectName field contains a PKIX type Name encoded according 586 to [RFC3280]. This field identifies the certificate subject by 587 the distinguished subject name. This field is REQUIRED when 588 there is a distinguished subject name present in the certificate 589 being used. 590 591 2. The issuerAndSerialNumber field contains a CMS type 592 IssuerAndSerialNumber encoded according to [RFC3852]. This field 593 identifies a certificate of the subject. This field is REQUIRED 594 for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both 595 structures are defined in Section 3.2.2). 596 597 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's 598 public key by a key identifier. When an X.509 certificate is 599 referenced, this key identifier matches the X.509 600 subjectKeyIdentifier extension value. When other certificate 601 formats are referenced, the documents that specify the 602 certificate format and their use with the CMS must include 603 details on matching the key identifier to the appropriate 604 certificate field. This field is RECOMMENDED for TD-TRUSTED- 605 CERTIFIERS (as defined in Section 3.2.2). 606 607 The trustedCertifiers field of the type PA-PK-AS-REQ contains a list 608 of CAs, trusted by the client, that can be used to certify the KDC. 609 610 611 612Zhu & Tung Expires June 2, 2006 [Page 11] 613 614Internet-Draft PKINIT November 2005 615 616 617 Each ExternalPrincipalIdentifier identifies a CA or a CA certificate 618 (thereby its public key). 619 620 The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type 621 SignerIdentifier encoded according to [RFC3852]. This field 622 identifies, if present, a particular KDC public key that the client 623 already has. 624 6253.2.2. Receipt of Client Request 626 627 Upon receiving the client's request, the KDC validates it. This 628 section describes the steps that the KDC MUST (unless otherwise 629 noted) take in validating the request. 630 631 The KDC verifies the client's signature in the signedAuthPack field 632 according to [RFC3852]. 633 634 If, while validating the client's X.509 certificate [RFC3280], the 635 KDC cannot build a certification path to validate the client's 636 certificate, it sends back a KRB-ERROR [RFC4120] message with the 637 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 638 this error message is a TYPED-DATA (as defined in [RFC4120]) that 639 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 640 whose data-value contains the DER encoding of the type TD-TRUSTED- 641 CERTIFIERS: 642 643 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 644 ExternalPrincipalIdentifier 645 -- Identifies a list of CAs trusted by the KDC. 646 -- Each ExternalPrincipalIdentifier identifies a CA 647 -- or a CA certificate (thereby its public key). 648 649 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 650 TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate 651 (thereby its public key) trusted by the KDC. 652 653 Upon receiving this error message, the client SHOULD retry only if it 654 has a different set of certificates (from those of the previous 655 requests) that form a certification path (or a partial path) from one 656 of the trust anchors acceptable by the KDC to its own certificate. 657 658 If, while processing the certification path, the KDC determines that 659 the signature on one of the certificates in the signedAuthPack field 660 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 661 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 662 message is a TYPED-DATA that contains an element whose data-type is 663 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 664 encoding of the type TD-INVALID-CERTIFICATES: 665 666 667 668Zhu & Tung Expires June 2, 2006 [Page 12] 669 670Internet-Draft PKINIT November 2005 671 672 673 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 674 ExternalPrincipalIdentifier 675 -- Each ExternalPrincipalIdentifier identifies a 676 -- certificate (sent by the client) with an invalid 677 -- signature. 678 679 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 680 TD-INVALID-CERTIFICATES structure identifies a certificate (that was 681 sent by the client) with an invalid signature. 682 683 If more than one X.509 certificate signature is invalid, the KDC MAY 684 include one IssuerAndSerialNumber per invalid signature within the 685 TD-INVALID-CERTIFICATES. 686 687 The client's X.509 certificate is validated according to [RFC3280]. 688 689 Based on local policy, the KDC may also check whether any X.509 690 certificates in the certification path validating the client's 691 certificate have been revoked. If any of them have been revoked, the 692 KDC MUST return an error message with the code 693 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 694 revocation status but is unable to do so, it SHOULD return an error 695 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 696 certificate or certificates affected are identified exactly as for 697 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 698 699 Note that the TD_INVALID_CERTIFICATES error data is only used to 700 identify invalid certificates sent by the client in the request. 701 702 The client's public key is then used to verify the signature. If the 703 signature fails to verify, the KDC MUST return an error message with 704 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 705 this error message. 706 707 In addition to validating the client's signature, the KDC MUST also 708 check that the client's public key used to verify the client's 709 signature is bound to the client's principal name as specified in the 710 AS-REQ as follows: 711 712 1. If the KDC has its own binding between either the client's 713 signature-verification public key or the client's certificate and 714 the client's Kerberos principal name, it uses that binding. 715 716 2. Otherwise, if the client's X.509 certificate contains a Subject 717 Alternative Name (SAN) extension carrying a KRB5PrincipalName 718 (defined below) in the otherName field of the type GeneralName 719 [RFC3280], it binds the client's X.509 certificate to that name. 720 721 722 723 724Zhu & Tung Expires June 2, 2006 [Page 13] 725 726Internet-Draft PKINIT November 2005 727 728 729 The type of the otherName field is AnotherName. The type-id field 730 of the type AnotherName is id-pkinit-san: 731 732 id-pkinit-san OBJECT IDENTIFIER ::= 733 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 734 x509SanAN (2) } 735 736 And the value field of the type AnotherName is a 737 KRB5PrincipalName. 738 739 KRB5PrincipalName ::= SEQUENCE { 740 realm [0] Realm, 741 principalName [1] PrincipalName 742 } 743 744 If the KDC does not have its own binding and there is no 745 KRB5PrincipalName name present in the client's X.509 certificate, or 746 if the Kerberos name in the request does not match the 747 KRB5PrincipalName in the client's X.509 certificate (including the 748 realm name), the KDC MUST return an error message with the code 749 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 750 this error message. 751 752 Even if the certification path is validated and the certificate is 753 mapped to the client's principal name, the KDC may decide not to 754 accept the client's certificate, depending on local policy. 755 756 The KDC MAY require the presence of an Extended Key Usage (EKU) 757 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field 758 of the client's X.509 certificate: 759 760 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= 761 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 762 pkinit(3) keyPurposeClientAuth(4) } 763 -- PKINIT client authentication. 764 -- Key usage bits that MUST be consistent: 765 -- digitalSignature. 766 767 The digitalSignature key usage bit MUST be asserted when the intended 768 purpose of the client certificate is restricted with the id-pkinit- 769 KPClientAuth EKU. 770 771 If this EKU KeyPurposeId is required but it is not present or if the 772 client certificate is restricted not to be used for PKINIT client 773 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 774 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 775 is no accompanying e-data for this error message. KDCs implementing 776 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- 777 778 779 780Zhu & Tung Expires June 2, 2006 [Page 14] 781 782Internet-Draft PKINIT November 2005 783 784 785 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 786 are a large number of X.509 client certificates deployed for use with 787 PKINIT which have this EKU. 788 789 As a matter of local policy, the KDC MAY decide to reject requests on 790 the basis of the absence or presence of other specific EKU OID's. 791 792 If the digest algorithm used in generating the CA signature for the 793 public key in any certificate of the request is not acceptable by the 794 KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code 795 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be 796 encoded in TYPED-DATA although none is defined at this point. 797 798 If the client's public key is not accepted with reasons other than 799 what were specified above, the KDC returns a KRB-ERROR [RFC4120] 800 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no 801 accompanying e-data currently defined for this error message. 802 803 The KDC MUST check the timestamp to ensure that the request is not a 804 replay, and that the time skew falls within acceptable limits. The 805 recommendations for clock skew times in [RFC4120] apply here. If the 806 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 807 KRB_AP_ERR_SKEW, respectively. 808 809 If the clientPublicValue is filled in, indicating that the client 810 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 811 check to see if the key parameters satisfy its policy. If they do 812 not, it MUST return an error message with the code 813 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 814 TYPED-DATA that contains an element whose data-type is 815 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 816 the type TD-DH-PARAMETERS: 817 818 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 819 -- Each AlgorithmIdentifier specifies a set of 820 -- Diffie-Hellman domain parameters [IEEE1363]. 821 -- This list is in decreasing preference order. 822 823 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 824 that the KDC supports in decreasing preference order, from which the 825 client SHOULD pick one to retry the request. 826 827 The AlgorithmIdentifier structure is defined in [RFC3280] and is 828 filled in according to [RFC3279]. More specifically Section 2.3.3 of 829 [RFC3279] describes how to fill in the AlgorithmIdentifier structure 830 in the case where MODP Diffie-Hellman key exchange is used. 831 832 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 833 834 835 836Zhu & Tung Expires June 2, 2006 [Page 15] 837 838Internet-Draft PKINIT November 2005 839 840 841 KDC does not possess the corresponding key, the KDC MUST ignore the 842 kdcPkId field as if the client did not include one. 843 844 If the digest algorithm used by the id-pkinit-authData is not 845 acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] 846 message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. 847 The accompanying e-data MUST be encoded in TYPED-DATA although none 848 is defined at this point. 849 8503.2.3. Generation of KDC Reply 851 852 Assuming that the client's request has been properly validated, the 853 KDC proceeds as per [RFC4120], except as follows. 854 855 The KDC MUST set the initial flag and include an authorization data 856 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 857 ticket. The ad-data [RFC4120] field contains the DER encoding of the 858 type AD-INITIAL-VERIFIED-CAS: 859 860 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 861 ExternalPrincipalIdentifier 862 -- Identifies the certification path based on which 863 -- the client certificate was validated. 864 -- Each ExternalPrincipalIdentifier identifies a CA 865 -- or a CA certificate (thereby its public key). 866 867 The AD-INITIAL-VERIFIED-CAS structure identifies the certification 868 path based on which the client certificate was validated. Each 869 ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- 870 INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate 871 (thereby its public key). 872 873 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 874 containers if the list of CAs satisfies the AS' realm's local policy 875 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 876 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 877 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 878 resulting ticket. If the list of CAs satisfies the local KDC's 879 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 880 container, otherwise it MAY unwrap the authorization data out of the 881 AD-IF-RELEVANT container. 882 883 Application servers that understand this authorization data type 884 SHOULD apply local policy to determine whether a given ticket bearing 885 such a type *not* contained within an AD-IF-RELEVANT container is 886 acceptable. (This corresponds to the AP server checking the 887 transited field when the TRANSITED-POLICY-CHECKED flag has not been 888 set [RFC4120].) If such a data type is contained within an AD-IF- 889 890 891 892Zhu & Tung Expires June 2, 2006 [Page 16] 893 894Internet-Draft PKINIT November 2005 895 896 897 RELEVANT container, AP servers MAY apply local policy to determine 898 whether the authorization data is acceptable. 899 900 A pre-authentication data element, whose padata-type is PA_PK_AS_REP 901 and whose padata-value contains the DER encoding of the type PA-PK- 902 AS-REP (defined below), is included in the AS-REP [RFC4120]. 903 904 PA-PK-AS-REP ::= CHOICE { 905 dhInfo [0] DHRepInfo, 906 -- Selected when Diffie-Hellman key exchange is 907 -- used. 908 encKeyPack [1] IMPLICIT OCTET STRING, 909 -- Selected when public key encryption is used. 910 -- Contains a CMS type ContentInfo encoded 911 -- according to [RFC3852]. 912 -- The contentType field of the type ContentInfo is 913 -- id-envelopedData (1.2.840.113549.1.7.3). 914 -- The content field is an EnvelopedData. 915 -- The contentType field for the type EnvelopedData 916 -- is id-signedData (1.2.840.113549.1.7.2). 917 -- The eContentType field for the inner type 918 -- SignedData (when unencrypted) is 919 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 920 -- eContent field contains the DER encoding of the 921 -- type ReplyKeyPack. 922 -- ReplyKeyPack is defined in Section 3.2.3.2. 923 ... 924 } 925 926 DHRepInfo ::= SEQUENCE { 927 dhSignedData [0] IMPLICIT OCTET STRING, 928 -- Contains a CMS type ContentInfo encoded according 929 -- to [RFC3852]. 930 -- The contentType field of the type ContentInfo is 931 -- id-signedData (1.2.840.113549.1.7.2), and the 932 -- content field is a SignedData. 933 -- The eContentType field for the type SignedData is 934 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 935 -- eContent field contains the DER encoding of the 936 -- type KDCDHKeyInfo. 937 -- KDCDHKeyInfo is defined below. 938 serverDHNonce [1] DHNonce OPTIONAL 939 -- Present if and only if dhKeyExpiration is 940 -- present in the KDCDHKeyInfo. 941 } 942 943 KDCDHKeyInfo ::= SEQUENCE { 944 subjectPublicKey [0] BIT STRING, 945 946 947 948Zhu & Tung Expires June 2, 2006 [Page 17] 949 950Internet-Draft PKINIT November 2005 951 952 953 -- The KDC's DH public key. 954 -- The DH public key value is encoded as a BIT 955 -- STRING according to [RFC3279]. 956 nonce [1] INTEGER (0..4294967295), 957 -- Contains the nonce in the pkAuthenticator field 958 -- in the request if the DH keys are NOT reused, 959 -- 0 otherwise. 960 dhKeyExpiration [2] KerberosTime OPTIONAL, 961 -- Expiration time for KDC's key pair, 962 -- present if and only if the DH keys are reused. 963 -- If present, the KDC's DH public key MUST not be 964 -- used past the point of this expiration time. 965 -- If this field is omitted then the serverDHNonce 966 -- field MUST also be omitted. 967 ... 968 } 969 970 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 971 KDC encrypts the reply as usual, but not with the client's long-term 972 key. Instead, it encrypts it with either a shared key derived from a 973 Diffie-Hellman exchange, or a generated encryption key. The contents 974 of the PA-PK-AS-REP indicate which key delivery method is used. 975 976 In addition, the lifetime of the ticket returned by the KDC MUST NOT 977 exceed that of the client's public-private key pair. The ticket 978 lifetime, however, can be shorter than that of the client's public- 979 private key pair. For the implementations of this specification, the 980 lifetime of the client's public-private key pair is the validity 981 period in X.509 certificates [RFC3280], unless configured otherwise. 982 9833.2.3.1. Using Diffie-Hellman Key Exchange 984 985 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 986 987 The ContentInfo [RFC3852] structure for the dhSignedData field is 988 filled in as follows: 989 990 1. The contentType field of the type ContentInfo is id-signedData 991 (as defined in [RFC3852]), and the content field is a SignedData 992 (as defined in [RFC3852]). 993 994 2. The eContentType field for the type SignedData is the OID value 995 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) 996 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS 997 implementers: the signed attribute content-type MUST be present 998 in this SignedData instance and its value is id-pkinit-DHKeyData 999 according to [RFC3852]. 1000 1001 1002 1003 1004Zhu & Tung Expires June 2, 2006 [Page 18] 1005 1006Internet-Draft PKINIT November 2005 1007 1008 1009 3. The eContent field for the type SignedData contains the DER 1010 encoding of the type KDCDHKeyInfo. 1011 1012 4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce 1013 and optionally the expiration time of the KDC's DH key being 1014 reused. The subjectPublicKey field of the type KDCDHKeyInfo 1015 field identifies KDC's DH public key. This DH public key value 1016 is encoded as a BIT STRING according to [RFC3279]. The nonce 1017 field contains the nonce in the pkAuthenticator field in the 1018 request if the DH keys are NOT reused. The value of this nonce 1019 field is 0 if the DH keys are reused. The dhKeyExpiration field 1020 is present if and only if the DH keys are reused. If the 1021 dhKeyExpiration field is present, the KDC's public key in this 1022 KDCDHKeyInfo structure MUST NOT be used past the point of this 1023 expiration time. If this field is omitted then the serverDHNonce 1024 field MUST also be omitted. 1025 1026 5. The signerInfos field of the type SignedData contains a single 1027 signerInfo, which contains the signature over the type 1028 KDCDHKeyInfo. 1029 1030 6. The certificates field of the type SignedData contains 1031 certificates intended to facilitate certification path 1032 construction, so that the client can verify the KDC's signature 1033 over the type KDCDHKeyInfo. The information contained in the 1034 trustedCertifiers in the request SHOULD be used by the KDC as 1035 hints to guide its selection of an appropriate certificate chain 1036 to return to the client. This field may be left empty if the KDC 1037 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 1038 used for signing. Otherwise, for path validation, these 1039 certificates SHOULD be sufficient to construct at least one 1040 certification path from the KDC certificate to one trust anchor 1041 acceptable by the client [RFC4158]. The KDC MUST be capable of 1042 including such a set of certificates if configured to do so. The 1043 certificates field MUST NOT contain "root" CA certificates. 1044 1045 7. If the client included the clientDHNonce field, then the KDC may 1046 choose to reuse its DH keys (see Section 3.2.3.1). If the server 1047 reuses DH keys then it MUST include an expiration time in the 1048 dhKeyExpiration field. Past the point of the expiration time, 1049 the signature over the type DHRepInfo is considered expired/ 1050 invalid. When the server reuses DH keys then it MUST include a 1051 serverDHNonce at least as long as the length of keys for the 1052 symmetric encryption system used to encrypt the AS reply. Note 1053 that including the serverDHNonce changes how the client and 1054 server calculate the key to use to encrypt the reply; see below 1055 for details. The KDC SHOULD NOT reuse DH keys unless the 1056 clientDHNonce field is present in the request. 1057 1058 1059 1060Zhu & Tung Expires June 2, 2006 [Page 19] 1061 1062Internet-Draft PKINIT November 2005 1063 1064 1065 The AS reply key is derived as follows: 1066 1067 1. Both the KDC and the client calculate the shared secret value as 1068 follows: 1069 1070 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 1071 shared secret value. DHSharedSecret is the value ZZ as 1072 described in Section 2.1.1 of [RFC2631]. 1073 1074 DHSharedSecret is first padded with leading zeros such that the 1075 size of DHSharedSecret in octets is the same as that of the 1076 modulus, then represented as a string of octets in big-endian 1077 order. 1078 1079 Implementation note: Both the client and the KDC can cache the 1080 triple (ya, yb, DHSharedSecret), where ya is the client's public 1081 key and yb is the KDC's public key. If both ya and yb are the 1082 same in a later exchange, the cached DHSharedSecret can be used. 1083 1084 2. Let K be the key-generation seed length [RFC3961] of the AS reply 1085 key whose enctype is selected according to [RFC4120]. 1086 1087 3. Define the function octetstring2key() as follows: 1088 1089 octetstring2key(x) == random-to-key(K-truncate( 1090 SHA1(0x00 | x) | 1091 SHA1(0x01 | x) | 1092 SHA1(0x02 | x) | 1093 ... 1094 )) 1095 1096 where x is an octet string; | is the concatenation operator; 0x00, 1097 0x01, 0x02, etc., are each represented as a single octet; random- 1098 to-key() is an operation that generates a protocol key from a 1099 bitstring of length K; and K-truncate truncates its input to the 1100 first K bits. Both K and random-to-key() are as defined in the 1101 kcrypto profile [RFC3961] for the enctype of the AS reply key. 1102 1103 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 1104 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 1105 strings. 1106 1107 5. The AS reply key k is: 1108 1109 k = octetstring2key(DHSharedSecret | n_c | n_k) 1110 1111 If the hash algorithm used in the key derivation function (currently 1112 only octetstring2key() is defined) is not acceptable by the KDC, the 1113 1114 1115 1116Zhu & Tung Expires June 2, 2006 [Page 20] 1117 1118Internet-Draft PKINIT November 2005 1119 1120 1121 KDC MUST return a KRB-ERROR [RFC4120] message with the code 1122 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be 1123 encoded in TYPED-DATA although none is defined at this point. 1124 11253.2.3.2. Using Public Key Encryption 1126 1127 In this case, the PA-PK-AS-REP contains an encKeyPack structure where 1128 the AS reply key is encrypted. 1129 1130 The ContentInfo [RFC3852] structure for the encKeyPack field is 1131 filled in as follows: 1132 1133 1. The contentType field of the type ContentInfo is id-envelopedData 1134 (as defined in [RFC3852]), and the content field is an 1135 EnvelopedData (as defined in [RFC3852]). 1136 1137 2. The contentType field for the type EnvelopedData is id- 1138 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 1139 pkcs (1) pkcs7 (7) signedData (2) }. 1140 1141 3. The eContentType field for the inner type SignedData (when 1142 decrypted from the encryptedContent field for the type 1143 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) 1144 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. 1145 Notes to CMS implementers: the signed attribute content-type MUST 1146 be present in this SignedData instance and its value is id- 1147 pkinit-rkeyData according to [RFC3852]. 1148 1149 4. The eContent field for the inner type SignedData contains the DER 1150 encoding of the type ReplyKeyPack (as described below). 1151 1152 5. The signerInfos field of the inner type SignedData contains a 1153 single signerInfo, which contains the signature for the type 1154 ReplyKeyPack. 1155 1156 6. The certificates field of the inner type SignedData contains 1157 certificates intended to facilitate certification path 1158 construction, so that the client can verify the KDC's signature 1159 for the type ReplyKeyPack. The information contained in the 1160 trustedCertifiers in the request SHOULD be used by the KDC as 1161 hints to guide its selection of an appropriate certificate chain 1162 to return to the client. This field may be left empty if the KDC 1163 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 1164 used for signing. Otherwise, for path validation, these 1165 certificates SHOULD be sufficient to construct at least one 1166 certification path from the KDC certificate to one trust anchor 1167 acceptable by the client [RFC4158]. The KDC MUST be capable of 1168 including such a set of certificates if configured to do so. The 1169 1170 1171 1172Zhu & Tung Expires June 2, 2006 [Page 21] 1173 1174Internet-Draft PKINIT November 2005 1175 1176 1177 certificates field MUST NOT contain "root" CA certificates. 1178 1179 7. The recipientInfos field of the type EnvelopedData is a SET which 1180 MUST contain exactly one member of type KeyTransRecipientInfo. 1181 The encryptedKey of this member contains the temporary key which 1182 is encrypted using the client's public key. 1183 1184 8. The unprotectedAttrs or originatorInfo fields of the type 1185 EnvelopedData MAY be present. 1186 1187 If there is a supportedCMSTypes field in the AuthPack, the KDC must 1188 check to see if it supports any of the listed types. If it supports 1189 more than one of the types, the KDC SHOULD use the one listed first. 1190 If it does not support any of them, it MUST return an error message 1191 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 1192 1193 Furthermore the KDC computes the checksum of the AS-REQ in the client 1194 request. This checksum is performed over the type AS-REQ and the 1195 protocol key [RFC3961] of the checksum operation is the replyKey and 1196 the key usage number is 6. If the replyKey's enctype is "newer" 1197 [RFC4120] [RFC4121], the checksum operation is the required checksum 1198 operation [RFC3961] of that enctype. 1199 1200 ReplyKeyPack ::= SEQUENCE { 1201 replyKey [0] EncryptionKey, 1202 -- Contains the session key used to encrypt the 1203 -- enc-part field in the AS-REP, i.e. the 1204 -- AS reply key. 1205 asChecksum [1] Checksum, 1206 -- Contains the checksum of the AS-REQ 1207 -- corresponding to the containing AS-REP. 1208 -- The checksum is performed over the type AS-REQ. 1209 -- The protocol key [RFC3961] of the checksum is the 1210 -- replyKey and the key usage number is 6. 1211 -- If the replyKey's enctype is "newer" [RFC4120] 1212 -- [RFC4121], the checksum is the required 1213 -- checksum operation [RFC3961] for that enctype. 1214 -- The client MUST verify this checksum upon receipt 1215 -- of the AS-REP. 1216 ... 1217 } 1218 1219 Implementations of this RSA encryption key delivery method are 1220 RECOMMENDED to support RSA keys at least 2048 bits in size. 1221 12223.2.4. Receipt of KDC Reply 1223 1224 Upon receipt of the KDC's reply, the client proceeds as follows. If 1225 1226 1227 1228Zhu & Tung Expires June 2, 2006 [Page 22] 1229 1230Internet-Draft PKINIT November 2005 1231 1232 1233 the PA-PK-AS-REP contains the dhSignedData field, the client derives 1234 the AS reply key using the same procedure used by the KDC as defined 1235 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 1236 field, and the client decrypts and extracts the temporary key in the 1237 encryptedKey field of the member KeyTransRecipientInfo, and then uses 1238 that as the AS reply key. 1239 1240 If the public key encryption method is used, the client MUST verify 1241 the asChecksum contained in the ReplyKeyPack. 1242 1243 In either case, the client MUST verify the signature in the 1244 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 1245 be validated according to [RFC3280]. In addition, unless the client 1246 can otherwise verify that the public key used to verify the KDC's 1247 signature is bound to the KDC of the target realm, the KDC's X.509 1248 certificate MUST contain a Subject Alternative Name extension 1249 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as 1250 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 1251 matches the name of the TGS of the target realm (as defined in 1252 Section 7.3 of [RFC4120]). 1253 1254 Unless the client knows by some other means that the KDC certificate 1255 is intended for a Kerberos KDC, the client MUST require that the KDC 1256 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: 1257 1258 id-pkinit-KPKdc OBJECT IDENTIFIER ::= 1259 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1260 pkinit(3) keyPurposeKdc(5) } 1261 -- Signing KDC responses. 1262 -- Key usage bits that MUST be consistent: 1263 -- digitalSignature. 1264 1265 The digitalSignature key usage bit MUST be asserted when the intended 1266 purpose of KDC certificate is restricted with the id-pkinit-KPKdc 1267 EKU. 1268 1269 If the KDC certificate contains the Kerberos TGS name encoded as an 1270 id-pkinit-san SAN, this certificate is certified by the issuing CA as 1271 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. 1272 1273 If all applicable checks are satisfied, the client then decrypts the 1274 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 1275 and then proceeds as described in [RFC4120]. 1276 1277 Implementation note: CAs issuing KDC certificates SHOULD place all 1278 "short" and "fully-qualified" Kerberos realm names of the KDC (one 1279 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 1280 flexibility. 1281 1282 1283 1284Zhu & Tung Expires June 2, 2006 [Page 23] 1285 1286Internet-Draft PKINIT November 2005 1287 1288 12893.3. Interoperability Requirements 1290 1291 The client MUST be capable of sending a set of certificates 1292 sufficient to allow the KDC to construct a certification path for the 1293 client's certificate, if the correct set of certificates is provided 1294 through configuration or policy. 1295 1296 If the client sends all the X.509 certificates on a certification 1297 path to a trust anchor acceptable by the KDC, and the KDC can not 1298 verify the client's public key otherwise, the KDC MUST be able to 1299 process path validation for the client's certificate based on the 1300 certificates in the request. 1301 1302 The KDC MUST be capable of sending a set of certificates sufficient 1303 to allow the client to construct a certification path for the KDC's 1304 certificate, if the correct set of certificates is provided through 1305 configuration or policy. 1306 1307 If the KDC sends all the X.509 certificates on a certification path 1308 to a trust anchor acceptable by the client, and the client can not 1309 verify the KDC's public key otherwise, the client MUST be able to 1310 process path validation for the KDC's certificate based on the 1311 certificates in the reply. 1312 13133.4. KDC Indication of PKINIT Support 1314 1315 If pre-authentication is required, but was not present in the 1316 request, per [RFC4120] an error message with the code 1317 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 1318 stored in the e-data field of the KRB-ERROR message to specify which 1319 pre-authentication mechanisms are acceptable. The KDC can then 1320 indicate the support of PKINIT by including an empty element whose 1321 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 1322 1323 Otherwise if it is required by the KDC's local policy that the client 1324 must be pre-authenticated using the pre-authentication mechanism 1325 specified in this document, but no PKINIT pre-authentication was 1326 present in the request, an error message with the code 1327 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 1328 1329 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 1330 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 1331 STRING), and clients MUST ignore this and any other value. Future 1332 extensions to this protocol may specify other data to send instead of 1333 an empty OCTET STRING. 1334 1335 1336 1337 1338 1339 1340Zhu & Tung Expires June 2, 2006 [Page 24] 1341 1342Internet-Draft PKINIT November 2005 1343 1344 13454. Security Considerations 1346 1347 Kerberos error messages are not integrity protected, as a result, the 1348 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered 1349 with by an attacker so that the set of domain parameters selected 1350 could be either weaker or not mutually preferred. Local policy can 1351 configure sets of domain parameters acceptable locally, or disallow 1352 the negotiation of DH domain parameters. 1353 1354 The symmetric reply key size and Diffie-Hellman field size or RSA 1355 modulus size should be chosen so as to provide sufficient 1356 cryptographic security [RFC3766]. 1357 1358 When MODP Diffie-Hellman is used, the exponents should have at least 1359 twice as many bits as the symmetric keys that will be derived from 1360 them [ODL99]. 1361 1362 PKINIT raises certain security considerations beyond those that can 1363 be regulated strictly in protocol definitions. We will address them 1364 in this section. 1365 1366 PKINIT extends the cross-realm model to the public-key 1367 infrastructure. Users of PKINIT must understand security policies 1368 and procedures appropriate to the use of Public Key Infrastructures 1369 [RFC3280]. 1370 1371 In order to trust a KDC certificate that is certified by a CA as a 1372 KDC certificate for a target realm (for example, by asserting the TGS 1373 name of that Kerberos realm as an id-pkinit-san SAN and/or 1374 restricting the certificate usage by using the id-pkinit-KPKdc EKU, 1375 as described in Section 3.2.4), the client MUST verify that the KDC 1376 certificate's issuing CA is authorized to issue KDC certificates for 1377 that target realm. Otherwise, the binding between the KDC 1378 certificate and the KDC of the target realm is not established. 1379 1380 How to validate this authorization is a matter of local policy. A 1381 way to achieve this is the configuration of specific sets of 1382 intermediary CAs and trust anchors, one of which must be on the KDC 1383 certificate's certification path [RFC3280]; and for each CA or trust 1384 anchor the realms for which it is allowed to issue certificates. 1385 1386 In addition, if any CA is trusted to issue KDC certificates can also 1387 issue other kinds of certificates, then local policy must be able to 1388 distinguish between them: for example, it could require that KDC 1389 certificates contain the id-pkinit-KPKdc EKU or that the realm be 1390 specified with the id-pkinit-san SAN. 1391 1392 It is the responsibility of the PKI administrators for an 1393 1394 1395 1396Zhu & Tung Expires June 2, 2006 [Page 25] 1397 1398Internet-Draft PKINIT November 2005 1399 1400 1401 organization to ensure that KDC certificates are only issued to KDCs, 1402 and that clients can ascertain this using their local policy. 1403 1404 Standard Kerberos allows the possibility of interactions between 1405 cryptosystems of varying strengths; this document adds interactions 1406 with public-key cryptosystems to Kerberos. Some administrative 1407 policies may allow the use of relatively weak public keys. Using 1408 such keys to wrap data encrypted under stronger conventional 1409 cryptosystems may be inappropriate. 1410 1411 PKINIT requires keys for symmetric cryptosystems to be generated. 1412 Some such systems contain "weak" keys. For recommendations regarding 1413 these weak keys, see [RFC4120]. 1414 1415 PKINIT allows the use of the same RSA key pair for encryption and 1416 signing when doing RSA encryption based key delivery. This is not 1417 recommended usage of RSA keys [RFC3447], by using DH based key 1418 delivery this is avoided. 1419 1420 Care should be taken in how certificates are chosen for the purposes 1421 of authentication using PKINIT. Some local policies may require that 1422 key escrow be used for certain certificate types. Deployers of 1423 PKINIT should be aware of the implications of using certificates that 1424 have escrowed keys for the purposes of authentication. Because 1425 signing only certificates are normally not escrowed, by using DH 1426 based key delivery this is avoided. 1427 1428 PKINIT does not provide for a "return routability" test to prevent 1429 attackers from mounting a denial-of-service attack on the KDC by 1430 causing it to perform unnecessary and expensive public-key 1431 operations. Strictly speaking, this is also true of standard 1432 Kerberos, although the potential cost is not as great, because 1433 standard Kerberos does not make use of public-key cryptography. By 1434 using DH based key delivery and reusing DH keys, the necessary crypto 1435 processing cost per request can be minimized. 1436 1437 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1438 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1439 be used if the KDC itself vouches for the user's certificate. 1440 1441 When the Diffie-Hellman key exchange method is used, additional pre- 1442 authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as 1443 defined in this specification) is not bound to the AS_REQ by the 1444 mechanisms discussed in this specification (meaning it may be dropped 1445 or added by attackers without being detected by either the client or 1446 the KDC). Designers of additional pre-authentication data should 1447 take that into consideration if such additional pre-authentication 1448 data can be used in conjunction with the PA_PK_AS_REQ. The future 1449 1450 1451 1452Zhu & Tung Expires June 2, 2006 [Page 26] 1453 1454Internet-Draft PKINIT November 2005 1455 1456 1457 work of the Kerberos working group is expected to update the hash 1458 algorithms specified in this document and provide a generic mechanism 1459 to bind additional pre-authentication data with the accompanying 1460 AS_REQ. 1461 1462 14635. Acknowledgements 1464 1465 The following people have made significant contributions to this 1466 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist 1467 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey 1468 Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M 1469 Grundman and Jeffrey Altman. 1470 1471 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and 1472 Chris Walstad discovered a binding issue between the AS-REQ and AS- 1473 REP in draft -26, the asChecksum field was added as the result. 1474 1475 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1476 Jonathan Trostle who wrote earlier versions of this document. 1477 1478 The authors are indebted to the Kerberos working group chair Jeffrey 1479 Hutzelman who kept track of various issues and was enormously helpful 1480 during the creation of this document. 1481 1482 Some of the ideas on which this document is based arose during 1483 discussions over several years between members of the SAAG, the IETF 1484 CAT working group, and the PSRG, regarding integration of Kerberos 1485 and SPX. Some ideas have also been drawn from the DASS system. 1486 These changes are by no means endorsed by these groups. This is an 1487 attempt to revive some of the goals of those groups, and this 1488 document approaches those goals primarily from the Kerberos 1489 perspective. 1490 1491 Lastly, comments from groups working on similar ideas in DCE have 1492 been invaluable. 1493 1494 14956. IANA Considerations 1496 1497 This document has no actions for IANA. 1498 1499 15007. References 1501 1502 1503 1504 1505 1506 1507 1508Zhu & Tung Expires June 2, 2006 [Page 27] 1509 1510Internet-Draft PKINIT November 2005 1511 1512 15137.1. Normative References 1514 1515 [IEEE1363] 1516 IEEE, "Standard Specifications for Public Key 1517 Cryptography", IEEE 1363, 2000. 1518 1519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1520 Requirement Levels", BCP 14, RFC 2119, March 1997. 1521 1522 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1523 RFC 2412, November 1998. 1524 1525 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1526 RFC 2631, June 1999. 1527 1528 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1529 Identifiers for the Internet X.509 Public Key 1530 Infrastructure Certificate and Certificate Revocation List 1531 (CRL) Profile", RFC 3279, April 2002. 1532 1533 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1534 X.509 Public Key Infrastructure Certificate and 1535 Certificate Revocation List (CRL) Profile", RFC 3280, 1536 April 2002. 1537 1538 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1539 Algorithms", RFC 3370, August 2002. 1540 1541 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1542 Standards (PKCS) #1: RSA Cryptography Specifications 1543 Version 2.1", RFC 3447, February 2003. 1544 1545 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1546 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1547 RFC 3526, May 2003. 1548 1549 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1550 Encryption Algorithm in Cryptographic Message Syntax 1551 (CMS)", RFC 3565, July 2003. 1552 1553 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1554 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1555 RFC 3766, April 2004. 1556 1557 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1558 RFC 3852, July 2004. 1559 1560 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1561 1562 1563 1564Zhu & Tung Expires June 2, 2006 [Page 28] 1565 1566Internet-Draft PKINIT November 2005 1567 1568 1569 Kerberos 5", RFC 3961, February 2005. 1570 1571 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1572 Encryption for Kerberos 5", RFC 3962, February 2005. 1573 1574 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1575 Kerberos Network Authentication Service (V5)", RFC 4120, 1576 July 2005. 1577 1578 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1579 Version 5 Generic Security Service Application Program 1580 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1581 July 2005. 1582 1583 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1584 Information technology - Abstract Syntax Notation One 1585 (ASN.1): Specification of basic notation. 1586 1587 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1588 Information technology - ASN.1 encoding Rules: Specification 1589 of Basic Encoding Rules (BER), Canonical Encoding Rules 1590 (CER) and Distinguished Encoding Rules (DER). 1591 15927.2. Informative References 1593 1594 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1595 Sizes", Journal of Cryptology 14 (2001) 255-293. 1596 1597 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1598 future, Designs, Codes, and Cryptography (1999)". 1599 1600 1601Zhu & Tung Expires June 1, 2006 [Page 27] 1602 1603Internet-Draft PKINIT November 2005 1604 1605 1606 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 1607 Nicholas, "Internet X.509 Public Key Infrastructure: 1608 Certification Path Building", RFC 4158, September 2005. 1609 1610 1611Appendix A. PKINIT ASN.1 Module 1612 1613 KerberosV5-PK-INIT-SPEC { 1614 iso(1) identified-organization(3) dod(6) internet(1) 1615 security(5) kerberosV5(2) modules(4) pkinit(5) 1616 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1617 1618 IMPORTS 1619 SubjectPublicKeyInfo, AlgorithmIdentifier 1620 1621 1622 1623Zhu & Tung Expires June 2, 2006 [Page 29] 1624 1625Internet-Draft PKINIT November 2005 1626 1627 1628 FROM PKIX1Explicit88 { iso (1) 1629 identified-organization (3) dod (6) internet (1) 1630 security (5) mechanisms (5) pkix (7) id-mod (0) 1631 id-pkix1-explicit (18) } 1632 -- As defined in RFC 3280. 1633 1634 KerberosTime, PrincipalName, Realm, EncryptionKey 1635 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1636 dod(6) internet(1) security(5) kerberosV5(2) 1637 modules(4) krb5spec2(2) } ; 1638 1639 id-pkinit OBJECT IDENTIFIER ::= 1640 { iso (1) org (3) dod (6) internet (1) security (5) 1641 kerberosv5 (2) pkinit (3) } 1642 1643 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 } 1644 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 } 1645 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 } 1646 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 } 1647 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 } 1648 1649 id-pkinit-san OBJECT IDENTIFIER ::= 1650 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1651 x509SanAN (2) } 1652 1653 pa-pk-as-req INTEGER ::= 16 1654 pa-pk-as-rep INTEGER ::= 17 1655 1656 ad-initial-verified-cas INTEGER ::= 9 1657 1658 td-trusted-certifiers INTEGER ::= 104 1659 td-invalid-certificates INTEGER ::= 105 1660 td-dh-parameters INTEGER ::= 109 1661 1662 PA-PK-AS-REQ ::= SEQUENCE { 1663 signedAuthPack [0] IMPLICIT OCTET STRING, 1664 -- Contains a CMS type ContentInfo encoded 1665 -- according to [RFC3852]. 1666 -- The contentType field of the type ContentInfo 1667 -- is id-signedData (1.2.840.113549.1.7.2), 1668 -- and the content field is a SignedData. 1669 -- The eContentType field for the type SignedData is 1670 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 1671 -- eContent field contains the DER encoding of the 1672 -- type AuthPack. 1673 -- AuthPack is defined below. 1674 trustedCertifiers [1] SEQUENCE OF 1675 ExternalPrincipalIdentifier OPTIONAL, 1676 1677 1678 1679Zhu & Tung Expires June 2, 2006 [Page 30] 1680 1681Internet-Draft PKINIT November 2005 1682 1683 1684 -- Contains a list of CAs, trusted by the client, 1685 -- that can be used to certify the KDC. 1686 -- Each ExternalPrincipalIdentifier identifies a CA 1687 -- or a CA certificate (thereby its public key). 1688 -- The information contained in the 1689 -- trustedCertifiers SHOULD be used by the KDC as 1690 -- hints to guide its selection of an appropriate 1691 -- certificate chain to return to the client. 1692 kdcPkId [2] IMPLICIT OCTET STRING 1693 OPTIONAL, 1694 -- Contains a CMS type SignerIdentifier encoded 1695 -- according to [RFC3852]. 1696 -- Identifies, if present, a particular KDC 1697 -- public key that the client already has. 1698 ... 1699 } 1700 1701 DHNonce ::= OCTET STRING 1702 1703 ExternalPrincipalIdentifier ::= SEQUENCE { 1704 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1705 -- Contains a PKIX type Name encoded according to 1706 -- [RFC3280]. 1707 -- Identifies the certificate subject by the 1708 -- distinguished subject name. 1709 -- REQUIRED when there is a distinguished subject 1710 -- name present in the certificate. 1711 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1712 -- Contains a CMS type IssuerAndSerialNumber encoded 1713 -- according to [RFC3852]. 1714 -- Identifies a certificate of the subject. 1715 -- REQUIRED for TD-INVALID-CERTIFICATES and 1716 -- TD-TRUSTED-CERTIFIERS. 1717 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1718 -- Identifies the subject's public key by a key 1719 -- identifier. When an X.509 certificate is 1720 -- referenced, this key identifier matches the X.509 1721 -- subjectKeyIdentifier extension value. When other 1722 -- certificate formats are referenced, the documents 1723 -- that specify the certificate format and their use 1724 -- with the CMS must include details on matching the 1725 -- key identifier to the appropriate certificate 1726 -- field. 1727 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1728 ... 1729 } 1730 1731 AuthPack ::= SEQUENCE { 1732 1733 1734 1735Zhu & Tung Expires June 2, 2006 [Page 31] 1736 1737Internet-Draft PKINIT November 2005 1738 1739 1740 pkAuthenticator [0] PKAuthenticator, 1741 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1742 -- Type SubjectPublicKeyInfo is defined in 1743 -- [RFC3280]. 1744 -- Specifies Diffie-Hellman domain parameters 1745 -- and the client's public key value [IEEE1363]. 1746 -- The DH public key value is encoded as a BIT 1747 -- STRING according to [RFC3279]. 1748 -- This field is present only if the client wishes 1749 -- to use the Diffie-Hellman key agreement method. 1750 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1751 OPTIONAL, 1752 -- Type AlgorithmIdentifier is defined in 1753 -- [RFC3280]. 1754 -- List of CMS encryption types supported by the 1755 -- client in order of (decreasing) preference. 1756 clientDHNonce [3] DHNonce OPTIONAL, 1757 -- Present only if the client indicates that it 1758 -- wishes to reuse DH keys or to allow the KDC to 1759 -- do so. 1760 ... 1761 } 1762 1763 PKAuthenticator ::= SEQUENCE { 1764 cusec [0] INTEGER (0..999999), 1765 ctime [1] KerberosTime, 1766 -- cusec and ctime are used as in [RFC4120], for 1767 -- replay prevention. 1768 nonce [2] INTEGER (0..4294967295), 1769 -- Chosen randomly; This nonce does not need to 1770 -- match with the nonce in the KDC-REQ-BODY. 1771 paChecksum [3] OCTET STRING, 1772 -- Contains the SHA1 checksum, performed over 1773 -- KDC-REQ-BODY. 1774 ... 1775 } 1776 1777 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1778 ExternalPrincipalIdentifier 1779 -- Identifies a list of CAs trusted by the KDC. 1780 -- Each ExternalPrincipalIdentifier identifies a CA 1781 -- or a CA certificate (thereby its public key). 1782 1783 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1784 ExternalPrincipalIdentifier 1785 -- Each ExternalPrincipalIdentifier identifies a 1786 -- certificate (sent by the client) with an invalid 1787 -- signature. 1788 1789 1790 1791Zhu & Tung Expires June 2, 2006 [Page 32] 1792 1793Internet-Draft PKINIT November 2005 1794 1795 1796 KRB5PrincipalName ::= SEQUENCE { 1797 realm [0] Realm, 1798 principalName [1] PrincipalName 1799 } 1800 1801 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1802 ExternalPrincipalIdentifier 1803 -- Identifies the certification path based on which 1804 -- the client certificate was validated. 1805 -- Each ExternalPrincipalIdentifier identifies a CA 1806 -- or a CA certificate (thereby its public key). 1807 1808 PA-PK-AS-REP ::= CHOICE { 1809 dhInfo [0] DHRepInfo, 1810 -- Selected when Diffie-Hellman key exchange is 1811 -- used. 1812 encKeyPack [1] IMPLICIT OCTET STRING, 1813 -- Selected when public key encryption is used. 1814 -- Contains a CMS type ContentInfo encoded 1815 -- according to [RFC3852]. 1816 -- The contentType field of the type ContentInfo is 1817 -- id-envelopedData (1.2.840.113549.1.7.3). 1818 -- The content field is an EnvelopedData. 1819 -- The contentType field for the type EnvelopedData 1820 -- is id-signedData (1.2.840.113549.1.7.2). 1821 -- The eContentType field for the inner type 1822 -- SignedData (when unencrypted) is 1823 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 1824 -- eContent field contains the DER encoding of the 1825 -- type ReplyKeyPack. 1826 -- ReplyKeyPack is defined below. 1827 ... 1828 } 1829 1830 DHRepInfo ::= SEQUENCE { 1831 dhSignedData [0] IMPLICIT OCTET STRING, 1832 -- Contains a CMS type ContentInfo encoded according 1833 -- to [RFC3852]. 1834 -- The contentType field of the type ContentInfo is 1835 -- id-signedData (1.2.840.113549.1.7.2), and the 1836 -- content field is a SignedData. 1837 -- The eContentType field for the type SignedData is 1838 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 1839 -- eContent field contains the DER encoding of the 1840 -- type KDCDHKeyInfo. 1841 -- KDCDHKeyInfo is defined below. 1842 serverDHNonce [1] DHNonce OPTIONAL 1843 -- Present if and only if dhKeyExpiration is 1844 1845 1846 1847Zhu & Tung Expires June 2, 2006 [Page 33] 1848 1849Internet-Draft PKINIT November 2005 1850 1851 1852 -- present. 1853 } 1854 1855 KDCDHKeyInfo ::= SEQUENCE { 1856 subjectPublicKey [0] BIT STRING, 1857 -- The KDC's DH public key. 1858 -- The DH public key value is encoded as a BIT 1859 -- STRING according to [RFC3279]. 1860 nonce [1] INTEGER (0..4294967295), 1861 -- Contains the nonce in the pkAuthenticator field 1862 -- in the request if the DH keys are NOT reused, 1863 -- 0 otherwise. 1864 dhKeyExpiration [2] KerberosTime OPTIONAL, 1865 -- Expiration time for KDC's key pair, 1866 -- present if and only if the DH keys are reused. 1867 -- If present, the KDC's DH public key MUST not be 1868 -- used past the point of this expiration time. 1869 -- If this field is omitted then the serverDHNonce 1870 -- field MUST also be omitted. 1871 ... 1872 } 1873 1874 ReplyKeyPack ::= SEQUENCE { 1875 replyKey [0] EncryptionKey, 1876 -- Contains the session key used to encrypt the 1877 -- enc-part field in the AS-REP, i.e. the 1878 -- AS reply key. 1879 asChecksum [1] Checksum, 1880 -- Contains the checksum of the AS-REQ 1881 -- corresponding to the containing AS-REP. 1882 -- The checksum is performed over the type AS-REQ. 1883 -- The protocol key [RFC3961] of the checksum is the 1884 -- replyKey and the key usage number is 6. 1885 -- If the replyKey's enctype is "newer" [RFC4120] 1886 -- [RFC4121], the checksum is the required 1887 -- checksum operation [RFC3961] for that enctype. 1888 -- The client MUST verify this checksum upon receipt 1889 -- of the AS-REP. 1890 ... 1891 } 1892 1893 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1894 -- Each AlgorithmIdentifier specifies a set of 1895 -- Diffie-Hellman domain parameters [IEEE1363]. 1896 -- This list is in decreasing preference order. 1897 END 1898 1899 1900 1901 1902 1903Zhu & Tung Expires June 2, 2006 [Page 34] 1904 1905Internet-Draft PKINIT November 2005 1906 1907 1908Appendix B. Test Vectors 1909 1910 Function octetstring2key() is defined in Section 3.2.3.1. This 1911 section describes a few sets of test vectors that would be useful for 1912 implementers of octetstring2key(). 1913 1914 1915 Set 1 1916 ===== 1917 Input octet string x is: 1918 1919 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1920 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1921 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1922 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1923 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1924 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1925 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1926 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1927 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1928 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1929 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1931 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1932 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1933 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1934 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1935 1936 Output of K-truncate() when the key size is 32 octets: 1937 1938 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1939 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1940 1941 1942 Set 2: 1943 ===== 1944 Input octet string x is: 1945 1946 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1947 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1948 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1949 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1951 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1952 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1953 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1954 1955 Output of K-truncate() when the key size is 32 octets: 1956 1957 1958 1959Zhu & Tung Expires June 2, 2006 [Page 35] 1960 1961Internet-Draft PKINIT November 2005 1962 1963 1964 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1965 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1966 1967 1968 Set 3: 1969 ====== 1970 Input octet string x is: 1971 1972 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1973 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1974 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1975 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1976 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1977 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1978 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1979 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1980 1981 Output of K-truncate() when the key size is 32 octets: 1982 1983 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1984 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1985 1986 1987 Set 4: 1988 ===== 1989 Input octet string x is: 1990 1991 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1992 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1993 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1994 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1995 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1996 1997 Output of K-truncate() when the key size is 32 octets: 1998 1999 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 2000 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 2001 2002 2003Appendix C. Miscellaneous Information about Microsoft Windows PKINIT 2004 Implementations 2005 2006 Earlier revisions of the PKINIT I-D were implemented in various 2007 releases of Microsoft Windows and deployed in fairly large numbers. 2008 To enable the community to better interoperate with systems running 2009 those releases, the following information may be useful. 2010 2011 KDC certificates issued by Windows 2000 Enterprise CAs contain a 2012 2013 2014 2015Zhu & Tung Expires June 2, 2006 [Page 36] 2016 2017Internet-Draft PKINIT November 2005 2018 2019 2020 dNSName SAN with the DNS name of the host running the KDC, and the 2021 id-kp-serverAuth EKU [RFC3280]. 2022 2023 KDC certificates issued by Windows 2003 Enterprise CAs contain a 2024 dNSName SAN with the DNS name of the host running the KDC, the id-kp- 2025 serverAuth EKU and the id-ms-kp-sc-logon EKU. 2026 2027 It is anticipated that the next release of Windows is already too far 2028 along to allow it to support the issuing KDC certificates with id- 2029 pkinit-san SAN as specified in this RFC. Instead, they will have a 2030 dNSName SAN containing the domain name of the KDC and the intended 2031 purpose of these KDC certificates be restricted by the presence of 2032 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU. 2033 2034 In addition to checking that the above are present in a KDC 2035 certificate, Windows clients verify that the issuer of the KDC 2036 certificate is one of a set of allowed issuers of such certificates, 2037 so those wishing to issue KDC certificates need to configure their 2038 Windows clients appropriately. 2039 2040 Client certificates accepted by Windows 2000 and Windows 2003 Server 2041 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) 2042 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN 2043 contains a UTF8 encoded string whose value is that of the Directory 2044 Service attribute UserPrincipalName of the client account object, and 2045 the purpose of including the id-ms-san-sc-logon-upn SAN in the client 2046 certificate is to validate the client mapping (in other words, the 2047 client's public key is bound to the account that has this 2048 UserPrincipalName value). 2049 2050 It should be noted that all Microsoft Kerberos realm names are domain 2051 style realm names and strictly in upper case. In addition, the 2052 UserPrincipalName attribute is globally unique in Windows 2000 and 2053 Windows 2003. 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071Zhu & Tung Expires June 2, 2006 [Page 37] 2072 2073Internet-Draft PKINIT November 2005 2074 2075 2076Authors' Addresses 2077 2078 Larry Zhu 2079 Microsoft Corporation 2080 One Microsoft Way 2081 Redmond, WA 98052 2082 US 2083 2084 Email: lzhu@microsoft.com 2085 2086 2087 Brian Tung 2088 USC Information Sciences Institute 2089 4676 Admiralty Way Suite 1001 2090 Marina del Rey, CA 90292 2091 US 2092 2093 Email: brian@isi.edu 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127Zhu & Tung Expires June 2, 2006 [Page 38] 2128 2129Internet-Draft PKINIT November 2005 2130 2131 2132Intellectual Property Statement 2133 2134 The IETF takes no position regarding the validity or scope of any 2135 Intellectual Property Rights or other rights that might be claimed to 2136 pertain to the implementation or use of the technology described in 2137 this document or the extent to which any license under such rights 2138 might or might not be available; nor does it represent that it has 2139 made any independent effort to identify any such rights. Information 2140 on the procedures with respect to rights in RFC documents can be 2141 found in BCP 78 and BCP 79. 2142 2143 Copies of IPR disclosures made to the IETF Secretariat and any 2144 assurances of licenses to be made available, or the result of an 2145 attempt made to obtain a general license or permission for the use of 2146 such proprietary rights by implementers or users of this 2147 specification can be obtained from the IETF on-line IPR repository at 2148 http://www.ietf.org/ipr. 2149 2150 The IETF invites any interested party to bring to its attention any 2151 copyrights, patents or patent applications, or other proprietary 2152 rights that may cover technology that may be required to implement 2153 this standard. Please address the information to the IETF at 2154 ietf-ipr@ietf.org. 2155 2156 2157Disclaimer of Validity 2158 2159 This document and the information contained herein are provided on an 2160 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2161 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2162 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2163 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2164 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2165 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2166 2167 2168Copyright Statement 2169 2170 Copyright (C) The Internet Society (2005). This document is subject 2171 to the rights, licenses and restrictions contained in BCP 78, and 2172 except as set forth therein, the authors retain all their rights. 2173 2174 2175Acknowledgment 2176 2177 Funding for the RFC Editor function is currently provided by the 2178 Internet Society. 2179 2180 2181 2182 2183Zhu & Tung Expires June 2, 2006 [Page 39] 2184