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