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