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