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