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