1NETWORK WORKING GROUP B. Tung 2Internet-Draft USC Information Sciences Institute 3Expires: March 16, 2006 L. Zhu 4 Microsoft Corporation 5 September 12, 2005 6 7 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-28 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 March 16, 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 March 16, 2006 [Page 1] 53 54Internet-Draft PKINIT September 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 . . . . . . . . . . . . . . . . . . . . . . . 23 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 79 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25 80 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 82 Intellectual Property and Copyright Statements . . . . . . . . . . 34 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 March 16, 2006 [Page 2] 109 110Internet-Draft PKINIT September 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 151 1522. Conventions Used in This Document 153 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 157 158 Both the AS and the TGS are referred to as the KDC. 159 160 In this document, the encryption key used to encrypt the enc-part 161 162 163 164Tung & Zhu Expires March 16, 2006 [Page 3] 165 166Internet-Draft PKINIT September 2005 167 168 169 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS 170 reply key. 171 172 1733. Extensions 174 175 This section describes extensions to [RFC4120] for supporting the use 176 of public-key cryptography in the initial request for a ticket. 177 178 Briefly, this document defines the following extensions to [RFC4120]: 179 180 1. The client indicates the use of public-key authentication by 181 including a special preauthenticator in the initial request. This 182 preauthenticator contains the client's public-key data and a 183 signature. 184 185 2. The KDC tests the client's request against its authentication 186 policy and trusted Certification Authorities (CAs). 187 188 3. If the request passes the verification tests, the KDC replies as 189 usual, but the reply is encrypted using either: 190 191 a. a key generated through a Diffie-Hellman (DH) key exchange 192 [RFC2631] [IEEE1363] with the client, signed using the KDC's 193 signature key; or 194 195 b. a symmetric encryption key, signed using the KDC's signature 196 key and encrypted using the client's public key. 197 198 Any keying material required by the client to obtain the 199 encryption key for decrypting the KDC reply is returned in a pre- 200 authentication field accompanying the usual reply. 201 202 4. The client validates the KDC's signature, obtains the encryption 203 key, decrypts the reply, and then proceeds as usual. 204 205 Section 3.1 of this document enumerates the required algorithms and 206 necessary extension message types. Section 3.2 describes the 207 extension messages in greater detail. 208 2093.1. Definitions, Requirements, and Constants 210 2113.1.1. Required Algorithms 212 213 All PKINIT implementations MUST support the following algorithms: 214 215 216 217 218 219 220Tung & Zhu Expires March 16, 2006 [Page 4] 221 222Internet-Draft PKINIT September 2005 223 224 225 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 226 sha1-96 [RFC3962]. 227 228 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 229 230 o AS reply key delivery method: Diffie-Hellman key exchange 231 [RFC2631]. 232 233 In addition, implementations of this specification MUST be capable of 234 processing the Extended Key Usage (EKU) extension and the id-pksan 235 (as defined in Section 3.2.2) otherName of the Subject Alternative 236 Name (SAN) extension in X.509 certificates [RFC3280], if present. 237 2383.1.2. Defined Message and Encryption Types 239 240 PKINIT makes use of the following new pre-authentication types: 241 242 PA_PK_AS_REQ 16 243 PA_PK_AS_REP 17 244 245 PKINIT also makes use of the following new authorization data type: 246 247 AD_INITIAL_VERIFIED_CAS 9 248 249 PKINIT introduces the following new error codes: 250 251 KDC_ERR_CLIENT_NOT_TRUSTED 62 252 KDC_ERR_INVALID_SIG 64 253 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 254 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 255 KDC_ERR_INVALID_CERTIFICATE 71 256 KDC_ERR_REVOKED_CERTIFICATE 72 257 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 258 KDC_ERR_CLIENT_NAME_MISMATCH 75 259 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 260 261 PKINIT uses the following typed data types for errors: 262 263 TD_TRUSTED_CERTIFIERS 104 264 TD_INVALID_CERTIFICATES 105 265 TD_DH_PARAMETERS 109 266 267 PKINIT defines the following encryption types, for use in the AS-REQ 268 message to indicate acceptance of the corresponding algorithms that 269 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in 270 the reply: 271 272 273 274 275 276Tung & Zhu Expires March 16, 2006 [Page 5] 277 278Internet-Draft PKINIT September 2005 279 280 281 dsaWithSHA1-CmsOID 9 282 md5WithRSAEncryption-CmsOID 10 283 sha1WithRSAEncryption-CmsOID 11 284 rc2CBC-EnvOID 12 285 rsaEncryption-EnvOID (PKCS1 v1.5) 13 286 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 287 des-ede3-cbc-EnvOID 15 288 289 The ASN.1 module for all structures defined in this document (plus 290 IMPORT statements for all imported structures) is given in 291 Appendix A. 292 293 All structures defined in or imported into this document MUST be 294 encoded using Distinguished Encoding Rules (DER) [X690] (unless 295 otherwise noted). All data structures carried in OCTET STRINGs must 296 be encoded according to the rules specified in corresponding 297 specifications. 298 299 Interoperability note: Some implementations may not be able to decode 300 wrapped CMS objects encoded with BER but not DER; specifically, they 301 may not be able to decode infinite length encodings. To maximize 302 interoperability, implementers SHOULD encode CMS objects used in 303 PKINIT with DER. 304 3053.1.3. Algorithm Identifiers 306 307 PKINIT does not define, but does make use of, the following algorithm 308 identifiers. 309 310 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman 311 key agreement [RFC3279]: 312 313 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) 314 315 PKINIT uses the following signature algorithm identifiers [RFC3279]: 316 317 sha-1WithRSAEncryption (RSA with SHA1) 318 md5WithRSAEncryption (RSA with MD5) 319 id-dsa-with-sha1 (DSA with SHA1) 320 321 PKINIT uses the following encryption algorithm identifiers [RFC3447] 322 for encrypting the temporary key with a public key: 323 324 rsaEncryption (PKCS1 v1.5) 325 id-RSAES-OAEP (PKCS1 v2.0) 326 327 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 328 for encrypting the AS reply key with the temporary key: 329 330 331 332Tung & Zhu Expires March 16, 2006 [Page 6] 333 334Internet-Draft PKINIT September 2005 335 336 337 des-ede3-cbc (three-key 3DES, CBC mode) 338 rc2-cbc (RC2, CBC mode) 339 id-aes256-CBC (AES-256, CBC mode) 340 3413.2. PKINIT Pre-authentication Syntax and Use 342 343 This section defines the syntax and use of the various pre- 344 authentication fields employed by PKINIT. 345 3463.2.1. Generation of Client Request 347 348 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 349 in addition, a pre-authentication data element, whose padata-type is 350 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 351 type PA-PK-AS-REQ, is included. 352 353 PA-PK-AS-REQ ::= SEQUENCE { 354 signedAuthPack [0] IMPLICIT OCTET STRING, 355 -- Contains a CMS type ContentInfo encoded 356 -- according to [RFC3852]. 357 -- The contentType field of the type ContentInfo 358 -- is id-signedData (1.2.840.113549.1.7.2), 359 -- and the content field is a SignedData. 360 -- The eContentType field for the type SignedData is 361 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 362 -- eContent field contains the DER encoding of the 363 -- type AuthPack. 364 -- AuthPack is defined below. 365 trustedCertifiers [1] SEQUENCE OF 366 ExternalPrincipalIdentifier OPTIONAL, 367 -- A list of CAs, trusted by the client, that can 368 -- be used to certify the KDC. 369 -- Each ExternalPrincipalIdentifier identifies a CA 370 -- or a CA certificate (thereby its public key). 371 -- The information contained in the 372 -- trustedCertifiers SHOULD be used by the KDC as 373 -- hints to guide its selection of an appropriate 374 -- certificate chain to return to the client. 375 kdcPkId [2] IMPLICIT OCTET STRING 376 OPTIONAL, 377 -- Contains a CMS type SignerIdentifier encoded 378 -- according to [RFC3852]. 379 -- Identifies, if present, a particular KDC 380 -- public key that the client already has. 381 ... 382 } 383 384 DHNonce ::= OCTET STRING 385 386 387 388Tung & Zhu Expires March 16, 2006 [Page 7] 389 390Internet-Draft PKINIT September 2005 391 392 393 ExternalPrincipalIdentifier ::= SEQUENCE { 394 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 395 -- Contains a PKIX type Name encoded according to 396 -- [RFC3280]. 397 -- Identifies the certificate subject by the 398 -- distinguished subject name. 399 -- REQUIRED when there is a distinguished subject 400 -- name present in the certificate. 401 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 402 -- Contains a CMS type IssuerAndSerialNumber encoded 403 -- according to [RFC3852]. 404 -- Identifies a certificate of the subject. 405 -- REQUIRED for TD-INVALID-CERTIFICATES and 406 -- TD-TRUSTED-CERTIFIERS. 407 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 408 -- Identifies the subject's public key by a key 409 -- identifier. When an X.509 certificate is 410 -- referenced, this key identifier matches the X.509 411 -- subjectKeyIdentifier extension value. When other 412 -- certificate formats are referenced, the documents 413 -- that specify the certificate format and their use 414 -- with the CMS must include details on matching the 415 -- key identifier to the appropriate certificate 416 -- field. 417 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 418 ... 419 } 420 421 AuthPack ::= SEQUENCE { 422 pkAuthenticator [0] PKAuthenticator, 423 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 424 -- Type SubjectPublicKeyInfo is defined in 425 -- [RFC3280]. 426 -- Specifies Diffie-Hellman domain parameters 427 -- and the client's public key value [IEEE1363]. 428 -- The DH public key value is encoded as a BIT 429 -- STRING according to [RFC3279]. 430 -- This field is present only if the client wishes 431 -- to use the Diffie-Hellman key agreement method. 432 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 433 OPTIONAL, 434 -- Type AlgorithmIdentifier is defined in 435 -- [RFC3280]. 436 -- List of CMS encryption types supported by the 437 -- client in order of (decreasing) preference. 438 clientDHNonce [3] DHNonce OPTIONAL, 439 -- Present only if the client indicates that it 440 -- wishes to reuse DH keys or to allow the KDC to 441 442 443 444Tung & Zhu Expires March 16, 2006 [Page 8] 445 446Internet-Draft PKINIT September 2005 447 448 449 -- do so (see Section 3.2.3.1). 450 ... 451 } 452 453 PKAuthenticator ::= SEQUENCE { 454 cusec [0] INTEGER (0..999999), 455 ctime [1] KerberosTime, 456 -- cusec and ctime are used as in [RFC4120], for 457 -- replay prevention. 458 nonce [2] INTEGER (0..4294967295), 459 -- Chosen randomly; This nonce does not need to 460 -- match with the nonce in the KDC-REQ-BODY. 461 paChecksum [3] OCTET STRING, 462 -- Contains the SHA1 checksum, performed over 463 -- KDC-REQ-BODY. 464 ... 465 } 466 467 The ContentInfo [RFC3852] structure for the signedAuthPack field is 468 filled out as follows: 469 470 1. The contentType field of the type ContentInfo is id-signedData 471 (as defined in [RFC3852]), and the content field is a SignedData 472 (as defined in [RFC3852]). 473 474 2. The eContentType field for the type SignedData is id-pkauthdata: 475 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 476 pkinit(3) pkauthdata(1) }. 477 478 3. The eContent field for the type SignedData contains the DER 479 encoding of the type AuthPack. 480 481 4. The signerInfos field of the type SignedData contains a single 482 signerInfo, which contains the signature over the type AuthPack. 483 484 5. The certificates field of the type SignedData contains 485 certificates intended to facilitate certification path 486 construction, so that the KDC can verify the signature over the 487 type AuthPack. For path validation, these certificates SHOULD be 488 sufficient to construct at least one certification path from the 489 client certificate to one trust anchor acceptable by the KDC 490 [CAPATH]. The client MUST be capable of including such a set of 491 certificates if configured to do so. The certificates field MUST 492 NOT contain "root" CA certificates. 493 494 6. The client's Diffie-Hellman public value (clientPublicValue) is 495 included if and only if the client wishes to use the Diffie- 496 Hellman key agreement method. The Diffie-Hellman domain 497 498 499 500Tung & Zhu Expires March 16, 2006 [Page 9] 501 502Internet-Draft PKINIT September 2005 503 504 505 parameters [IEEE1363] for the client's public key are specified 506 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 507 and the client's Diffie-Hellman public key value is mapped to a 508 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 509 using the Diffie-Hellman key agreement method, implementations 510 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 511 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 512 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 513 group 16 [RFC3526]. 514 515 The Diffie-Hellman field size should be chosen so as to provide 516 sufficient cryptographic security [RFC3766]. 517 518 When MODP Diffie-Hellman is used, the exponents should have at 519 least twice as many bits as the symmetric keys that will be 520 derived from them [ODL99]. 521 522 7. The client may wish to reuse DH keys or to allow the KDC to do so 523 (see Section 3.2.3.1). If so, then the client includes the 524 clientDHNonce field. This nonce string needs to be as long as 525 the longest key length of the symmetric key types that the client 526 supports. This nonce MUST be chosen randomly. 527 528 5293.2.2. Receipt of Client Request 530 531 Upon receiving the client's request, the KDC validates it. This 532 section describes the steps that the KDC MUST (unless otherwise 533 noted) take in validating the request. 534 535 The KDC verifies the client's signature in the signedAuthPack field 536 according to [RFC3852]. 537 538 If, while validating the client's X.509 certificate [RFC3280], the 539 KDC cannot build a certification path to validate the client's 540 certificate, it sends back a KRB-ERROR [RFC4120] message with the 541 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 542 this error message is a TYPED-DATA (as defined in [RFC4120]) that 543 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 544 whose data-value contains the DER encoding of the type TD-TRUSTED- 545 CERTIFIERS: 546 547 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 548 ExternalPrincipalIdentifier 549 -- Identifies a list of CAs trusted by the KDC. 550 -- Each ExternalPrincipalIdentifier identifies a CA 551 -- or a CA certificate (thereby its public key). 552 553 554 555 556Tung & Zhu Expires March 16, 2006 [Page 10] 557 558Internet-Draft PKINIT September 2005 559 560 561 Upon receiving this error message, the client SHOULD retry only if it 562 has a different set of certificates (from those of the previous 563 requests) that form a certification path (or a partial path) from one 564 of the trust anchors acceptable by the KDC to its own certificate. 565 566 If, while processing the certification path, the KDC determines that 567 the signature on one of the certificates in the signedAuthPack field 568 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 569 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 570 message is a TYPED-DATA that contains an element whose data-type is 571 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 572 encoding of the type TD-INVALID-CERTIFICATES: 573 574 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 575 ExternalPrincipalIdentifier 576 -- Each ExternalPrincipalIdentifier identifies a 577 -- certificate (sent by the client) with an invalid 578 -- signature. 579 580 If more than one X.509 certificate signature is invalid, the KDC MAY 581 include one IssuerAndSerialNumber per invalid signature within the 582 TD-INVALID-CERTIFICATES. 583 584 The client's X.509 certificate is validated according to [RFC3280]. 585 586 Based on local policy, the KDC may also check whether any X.509 587 certificates in the certification path validating the client's 588 certificate have been revoked. If any of them have been revoked, the 589 KDC MUST return an error message with the code 590 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 591 revocation status but is unable to do so, it SHOULD return an error 592 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 593 certificate or certificates affected are identified exactly as for 594 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 595 596 Note that the TD_INVALID_CERTIFICATES error data is only used to 597 identify invalid certificates sent by the client in the request. 598 599 The client's public key is then used to verify the signature. If the 600 signature fails to verify, the KDC MUST return an error message with 601 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 602 this error message. 603 604 In addition to validating the client's signature, the KDC MUST also 605 check that the client's public key used to verify the client's 606 signature is bound to the client's principal name as specified in the 607 AS-REQ as follows: 608 609 610 611 612Tung & Zhu Expires March 16, 2006 [Page 11] 613 614Internet-Draft PKINIT September 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 March 16, 2006 [Page 12] 669 670Internet-Draft PKINIT September 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 March 16, 2006 [Page 13] 725 726Internet-Draft PKINIT September 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 March 16, 2006 [Page 14] 781 782Internet-Draft PKINIT September 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 according to [RFC3279]. 823 nonce [1] INTEGER (0..4294967295), 824 -- Contains the nonce in the PKAuthenticator of the 825 -- request if DH keys are NOT reused, 826 -- 0 otherwise. 827 dhKeyExpiration [2] KerberosTime OPTIONAL, 828 -- Expiration time for KDC's key pair, 829 -- present if and only if DH keys are reused. If 830 -- this field is omitted then the serverDHNonce 831 -- field MUST also be omitted. See Section 3.2.3.1. 832 ... 833 834 835 836Tung & Zhu Expires March 16, 2006 [Page 15] 837 838Internet-Draft PKINIT September 2005 839 840 841 } 842 8433.2.3.1. Using Diffie-Hellman Key Exchange 844 845 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 846 847 The ContentInfo [RFC3852] structure for the dhSignedData field is 848 filled in as follows: 849 850 1. The contentType field of the type ContentInfo is id-signedData 851 (as defined in [RFC3852]), and the content field is a SignedData 852 (as defined in [RFC3852]). 853 854 2. The eContentType field for the type SignedData is the OID value 855 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 856 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 857 858 3. The eContent field for the type SignedData contains the DER 859 encoding of the type KDCDHKeyInfo. 860 861 4. The signerInfos field of the type SignedData contains a single 862 signerInfo, which contains the signature over the type 863 KDCDHKeyInfo. 864 865 5. The certificates field of the type SignedData contains 866 certificates intended to facilitate certification path 867 construction, so that the client can verify the KDC's signature 868 over the type KDCDHKeyInfo. The information contained in the 869 trustedCertifiers in the request SHOULD be used by the KDC as 870 hints to guide its selection of an appropriate certificate chain 871 to return to the client. This field may only. be left empty if 872 the KDC public key specified by the kdcPkId field in the PA-PK- 873 AS-REQ was used for signing. Otherwise, for path validation, 874 these certificates SHOULD be sufficient to construct at least one 875 certification path from the KDC certificate to one trust anchor 876 acceptable by the client [CAPATH]. The KDC MUST be capable of 877 including such a set of certificates if configured to do so. The 878 certificates field MUST NOT contain "root" CA certificates. 879 880 6. If the client included the clientDHNonce field, then the KDC may 881 choose to reuse its DH keys (see Section 3.2.3.1). If the server 882 reuses DH keys then it MUST include an expiration time in the 883 dhKeyExpiration field. Past the point of the expiration time, 884 the signature over the type DHRepInfo is considered expired/ 885 invalid. When the server reuses DH keys then it MUST include a 886 serverDHNonce at least as long as the length of keys for the 887 symmetric encryption system used to encrypt the AS reply. Note 888 that including the serverDHNonce changes how the client and 889 890 891 892Tung & Zhu Expires March 16, 2006 [Page 16] 893 894Internet-Draft PKINIT September 2005 895 896 897 server calculate the key to use to encrypt the reply; see below 898 for details. The KDC SHOULD NOT reuse DH keys unless the 899 clientDHNonce field is present in the request. 900 901 The AS reply key is derived as follows: 902 903 1. Both the KDC and the client calculate the shared secret value as 904 follows: 905 906 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 907 shared secret value. DHSharedSecret is the value ZZ as 908 described in Section 2.1.1 of [RFC2631]. 909 910 DHSharedSecret is first padded with leading zeros such that the 911 size of DHSharedSecret in octets is the same as that of the 912 modulus, then represented as a string of octets in big-endian 913 order. 914 915 Implementation note: Both the client and the KDC can cache the 916 triple (ya, yb, DHSharedSecret), where ya is the client's public 917 key and yb is the KDC's public key. If both ya and yb are the 918 same in a later exchange, the cached DHSharedSecret can be used. 919 920 2. Let K be the key-generation seed length [RFC3961] of the AS reply 921 key whose enctype is selected according to [RFC4120]. 922 923 3. Define the function octetstring2key() as follows: 924 925 octetstring2key(x) == random-to-key(K-truncate( 926 SHA1(0x00 | x) | 927 SHA1(0x01 | x) | 928 SHA1(0x02 | x) | 929 ... 930 )) 931 932 where x is an octet string; | is the concatenation operator; 0x00, 933 0x01, 0x02, etc., are each represented as a single octet; random- 934 to-key() is an operation that generates a protocol key from a 935 bitstring of length K; and K-truncate truncates its input to the 936 first K bits. Both K and random-to-key() are as defined in the 937 kcrypto profile [RFC3961] for the enctype of the AS reply key. 938 939 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 940 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 941 strings. 942 943 944 945 946 947 948Tung & Zhu Expires March 16, 2006 [Page 17] 949 950Internet-Draft PKINIT September 2005 951 952 953 5. The AS reply key k is: 954 955 k = octetstring2key(DHSharedSecret | n_c | n_k) 956 9573.2.3.2. Using Public Key Encryption 958 959 In this case, the PA-PK-AS-REP contains a ContentInfo structure 960 wrapped in an OCTET STRING. The AS reply key is encrypted in the 961 encKeyPack field, which contains data of type ReplyKeyPack: 962 963 ReplyKeyPack ::= SEQUENCE { 964 replyKey [0] EncryptionKey, 965 -- Contains the session key used to encrypt the 966 -- enc-part field in the AS-REP. 967 asChecksum [1] Checksum, 968 -- Contains the checksum of the AS-REQ 969 -- corresponding to the containing AS-REP. 970 -- The checksum is performed over the type AS-REQ. 971 -- The protocol key [RFC3961] of the checksum is the 972 -- replyKey and the key usage number is 6. 973 -- If the replyKey's enctype is "newer" [RFC4120] 974 -- [RFC4121], the checksum is the required 975 -- checksum operation [RFC3961] for that enctype. 976 -- The client MUST verify this checksum upon receipt 977 -- of the AS-REP. 978 ... 979 } 980 981 The ContentInfo [RFC3852] structure for the encKeyPack field is 982 filled in as follows: 983 984 1. The contentType field of the type ContentInfo is id-envelopedData 985 (as defined in [RFC3852]), and the content field is an 986 EnvelopedData (as defined in [RFC3852]). 987 988 2. The contentType field for the type EnvelopedData is id- 989 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 990 pkcs (1) pkcs7 (7) signedData (2) }. 991 992 3. The eContentType field for the inner type SignedData (when 993 decrypted from the encryptedContent field for the type 994 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 995 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 996 997 4. The eContent field for the inner type SignedData contains the DER 998 encoding of the type ReplyKeyPack. 999 1000 1001 1002 1003 1004Tung & Zhu Expires March 16, 2006 [Page 18] 1005 1006Internet-Draft PKINIT September 2005 1007 1008 1009 5. The signerInfos field of the inner type SignedData contains a 1010 single signerInfo, which contains the signature over the type 1011 ReplyKeyPack. 1012 1013 6. The certificates field of the inner type SignedData contains 1014 certificates intended to facilitate certification path 1015 construction, so that the client can verify the KDC's signature 1016 over the type ReplyKeyPack. The information contained in the 1017 trustedCertifiers in the request SHOULD be used by the KDC as 1018 hints to guide its selection of an appropriate certificate chain 1019 to return to the client. This field may only be left empty if 1020 the KDC public key specified by the kdcPkId field in the PA-PK- 1021 AS-REQ was used for signing. Otherwise, for path validation, 1022 these certificates SHOULD be sufficient to construct at least one 1023 certification path from the KDC certificate to one trust anchor 1024 acceptable by the client [CAPATH]. The KDC MUST be capable of 1025 including such a set of certificates if configured to do so. The 1026 certificates field MUST NOT contain "root" CA certificates. 1027 1028 7. The recipientInfos field of the type EnvelopedData is a SET which 1029 MUST contain exactly one member of type KeyTransRecipientInfo. 1030 The encryptedKey of this member contains the temporary key which 1031 is encrypted using the client's public key. 1032 1033 8. The unprotectedAttrs or originatorInfo fields of the type 1034 EnvelopedData MAY be present. 1035 1036 Implementations of this RSA encryption key delivery method are 1037 RECOMMENDED to support for RSA keys at least 2048 bits in size. 1038 10393.2.4. Receipt of KDC Reply 1040 1041 Upon receipt of the KDC's reply, the client proceeds as follows. If 1042 the PA-PK-AS-REP contains the dhSignedData field, the client derives 1043 the AS reply key using the same procedure used by the KDC as defined 1044 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 1045 field, and the client decrypts and extracts the temporary key in the 1046 encryptedKey field of the member KeyTransRecipientInfo, and then uses 1047 that as the AS reply key. 1048 1049 If the public key encrytion method is used, the client MUST verify 1050 the asChecksum contained in the ReplyKeyPack. 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 March 16, 2006 [Page 19] 1061 1062Internet-Draft PKINIT September 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 Unless the client knows by some other means that the KDC certificate 1072 is intended for a Kerberos KDC, the client MUST require that the KDC 1073 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: 1074 1075 id-pkkdcekuoid OBJECT IDENTIFIER ::= 1076 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1077 pkinit(3) pkkdcekuoid(5) } 1078 -- Signing KDC responses. 1079 -- Key usage bits that MUST be consistent: 1080 -- digitalSignature. 1081 1082 If the KDC certificate contains the Kerberos TGS name encoded as an 1083 id-pksan SAN, this certificate is certified by the issuing CA as a 1084 KDC certificate, therefore the id-pkkdcekuoid EKU is not required. 1085 1086 If all applicable checks are satisfied, the client then decrypts the 1087 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 1088 and then proceeds as described in [RFC4120]. 1089 1090 Implementation note: CAs issuing KDC certificates SHOULD place all 1091 "short" and "fully-qualified" Kerberos realm names of the KDC (one 1092 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 1093 flexibility. 1094 10953.3. Interoperability Requirements 1096 1097 The client MUST be capable of sending a set of certificates 1098 sufficient to allow the KDC to construct a certification path for the 1099 client's certificate, if the correct set of certificates is provided 1100 through configuration or policy. 1101 1102 If the client sends all the X.509 certificates on a certification 1103 path to a trust anchor acceptable by the KDC, and the KDC can not 1104 verify the client's public key otherwise, the KDC MUST be able to 1105 process path validation for the client's certificate based on the 1106 certificates in the request. 1107 1108 The KDC MUST be capable of sending a set of certificates sufficient 1109 to allow the client to construct a certification path for the KDC's 1110 certificate, if the correct set of certificates is provided through 1111 configuration or policy. 1112 1113 1114 1115 1116Tung & Zhu Expires March 16, 2006 [Page 20] 1117 1118Internet-Draft PKINIT September 2005 1119 1120 1121 If the KDC sends all the X.509 certificates on a certification path 1122 to a trust anchor acceptable by the client, and the client can not 1123 verify the KDC's public key otherwise, the client MUST be able to 1124 process path validation for the KDC's certificate based on the 1125 certificates in the reply. 1126 11273.4. KDC Indication of PKINIT Support 1128 1129 If pre-authentication is required, but was not present in the 1130 request, per [RFC4120] an error message with the code 1131 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 1132 stored in the e-data field of the KRB-ERROR message to specify which 1133 pre-authentication mechanisms are acceptable. The KDC can then 1134 indicate the support of PKINIT by including an empty element whose 1135 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 1136 1137 Otherwise if it is required by the KDC's local policy that the client 1138 must be pre-authenticated using the pre-authentication mechanism 1139 specified in this document, but no PKINIT pre-authentication was 1140 present in the request, an error message with the code 1141 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 1142 1143 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 1144 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 1145 STRING), and clients MUST ignore this and any other value. Future 1146 extensions to this protocol may specify other data to send instead of 1147 an empty OCTET STRING. 1148 1149 11504. Security Considerations 1151 1152 The symmetric reply key size and Diffie-Hellman field size or RSA 1153 modulus size should be chosen so as to provide sufficient 1154 cryptographic security [RFC3766]. 1155 1156 When MODP Diffie-Hellman is used, the exponents should have at least 1157 twice as many bits as the symmetric keys that will be derived from 1158 them [ODL99]. 1159 1160 PKINIT raises certain security considerations beyond those that can 1161 be regulated strictly in protocol definitions. We will address them 1162 in this section. 1163 1164 PKINIT extends the cross-realm model to the public-key 1165 infrastructure. Users of PKINIT must understand security policies 1166 and procedures appropriate to the use of Public Key Infrastructures 1167 [RFC3280]. 1168 1169 1170 1171 1172Tung & Zhu Expires March 16, 2006 [Page 21] 1173 1174Internet-Draft PKINIT September 2005 1175 1176 1177 In order to trust a KDC certificate that is certified by a CA as a 1178 KDC certificate for a target realm (for example, by asserting the TGS 1179 name of that Kerberos realm as an id-pksan SAN and/or restricting the 1180 certificate usage by using the id-pkkdcekuoid EKU, as described in 1181 Section 3.2.4), the client MUST verify that the KDC certificate's 1182 issuing CA is authorized to issue KDC certificates for that target 1183 realm. Otherwise, the binding between the KDC certificate and the 1184 KDC of the target realm is not established. 1185 1186 How to validate this authorization is a matter of local policy. A 1187 way to achieve this is the configuration of specific sets of 1188 intermediary CAs and trust anchors, one of which must be on the KDC 1189 certificate's certification path [RFC3280]; and for each CA or trust 1190 anchor the realms for which it is allowed to issue certificates. 1191 1192 In addition, if any CA is trusted to issue KDC certificates can also 1193 issue other kinds of certificates, then local policy must be able to 1194 distinguish between them: for example, it could require that KDC 1195 certificates contain the id-pkkdcekuoid EKU or that the realm be 1196 specified with the id-pksan SAN. 1197 1198 It is the responsibility of the PKI administrators for an 1199 organization to ensure that KDC certificates are only issued to KDCs, 1200 and that clients can ascertain this using their local policy. 1201 1202 Standard Kerberos allows the possibility of interactions between 1203 cryptosystems of varying strengths; this document adds interactions 1204 with public-key cryptosystems to Kerberos. Some administrative 1205 policies may allow the use of relatively weak public keys. Using 1206 such keys to wrap data encrypted under stronger conventional 1207 cryptosystems may be inappropriate. 1208 1209 PKINIT requires keys for symmetric cryptosystems to be generated. 1210 Some such systems contain "weak" keys. For recommendations regarding 1211 these weak keys, see [RFC4120]. 1212 1213 PKINIT allows the use of the same RSA key pair for encryption and 1214 signing when doing RSA encryption based key delivery. This is not 1215 recommended usage of RSA keys [RFC3447], by using DH based key 1216 delivery this is avoided. 1217 1218 Care should be taken in how certificates are chosen for the purposes 1219 of authentication using PKINIT. Some local policies may require that 1220 key escrow be used for certain certificate types. Deployers of 1221 PKINIT should be aware of the implications of using certificates that 1222 have escrowed keys for the purposes of authentication. Because 1223 signing only certificates are normally not escrowed, by using DH 1224 based key delivery this is avoided. 1225 1226 1227 1228Tung & Zhu Expires March 16, 2006 [Page 22] 1229 1230Internet-Draft PKINIT September 2005 1231 1232 1233 PKINIT does not provide for a "return routability" test to prevent 1234 attackers from mounting a denial-of-service attack on the KDC by 1235 causing it to perform unnecessary and expensive public-key 1236 operations. Strictly speaking, this is also true of standard 1237 Kerberos, although the potential cost is not as great, because 1238 standard Kerberos does not make use of public-key cryptography. By 1239 using DH based key delivery and reusing DH keys, the necessary crypto 1240 processing cost per request can be minimized. 1241 1242 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1243 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1244 be used if the KDC itself vouches for the user's certificate. 1245 1246 12475. Acknowledgements 1248 1249 The following people have made significant contributions to this 1250 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist 1251 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 1252 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik 1253 Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and 1254 Aaron D. Jaggard. 1255 1256 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1257 Jonathan Trostle who wrote earlier versions of this document. 1258 1259 The authors are indebted to the Kerberos working group chair Jeffrey 1260 Hutzelman who kept track of various issues and was enormously helpful 1261 during the creation of this document. 1262 1263 Some of the ideas on which this document is based arose during 1264 discussions over several years between members of the SAAG, the IETF 1265 CAT working group, and the PSRG, regarding integration of Kerberos 1266 and SPX. Some ideas have also been drawn from the DASS system. 1267 These changes are by no means endorsed by these groups. This is an 1268 attempt to revive some of the goals of those groups, and this 1269 document approaches those goals primarily from the Kerberos 1270 perspective. 1271 1272 Lastly, comments from groups working on similar ideas in DCE have 1273 been invaluable. 1274 1275 12766. IANA Considerations 1277 1278 This document has no actions for IANA. 1279 1280 1281 1282 1283 1284Tung & Zhu Expires March 16, 2006 [Page 23] 1285 1286Internet-Draft PKINIT September 2005 1287 1288 12897. References 1290 12917.1. Normative References 1292 1293 [IEEE1363] 1294 IEEE, "Standard Specifications for Public Key 1295 Cryptography", IEEE 1363, 2000. 1296 1297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1298 Requirement Levels", BCP 14, RFC 2119, March 1997. 1299 1300 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1301 RFC 2412, November 1998. 1302 1303 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1304 RFC 2631, June 1999. 1305 1306 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1307 Identifiers for the Internet X.509 Public Key 1308 Infrastructure Certificate and Certificate Revocation List 1309 (CRL) Profile", RFC 3279, April 2002. 1310 1311 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1312 X.509 Public Key Infrastructure Certificate and 1313 Certificate Revocation List (CRL) Profile", RFC 3280, 1314 April 2002. 1315 1316 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1317 Algorithms", RFC 3370, August 2002. 1318 1319 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1320 Standards (PKCS) #1: RSA Cryptography Specifications 1321 Version 2.1", RFC 3447, February 2003. 1322 1323 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1324 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1325 RFC 3526, May 2003. 1326 1327 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1328 Encryption Algorithm in Cryptographic Message Syntax 1329 (CMS)", RFC 3565, July 2003. 1330 1331 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1332 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1333 RFC 3766, April 2004. 1334 1335 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1336 RFC 3852, July 2004. 1337 1338 1339 1340Tung & Zhu Expires March 16, 2006 [Page 24] 1341 1342Internet-Draft PKINIT September 2005 1343 1344 1345 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1346 Kerberos 5", RFC 3961, February 2005. 1347 1348 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1349 Encryption for Kerberos 5", RFC 3962, February 2005. 1350 1351 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1352 Kerberos Network Authentication Service (V5)", RFC 4120, 1353 July 2005. 1354 1355 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1356 Version 5 Generic Security Service Application Program 1357 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1358 July 2005. 1359 1360 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication 1361 Framework. 1997. 1362 1363 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1364 Rules (BER), Canonical Encoding Rules (CER) and 1365 Distinguished Encoding Rules (DER), ITU-T Recommendation 1366 X.690 (1997) | ISO/IEC International Standard 1367 8825-1:1998. 1368 13697.2. Informative References 1370 1371 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1372 pkix-certpathbuild. Work in Progress. 1373 1374 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1375 Sizes", Journal of Cryptology 14 (2001) 255-293. 1376 1377 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1378 future, Designs, Codes, and Cryptography (1999)". 1379 1380Appendix A. PKINIT ASN.1 Module 1381 1382 KerberosV5-PK-INIT-SPEC { 1383 iso(1) identified-organization(3) dod(6) internet(1) 1384 security(5) kerberosV5(2) modules(4) pkinit(5) 1385 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1386 1387 IMPORTS 1388 1389 1390 1391Tung & Zhu Expires March 16, 2006 [Page 25] 1392 1393Internet-Draft PKINIT September 2005 1394 1395 1396 SubjectPublicKeyInfo, AlgorithmIdentifier 1397 FROM PKIX1Explicit88 { iso (1) 1398 identified-organization (3) dod (6) internet (1) 1399 security (5) mechanisms (5) pkix (7) id-mod (0) 1400 id-pkix1-explicit (18) } 1401 -- As defined in RFC 3280. 1402 1403 KerberosTime, PrincipalName, Realm, EncryptionKey 1404 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1405 dod(6) internet(1) security(5) kerberosV5(2) 1406 modules(4) krb5spec2(2) } ; 1407 1408 id-pkinit OBJECT IDENTIFIER ::= 1409 { iso (1) org (3) dod (6) internet (1) security (5) 1410 kerberosv5 (2) pkinit (3) } 1411 1412 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1413 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1414 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1415 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1416 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1417 1418 id-pksan OBJECT IDENTIFIER ::= 1419 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1420 x509-sanan (2) } 1421 1422 pa-pk-as-req INTEGER ::= 16 1423 pa-pk-as-rep INTEGER ::= 17 1424 1425 ad-initial-verified-cas INTEGER ::= 9 1426 1427 td-trusted-certifiers INTEGER ::= 104 1428 td-invalid-certificates INTEGER ::= 105 1429 td-dh-parameters INTEGER ::= 109 1430 1431 PA-PK-AS-REQ ::= SEQUENCE { 1432 signedAuthPack [0] IMPLICIT OCTET STRING, 1433 -- Contains a CMS type ContentInfo encoded 1434 -- according to [RFC3852]. 1435 -- The contentType field of the type ContentInfo 1436 -- is id-signedData (1.2.840.113549.1.7.2), 1437 -- and the content field is a SignedData. 1438 -- The eContentType field for the type SignedData is 1439 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1440 -- eContent field contains the DER encoding of the 1441 -- type AuthPack. 1442 -- AuthPack is defined below. 1443 trustedCertifiers [1] SEQUENCE OF 1444 1445 1446 1447Tung & Zhu Expires March 16, 2006 [Page 26] 1448 1449Internet-Draft PKINIT September 2005 1450 1451 1452 ExternalPrincipalIdentifier OPTIONAL, 1453 -- A list of CAs, trusted by the client, that can 1454 -- be used to certify the KDC. 1455 -- Each ExternalPrincipalIdentifier identifies a CA 1456 -- or a CA certificate (thereby its public key). 1457 -- The information contained in the 1458 -- trustedCertifiers SHOULD be used by the KDC as 1459 -- hints to guide its selection of an appropriate 1460 -- certificate chain to return to the client. 1461 kdcPkId [2] IMPLICIT OCTET STRING 1462 OPTIONAL, 1463 -- Contains a CMS type SignerIdentifier encoded 1464 -- according to [RFC3852]. 1465 -- Identifies, if present, a particular KDC 1466 -- public key that the client already has. 1467 ... 1468 } 1469 1470 DHNonce ::= OCTET STRING 1471 1472 ExternalPrincipalIdentifier ::= SEQUENCE { 1473 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1474 -- Contains a PKIX type Name encoded according to 1475 -- [RFC3280]. 1476 -- Identifies the certificate subject by the 1477 -- distinguished subject name. 1478 -- REQUIRED when there is a distinguished subject 1479 -- name present in the certificate. 1480 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1481 -- Contains a CMS type IssuerAndSerialNumber encoded 1482 -- according to [RFC3852]. 1483 -- Identifies a certificate of the subject. 1484 -- REQUIRED for TD-INVALID-CERTIFICATES and 1485 -- TD-TRUSTED-CERTIFIERS. 1486 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1487 -- Identifies the subject's public key by a key 1488 -- identifier. When an X.509 certificate is 1489 -- referenced, this key identifier matches the X.509 1490 -- subjectKeyIdentifier extension value. When other 1491 -- certificate formats are referenced, the documents 1492 -- that specify the certificate format and their use 1493 -- with the CMS must include details on matching the 1494 -- key identifier to the appropriate certificate 1495 -- field. 1496 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1497 ... 1498 } 1499 1500 1501 1502 1503Tung & Zhu Expires March 16, 2006 [Page 27] 1504 1505Internet-Draft PKINIT September 2005 1506 1507 1508 AuthPack ::= SEQUENCE { 1509 pkAuthenticator [0] PKAuthenticator, 1510 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1511 -- Type SubjectPublicKeyInfo is defined in 1512 -- [RFC3280]. 1513 -- Specifies Diffie-Hellman domain parameters 1514 -- and the client's public key value [IEEE1363]. 1515 -- The DH public key value is encoded as a BIT 1516 -- STRING according to [RFC3279]. 1517 -- This field is present only if the client wishes 1518 -- to use the Diffie-Hellman key agreement method. 1519 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1520 OPTIONAL, 1521 -- Type AlgorithmIdentifier is defined in 1522 -- [RFC3280]. 1523 -- List of CMS encryption types supported by the 1524 -- client in order of (decreasing) preference. 1525 clientDHNonce [3] DHNonce OPTIONAL, 1526 -- Present only if the client indicates that it 1527 -- wishes to reuse DH keys or to allow the KDC to 1528 -- do so. 1529 ... 1530 } 1531 1532 PKAuthenticator ::= SEQUENCE { 1533 cusec [0] INTEGER (0..999999), 1534 ctime [1] KerberosTime, 1535 -- cusec and ctime are used as in [RFC4120], for 1536 -- replay prevention. 1537 nonce [2] INTEGER (0..4294967295), 1538 -- Chosen randomly; This nonce does not need to 1539 -- match with the nonce in the KDC-REQ-BODY. 1540 paChecksum [3] OCTET STRING, 1541 -- Contains the SHA1 checksum, performed over 1542 -- KDC-REQ-BODY. 1543 ... 1544 } 1545 1546 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1547 ExternalPrincipalIdentifier 1548 -- Identifies a list of CAs trusted by the KDC. 1549 -- Each ExternalPrincipalIdentifier identifies a CA 1550 -- or a CA certificate (thereby its public key). 1551 1552 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1553 ExternalPrincipalIdentifier 1554 -- Each ExternalPrincipalIdentifier identifies a 1555 -- certificate (sent by the client) with an invalid 1556 1557 1558 1559Tung & Zhu Expires March 16, 2006 [Page 28] 1560 1561Internet-Draft PKINIT September 2005 1562 1563 1564 -- signature. 1565 1566 KRB5PrincipalName ::= SEQUENCE { 1567 realm [0] Realm, 1568 principalName [1] PrincipalName 1569 } 1570 1571 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1572 ExternalPrincipalIdentifier 1573 -- Identifies the certification path based on which 1574 -- the client certificate was validated. 1575 -- Each ExternalPrincipalIdentifier identifies a CA 1576 -- or a CA certificate (thereby its public key). 1577 1578 PA-PK-AS-REP ::= CHOICE { 1579 dhInfo [0] DHRepInfo, 1580 -- Selected when Diffie-Hellman key exchange is 1581 -- used. 1582 encKeyPack [1] IMPLICIT OCTET STRING, 1583 -- Selected when public key encryption is used. 1584 -- Contains a CMS type ContentInfo encoded 1585 -- according to [RFC3852]. 1586 -- The contentType field of the type ContentInfo is 1587 -- id-envelopedData (1.2.840.113549.1.7.3). 1588 -- The content field is an EnvelopedData. 1589 -- The contentType field for the type EnvelopedData 1590 -- is id-signedData (1.2.840.113549.1.7.2). 1591 -- The eContentType field for the inner type 1592 -- SignedData (when unencrypted) is id-pkrkeydata 1593 -- (1.2.840.113549.1.7.3) and the eContent field 1594 -- contains the DER encoding of the type 1595 -- ReplyKeyPack. 1596 -- ReplyKeyPack is defined below. 1597 ... 1598 } 1599 1600 DHRepInfo ::= SEQUENCE { 1601 dhSignedData [0] IMPLICIT OCTET STRING, 1602 -- Contains a CMS type ContentInfo encoded according 1603 -- to [RFC3852]. 1604 -- The contentType field of the type ContentInfo is 1605 -- id-signedData (1.2.840.113549.1.7.2), and the 1606 -- content field is a SignedData. 1607 -- The eContentType field for the type SignedData is 1608 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1609 -- eContent field contains the DER encoding of the 1610 -- type KDCDHKeyInfo. 1611 -- KDCDHKeyInfo is defined below. 1612 1613 1614 1615Tung & Zhu Expires March 16, 2006 [Page 29] 1616 1617Internet-Draft PKINIT September 2005 1618 1619 1620 serverDHNonce [1] DHNonce OPTIONAL 1621 -- Present if and only if dhKeyExpiration is 1622 -- present. 1623 } 1624 1625 KDCDHKeyInfo ::= SEQUENCE { 1626 subjectPublicKey [0] BIT STRING, 1627 -- KDC's DH public key. 1628 -- The DH public key value is encoded as a BIT 1629 -- STRING according to [RFC3279]. 1630 nonce [1] INTEGER (0..4294967295), 1631 -- Contains the nonce in the PKAuthenticator of the 1632 -- request if DH keys are NOT reused, 1633 -- 0 otherwise. 1634 dhKeyExpiration [2] KerberosTime OPTIONAL, 1635 -- Expiration time for KDC's key pair, 1636 -- present if and only if DH keys are reused. If 1637 -- this field is omitted then the serverDHNonce 1638 -- field MUST also be omitted. 1639 ... 1640 } 1641 1642 ReplyKeyPack ::= SEQUENCE { 1643 replyKey [0] EncryptionKey, 1644 -- Contains the session key used to encrypt the 1645 -- enc-part field in the AS-REP. 1646 asChecksum [1] Checksum, 1647 -- Contains the checksum of the AS-REQ 1648 -- corresponding to the containing AS-REP. 1649 -- The checksum is performed over the type AS-REQ. 1650 -- The protocol key [RFC3961] of the checksum is the 1651 -- replyKey and the key usage number is 6. 1652 -- If the replyKey's enctype is "newer" [RFC4120] 1653 -- [RFC4121], the checksum is the required 1654 -- checksum operation [RFC3961] for that enctype. 1655 -- The client MUST verify this checksum upon receipt 1656 -- of the AS-REP. 1657 ... 1658 } 1659 1660 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1661 -- Each AlgorithmIdentifier specifies a set of 1662 -- Diffie-Hellman domain parameters [IEEE1363]. 1663 -- This list is in decreasing preference order. 1664 END 1665 1666 1667 1668 1669 1670 1671Tung & Zhu Expires March 16, 2006 [Page 30] 1672 1673Internet-Draft PKINIT September 2005 1674 1675 1676Appendix B. Test Vectors 1677 1678 Function octetstring2key() is defined in Section 3.2.3.1. This 1679 section describes a few sets of test vectors that would be useful for 1680 implementers of octetstring2key(). 1681 1682 1683 Set 1 1684 ===== 1685 Input octet string x is: 1686 1687 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1688 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1689 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1691 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1692 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1693 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1694 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1695 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1696 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1697 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1698 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1699 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1701 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1702 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1703 1704 Output of K-truncate() when the key size is 32 octets: 1705 1706 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1707 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1708 1709 1710 Set 2: 1711 ===== 1712 Input octet string x is: 1713 1714 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1715 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1716 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1717 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1718 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1719 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1721 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1722 1723 Output of K-truncate() when the key size is 32 octets: 1724 1725 1726 1727Tung & Zhu Expires March 16, 2006 [Page 31] 1728 1729Internet-Draft PKINIT September 2005 1730 1731 1732 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1733 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1734 1735 1736 Set 3: 1737 ====== 1738 Input octet string x is: 1739 1740 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1741 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1742 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1743 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1744 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1745 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1746 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1747 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1748 1749 Output of K-truncate() when the key size is 32 octets: 1750 1751 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1752 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1753 1754 1755 Set 4: 1756 ===== 1757 Input octet string x is: 1758 1759 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1760 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1761 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1762 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1763 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1764 1765 Output of K-truncate() when the key size is 32 octets: 1766 1767 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 1768 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783Tung & Zhu Expires March 16, 2006 [Page 32] 1784 1785Internet-Draft PKINIT September 2005 1786 1787 1788Authors' Addresses 1789 1790 Brian Tung 1791 USC Information Sciences Institute 1792 4676 Admiralty Way Suite 1001, Marina del Rey CA 1793 Marina del Rey, CA 90292 1794 US 1795 1796 Email: brian@isi.edu 1797 1798 1799 Larry Zhu 1800 Microsoft Corporation 1801 One Microsoft Way 1802 Redmond, WA 98052 1803 US 1804 1805 Email: lzhu@microsoft.com 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839Tung & Zhu Expires March 16, 2006 [Page 33] 1840 1841Internet-Draft PKINIT September 2005 1842 1843 1844Intellectual Property Statement 1845 1846 The IETF takes no position regarding the validity or scope of any 1847 Intellectual Property Rights or other rights that might be claimed to 1848 pertain to the implementation or use of the technology described in 1849 this document or the extent to which any license under such rights 1850 might or might not be available; nor does it represent that it has 1851 made any independent effort to identify any such rights. Information 1852 on the procedures with respect to rights in RFC documents can be 1853 found in BCP 78 and BCP 79. 1854 1855 Copies of IPR disclosures made to the IETF Secretariat and any 1856 assurances of licenses to be made available, or the result of an 1857 attempt made to obtain a general license or permission for the use of 1858 such proprietary rights by implementers or users of this 1859 specification can be obtained from the IETF on-line IPR repository at 1860 http://www.ietf.org/ipr. 1861 1862 The IETF invites any interested party to bring to its attention any 1863 copyrights, patents or patent applications, or other proprietary 1864 rights that may cover technology that may be required to implement 1865 this standard. Please address the information to the IETF at 1866 ietf-ipr@ietf.org. 1867 1868 1869Disclaimer of Validity 1870 1871 This document and the information contained herein are provided on an 1872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1878 1879 1880Copyright Statement 1881 1882 Copyright (C) The Internet Society (2005). This document is subject 1883 to the rights, licenses and restrictions contained in BCP 78, and 1884 except as set forth therein, the authors retain all their rights. 1885 1886 1887Acknowledgment 1888 1889 Funding for the RFC Editor function is currently provided by the 1890 Internet Society. 1891 1892 1893 1894 1895Tung & Zhu Expires March 16, 2006 [Page 34] 1896 1897 1898