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