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