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