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