1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-19.txt Clifford Neuman 3Updates: RFC 1510bis USC/ISI 4expires September 30, 2004 Matthew Hur 5 Ari Medvinsky 6 Microsoft Corporation 7 Sasha Medvinsky 8 Motorola, Inc. 9 John Wray 10 Iris Associates, Inc. 11 Jonathan Trostle 12 13 14 Public Key Cryptography for Initial Authentication in Kerberos 15 16 170. Status Of This Memo 18 19 20This document is an Internet-Draft and is in full conformance with 21all provision of Section 10 of RFC 2026. Internet-Drafts are 22working documents of the Internet Engineering Task Force (IETF), its 23areas, and its working groups. Note that other groups may also 24distribute working documents as Internet-Drafts. 25 26 27Internet-Drafts are draft documents valid for a maximum of six 28months and may be updated, replaced, or obsoleted by other documents 29at any time. It is inappropriate to use Internet-Drafts as 30reference material or to cite them other than as "work in progress." 31 32 33The list of current Internet-Drafts can be accessed at 34http://www.ietf.org/ietf/1id-abstracts.txt 35 36 37The list of Internet-Draft Shadow Directories can be accessed at 38http://www.ietf.org/shadow.html 39 40 41The distribution of this memo is unlimited. It is filed as 42draft-ietf-cat-kerberos-pk-init-19.txt and expires September 30, 432004. Please send comments to the authors. 44 45 46 471. Abstract 48 49 50This document describes protocol extensions (hereafter called PKINIT) 51to the Kerberos protocol specification (RFC 1510bis [1]). These 52extensions provide a method for integrating public key cryptography 53into the initial authentication exchange, by passing digital 54certificates and associated authenticators in preauthentication data 55fields. 56 57 58 592. Introduction 60 61 62A client typically authenticates itself to a service in Kerberos 63using three distinct though related exchanges. First, the client 64requests a ticket-granting ticket (TGT) from the Kerberos 65authentication server (AS). Then, it uses the TGT to request a 66service ticket from the Kerberos ticket-granting server (TGS). 67Usually, the AS and TGS are integrated in a single device known as 68a Kerberos Key Distribution Center, or KDC. (In this document, we will 69refer to both the AS and the TGS as the KDC.) Finally, the client 70uses the service ticket to authenticate itself to the service. 71 72 73The advantage afforded by the TGT is that the client need 74explicitly request a ticket and expose his credentials only once. The 75TGT and its associated session key can then be used for any 76subsequent requests. One result of this is that all further 77authentication is independent of the method by which the initial 78authentication was performed. Consequently, initial authentication 79provides a convenient place to integrate public-key cryptography 80into Kerberos authentication. 81 82 83As defined, Kerberos authentication exchanges use symmetric-key 84cryptography, in part for performance. One cost of using 85symmetric-key cryptography is that the keys must be shared, so that 86before a client can authenticate itself, he must already be 87registered with the KDC. 88 89 90Conversely, public-key cryptography (in conjunction with an 91established Public Key Infrastructure) permits authentication 92without prior registration with a KDC. Adding it to Kerberos allows the 93widespread use of Kerberized applications by clients without requiring 94them to register first with a KDC: a requirement that has no inherent 95security benefit. 96 97 98As noted above, a convenient and efficient place to introduce 99public-key cryptography into Kerberos is in the initial 100authentication exchange. This document describes the methods and 101data formats for integrating public-key cryptography into Kerberos 102initial authentication. 103 104 105 1063. Extensions 107 108 109This section describes extensions to RFC 1510bis for supporting the 110use of public-key cryptography in the initial request for a ticket. 111 112 113Briefly, this document defines the following extensions to RFC 1510bis: 114 115 116 1. The client indicates the use of public-key authentication by 117 including a special preauthenticator in the initial request. 118 This preauthenticator contains the client's public-key data 119 and a signature. 120 121 1222. 2. The KDC tests the client's request against its policy and 123 trusted Certification Authorities (CAs). 124 125 126 3. If the request passes the verification tests, the KDC 127 replies as usual, but the reply is encrypted using either: 128 129 130 a. a symmetric encryption key, signed using the KDC?s 131 signature key and encrypted using the client?s encryption 132 key; or 133 134 135 b. a key generated through a Diffie-Hellman exchange with 136 the client, signed using the KDC's signature key. 137 138 139 Any keying material required by the client to obtain the 140 Encryption key is returned in a preauthentication field in 141 the usual reply. 142 143 144 4. The client obtains the encryption key, decrypts the reply, 145 and then proceeds as usual. 146 147 148Section 3.1 of this document defines the necessary message formats. 149Section 3.2 describes their syntax and use in greater detail. 150 151 152 1533.1. Definitions 154 155 156 1573.1.1. Required Algorithms 158 159 160All PKINIT implementations MUST support the following algorithms: 161 162 163 - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype; 164 165 - Signature algorithm: SHA-1 digest and RSA; 166 167 168 - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman 169 with a non-zero nonce; 170 171 172 - Unkeyed checksum type for the paChecksum member of 173 PKAuthenticator: SHA1 (unkeyed). 174 175 176 1773.1.2. Defined Message and Encryption Types 178 179 180PKINIT makes use of the following new preauthentication types: 181 182 183 PA-PK-AS-REQ TBD 184 PA-PK-AS-REP TBD 185 PA-PK-OCSP-REQ TBD 186 PA-PK-OCSP-REP TBD 187 188 189PKINIT also makes use of the following new authorization data type: 190 191 192 AD-INITIAL-VERIFIED-CAS TBD 193 194 195PKINIT introduces the following new error codes: 196 197 198 KDC_ERR_CLIENT_NOT_TRUSTED 62 199 KDC_ERR_KDC_NOT_TRUSTED 63 200 KDC_ERR_INVALID_SIG 64 201 KDC_ERR_KEY_SIZE 65 202 KDC_ERR_CERTIFICATE_MISMATCH 66 203 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 204 KDC_ERR_INVALID_CERTIFICATE 71 205 KDC_ERR_REVOKED_CERTIFICATE 72 206 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 207 KDC_ERR_CLIENT_NAME_MISMATCH 75 208 209 210PKINIT uses the following typed data types for errors: 211 212 213 TD-DH-PARAMETERS TBD 214 TD-TRUSTED-CERTIFIERS 104 215 TD-CERTIFICATE-INDEX 105 216 217 218PKINIT defines the following encryption types, for use in the AS-REQ 219message (to indicate acceptance of the corresponding encryption OIDs 220in PKINIT): 221 222 223 dsaWithSHA1-CmsOID 9 224 md5WithRSAEncryption-CmsOID 10 225 sha1WithRSAEncryption-CmsOID 11 226 rc2CBC-EnvOID 12 227 rsaEncryption-EnvOID (PKCS1 v1.5) 13 228 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 229 des-ede3-cbc-EnvOID 15 230 231 232The above encryption types are used by the client only within the 233KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their 234use within Kerberos EncryptedData structures is not specified by this 235document. 236 237 238 2393.1.3. Algorithm Identifiers 240 241 242PKINIT does not define, but does make use of, the following 243algorithm identifiers. 244 245 246PKINIT uses the following algorithm identifier for Diffie-Hellman 247key agreement [9]: 248 249 250 dhpublicnumber 251 252 253PKINIT uses the following signature algorithm identifiers [8, 12]: 254 255 256 sha-1WithRSAEncryption (RSA with SHA1) 257 md5WithRSAEncryption (RSA with MD5) 258 id-dsa-with-sha1 (DSA with SHA1) 259 260 261PKINIT uses the following encryption algorithm identifiers [5] for 262encrypting the temporary key with a public key: 263 264 265 rsaEncryption (PKCS1 v1.5) 266 id-RSAES-OAEP (PKCS1 v2.0) 267 268 269PKINIT uses the following algorithm identifiers [2] for encrypting 270the reply key with the temporary key: 271 272 273 des-ede3-cbc (three-key 3DES, CBC mode) 274 rc2-cbc (RC2, CBC mode) 275 276 277Kerberos data structures require the use of integer etypes, while CMS 278objects use OIDs. Therefore, each cryptographic algorithm supported 279by PKINIT is identified both by a CMS OID and by an equivalent 280Kerberos etype (defined in section 3.1.2). 281 282 2833.2. PKINIT Preauthentication Syntax and Use 284 285 286This section defines the syntax and use of the various 287preauthentication fields employed by PKINIT. 288 289 290 2913.2.1. Client Request 292 293 294The initial authentication request (AS-REQ) is sent as per RFC 2951510bis; the preauthentication field contains data signed by the 296client's private signature key as follows: 297 298 299 PA-PK-AS-REQ ::= SEQUENCE { 300 signedAuthPack [0] ContentInfo, 301 -- Defined in CMS [2]. 302 -- Type is SignedData. 303 -- Content is AuthPack 304 -- (defined below). 305 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 306 -- A list of CAs, trusted by 307 -- the client, used to certify 308 -- KDCs. 309 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 310 -- Defined in CMS [2]. 311 -- Identifies a particular KDC 312 -- certificate, if the client 313 -- already has it. 314 encryptionCert [3] IssuerAndSerialNumber OPTIONAL, 315 -- May identify the client's 316 -- Diffie-Hellman certificate, 317 -- or an RSA encryption key 318 -- certificate. 319 ... 320 } 321 322 323 TrustedCA ::= CHOICE { 324 caName [0] Name, 325 -- Fully qualified X.500 name 326 -- as defined in RFC 3280 [4]. 327 issuerAndSerial [1] IssuerAndSerialNumber, 328 -- Identifies a specific CA 329 -- certificate. 330 ... 331 } 332 333 334 AuthPack ::= SEQUENCE { 335 pkAuthenticator [0] PKAuthenticator, 336 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 337 -- Defined in RFC 3280 [4]. 338 -- Present only if the client 339 -- is using ephemeral-ephemeral 340 -- Diffie-Hellman. 341 ... 342 } 343 344 345 PKAuthenticator ::= SEQUENCE { 346 cusec [0] INTEGER, 347 ctime [1] KerberosTime, 348 -- cusec and ctime are used as 349 -- in RFC 1510bis, for replay 350 -- prevention. 351 nonce [2] INTEGER, 352 -- Binds reply to request, 353 -- MUST be zero when client 354 -- will accept cached 355 -- Diffie-Hellman parameters 356 -- from KDC. MUST NOT be 357 -- zero otherwise. 358 -- MUST be 0 <= nonce < 2^32. 359 paChecksum [3] Checksum, 360 -- Defined in RFC 1510bis [1]. 361 -- Performed over KDC-REQ-BODY, 362 -- MUST be unkeyed. 363 ... 364 } 365 366 367 IMPORTS 368 -- from RFC 3280 [4] 369 SubjectPublicKeyInfo, AlgorithmIdentifier, Name 370 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 371 dod (6) internet (1) security (5) mechanisms (5) 372 pkix (7) id-mod (0) id-pkix1-explicit (18) } 373 374 375 IMPORTS 376 -- from RFC 2630 [2] 377 ContentInfo, IssuerAndSerialNumber 378 FROM CryptographicMessageSyntax { iso(1) member-body(2) 379 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 380 modules(0) cms(1) } 381 382 383 IMPORTS 384 -- from RFC 1510bis [1] 385 KerberosTime, Checksum 386 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 387 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 388 krb5spec2(2) } 389 390 391The ContentInfo in the signedAuthPack is filled out as follows: 392 393 394 1. The eContent field contains data of type AuthPack. It MUST 395 contain the pkAuthenticator, and MAY also contain the 396 client's Diffie-Hellman public value (clientPublicValue). 397 398 399 2. The eContentType field MUST contain the OID value for 400 pkauthdata: { iso (1) org (3) dod (6) internet (1) 401 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)} 402 403 404 3. The signerInfos field MUST contain the signature over the 405 AuthPack. 406 407 408 4. The certificates field MUST contain at least a signature 409 verification certificate chain that the KDC can use to 410 verify the signature over the AuthPack. Additionally, the 411 client MAY insert an encryption certificate chain, if 412 (for example) the client is not using ephemeral-ephemeral 413 Diffie-Hellman. 414 415 416 5. If a Diffie-Hellman key is being used, the parameters SHOULD 417 be chosen from the First or Second defined Oakley Groups. 418 (See RFC 2409 [10].) 419 420 421 6. The KDC may wish to use cached Diffie-Hellman parameters. 422 To indicate acceptance of caching, the client sends zero in 423 the nonce field of the pkAuthenticator. Zero is not a valid 424 value for this field under any other circumstances. Since 425 zero is used to indicate acceptance of cached parameters, 426 message binding in this case is performed using only the 427 nonce in the main request. 428 429 430 4313.2.2. Validation of Client Request 432 433 434Upon receiving the client's request, the KDC validates it. This 435section describes the steps that the KDC MUST (unless otherwise 436noted) take in validating the request. 437 438 439The KDC must look for a client certificate in the signedAuthPack. 440If it cannot find one signed by a CA it trusts, it sends back an 441error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 442e-data for this error is a SEQUENCE OF TYPED-DATA: 443 444 445 TYPED-DATA ::= SEQUENCE { 446 -- As defined in RFC 1510bis. 447 data-type [0] INTEGER, 448 data-value [1] OCTET STRING 449 } 450 451 452 IMPORTS 453 -- from RFC 1510bis [1] 454 TYPED-DATA, Checksum 455 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 456 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 457 krb5spec2(2) } 458 459 460For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the 461data-value is an OCTET STRING containing the DER encoding of 462 463 464 TrustedCertifiers ::= SEQUENCE OF Name 465 466 467If, while verifying the certificate chain, the KDC determines that 468the signature on one of the certificates in the signedAuthPack is 469invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 470The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA, 471whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 472OCTET STRING containing the DER encoding of the index into the 473CertificateSet field, ordered as sent by the client: 474 475 476 CertificateIndex ::= IssuerAndSerialNumber 477 -- IssuerAndSerialNumber of 478 -- certificate with invalid signature 479 480 481If more than one certificate signature is invalid, the KDC MAY send one 482TYPED-DATA per invalid signature. 483 484 485The KDC MAY also check whether any of the certificates in the client's 486chain have been revoked. If any of them have been revoked, the KDC 487MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 488attempts to determine the revocation status but is unable to do so, 489it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 490The certificate or certificates affected are identified exactly as 491for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 492 493 494In addition to validating the certificate chain, the KDC MUST also 495check that the certificate properly maps to the client's principal name 496as specified in the AS-REQ as follows: 497 498 499 1. If the KDC has its own mapping from the name in the 500 certificate to a Kerberos name, it uses that Kerberos 501 name. 502 503 504 2. Otherwise, if the certificate contains a SubjectAltName 505 extension with a Kerberos name in the otherName field, 506 it uses that name. The otherName field (of type AnotherName) in 507 the SubjectAltName extension MUST contain the following: 508 509 510 The type-id is: 511 512 513 krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) 514 internet (1) security (5) kerberosv5 (2) 2 } 515 516 517 The value is: 518 519 520 KRB5PrincipalName ::= SEQUENCE { 521 realm [0] Realm, 522 principalName [1] PrincipalName 523 } 524 525 526 IMPORTS 527 -- from RFC 3280 [4] 528 GeneralName 529 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 530 dod (6) internet (1) security (5) mechanisms (5) 531 pkix (7) id-mod (0) id-pkix1-explicit (18) } 532 533 534 IMPORTS 535 -- from RFC 1510bis [1] 536 PrincipalName, Realm 537 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 538 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 539 krb5spec2(2) } 540 541 542If the KDC does not have its own mapping and there is no Kerberos 543name present in the certificate, or if the name in the request does 544not match the name in the certificate (including the realm name), or 545if there is no name in the request, the KDC MUST return error code 546KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 547for this error. If the name in the request is [special "blank" 548name], the KDC MAY insert a different name in the reply. 549 550 551Even if the chain is validated, and the names in the certificate and 552the request match, the KDC may decide not to trust the client. For 553example, the certificate may include an Enxtended Key Usage (EKU) OID 554in the extensions field. As a matter of local policy, the KDC may 555decide to reject requests on the basis of the absence or presence of 556specific EKU OIDs. In this case, the KDC MUST return error code 557KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: 558 559 560 { iso (1) org (3) dod (6) internet (1) security (5) 561 kerberosv5 (2) pkinit (3) pkekuoid (4) } 562 563 564If the client's signature on the signedAuthPack fails to verify, the KDC 565MUST return error KDC_ERR_INVALID_SIG. There is no accompanying 566e-data for this error. 567 568 569The KDC MUST check the timestamp to ensure that the request is not 570a replay, and that the time skew falls within acceptable limits. 571The recommendations clock skew times in RFC 1510bis [1] apply here. 572If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 573or KRB_AP_ERR_SKEW, respectively. 574 575 576If the clientPublicValue is filled in, indicating that the 577client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC 578checks to see if the parameters satisfy its policy. If they do not, 579it MUST return error code KDC_ERR_KEY_SIZE. The accompanying e-data is 580a SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose 581data-value is an OCTET STRING containing the DER encoding of a 582DomainParameters (see [3]), including appropriate Diffie-Hellman 583parameters with which to retry the request. 584 585 586The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 587client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not 588have the corresponding certificate. 589 590 591The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did 592not include a kdcCert field, but did include a trustedCertifiers field, 593and the KDC does not possesses a certificate issued by one of the listed 594certifiers. 595 596 597 5983.2.3. KDC Reply 599 600 601Assuming that the client's request has been properly validated, the 602KDC proceeds as per RFC 1510bis, except as follows. 603 604 605The KDC MUST set the initial flag and include an authorization data of 606type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is an 607OCTET STRING containing the DER encoding of InitialVerifiedCAs: 608 609 610 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 611 ca [0] Name, 612 Validated [1] BOOLEAN, 613 ... 614 } 615 616 617The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 618containers if the list of CAs satisfies the KDC's realm's policy. 619(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 620Furthermore, any TGS must copy such authorization data from tickets 621used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 622including the AD-IF-RELEVANT container, if present. 623 624 625AP servers that understand this authorization data type SHOULD apply 626local policy to determine whether a given ticket bearing such a type 627(not contained within an AD-IF-RELEVANT container) is acceptable. 628(This corresponds to the AP server checking the transited field when 629the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data 630type is contained within an AD-IF-RELEVANT container, AP servers 631MAY apply local policy to determine whether the authorization 632data is acceptable. 633 634 635The AS-REP is otherwise unchanged from RFC 1510bis. The KDC encrypts 636the reply as usual, but not with the client's long-term key. 637Instead, it encrypts it with either a generated encryption key, or a 638key derived from a Diffie-Hellman exchange. The contents of the 639PA-PK-AS-REP indicate the type of encryption key that was used: 640 641 642 PA-PK-AS-REP ::= CHOICE { 643 dhSignedData [0] ContentInfo, 644 -- Type is SignedData. 645 -- Content is KDCDHKeyInfo 646 -- (defined below). 647 encKeyPack [1] ContentInfo, 648 -- Type is SignedData. 649 -- Content is ReplyKeyPack 650 -- (defined below). 651 ... 652 } 653 654 655 KDCDHKeyInfo ::= SEQUENCE { 656 subjectPublicKey [0] BIT STRING, 657 -- Equals public exponent 658 -- (g^a mod p). 659 -- INTEGER encoded as payload 660 -- of BIT STRING. 661 nonce [1] INTEGER, 662 -- Binds reply to request. 663 -- Exception: A value of zero 664 -- indicates that the KDC is 665 -- using cached values. 666 dhKeyExpiration [2] KerberosTime OPTIONAL, 667 -- Expiration time for KDC's 668 -- cached values. 669 ... 670 } 671 672 673The fields of the ContentInfo for dhSignedData are to be filled in 674as follows: 675 676 677 1. The eContent field contains data of type KDCDHKeyInfo. 678 679 680 2. The eContentType field contains the OID value for 681 pkdhkeydata: { iso (1) org (3) dod (6) internet (1) 682 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) } 683 684 685 3. The signerInfos field contains a single signerInfo, which is 686 the signature of the KDCDHKeyInfo. 687 688 689 4. The certificates field contains a signature verification 690 certificate chain that the client will use to verify the 691 KDC's signature over the KDCDHKeyInfo. This field may only 692 be left empty if the client did include a kdcCert field in 693 the PA-PK-AS-REQ, indicating that it has the KDC's certificate. 694 695 696 5. If the client and KDC agree to use cached parameters, the 697 KDC MUST return a zero in the nonce field and include the 698 expiration time of the cached values in the dhKeyExpiration 699 field. If this time is exceeded, the client MUST NOT use 700 the reply. If the time is absent, the client MUST NOT use 701 the reply and MAY resubmit a request with a non-zero nonce, 702 thus indicating non-acceptance of the cached parameters. 703 704 705The key is derived as follows: Both the KDC and the client calculate 706the value g^(ab) mod p, where a and b are the client's and KDC's 707private exponents, respectively. They both take the first k bits of 708this secret value as a key generation seed, where the parameter k 709(the size of the seed) is dependent on the selected key type, as 710specified in [6]. The seed is then converted into a protocol key by 711applying to it a random-to-key function, which is also dependent on 712key type. 713 714 715 1. For example, if the encryption type is DES with MD4, k = 64 716 bits and the random-to-key function consists of replacing 717 some of the bits with parity bits, according to FIPS PUB 74 718 [9]. 719 720 721 2. If the encryption type is three-key 3DES with HMAC-SHA1, 722 k = 168 bits and the random-to-key function is 723 DES3random-to-key as defined in [6]. This function inserts 724 parity bits to create a 192-bit 3DES protocol key that is 725 compliant with FIPS PUB 74 [9]. This key is used to 726 generate additional keys Ke and Ki, for encryption and 727 integrity protection, respectively, using the key usage 728 value of 3, as per [6] for the handling of the encrypted 729 part of the AS-REP. 730 731 732If the KDC and client are not using Diffie-Hellman, the KDC encrypts 733the reply with an encryption key, packed in the encKeyPack, which 734contains data of type ReplyKeyPack: 735 736 737 ReplyKeyPack ::= SEQUENCE { 738 replyKey [0] EncryptionKey, 739 -- Defined in RFC 1510bis. 740 -- Used to encrypt main reply. 741 -- MUST be at least as strong 742 -- as session key. (Using the 743 -- same enctype and a strong 744 -- prng should suffice, if no 745 -- stronger encryption system 746 -- is available.) 747 nonce [1] INTEGER, 748 -- Binds reply to request. 749 -- MUST be 0 < nonce < 2^32. 750 ... 751 } 752 753 754 IMPORTS 755 -- from RFC 1510bis [1] 756 EncryptionKey 757 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 758 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 759 krb5spec2(2) } 760 761 762The fields of the ContentInfo for encKeyPack MUST be filled in as 763follows: 764 765 766 1. The content is of type SignedData. The eContent for 767 the SignedData is of type ReplyKeyPack. 768 769 770 2. The eContentType for the SignedData contains the OID value for 771 pkrkeydata: { iso (1) org (3) dod (6) internet (1) 772 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) } 773 774 775 3. The signerInfos field contains a single signerInfo, which is 776 the signature of the ReplyKeyPack. 777 778 779 4. The certificates field contains a signature verification 780 certificate chain that the client will use to verify the 781 KDC's signature over the ReplyKeyPack. This field may only 782 be left empty if the client did include a kdcCert field in 783 the PA-PK-AS-REQ, indicating that it has the KDC's certificate. 784 785 786 5. The encryptedContentType for the EnvelopedData contains the OID 787 value for id-signedData: { iso (1) member-body (2) us (840) 788 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } 789 790 791 6. The recipientInfos field is a SET which MUST contain exactly 792 one member of type KeyTransRecipientInfo. The encryptedKey 793 for this member contains the temporary key which is 794 encrypted using the client's public key. 795 796 797 7. The unprotectedAttrs or originatorInfo fields MAY be present. 798 799 800 8013.2.4. Validation of KDC Reply 802 803 804Upon receipt of the KDC's reply, the client proceeds as follows. If 805the PA-PK-AS-REP contains a dhSignedData, the client obtains and 806verifies the Diffie-Hellman parameters, and obtains the shared key 807as described above. Otherwise, the message contains an encKeyPack, 808and the client decrypts and verifies the temporary encryption key. 809In either case, the client then decrypts the main reply with the 810resulting key, and then proceeds as described in RFC 1510bis. 811 812 813 8143.2.5. Support for OCSP 815 816 817OCSP (Online Certificate Status Protocol) [8] allows the use of 818on-line requests for a client or server to determine the validity of 819each other's certificates. It is particularly useful for clients 820authenticating each other across a constrained network. These 821clients will not have to download the entire CRL to check for the 822validity of the KDC's certificate. 823 824 825In these cases, the KDC generally has better connectivity to the 826OCSP server, and it therefore processes the OCSP request and 827response and sends the results to the client. The mechanism defined 828in this section allow a client to request an OCSP response from the 829KDC when using PKINIT. This is similar to the way that OCSP is 830handled in [7]. 831 832 833OCSP support is provided in PKINIT through the use of additional 834preauthentication data. The following new preauthentication types 835are defined: 836 837 838 PA-PK-OCSP-REQ ::= SEQUENCE { 839 -- PAType TBD 840 responderIDList [0] SEQUENCE of ResponderID OPTIONAL, 841 -- ResponderID is a DER-encoded 842 -- ASN.1 type defined in [8] 843 requestExtensions [1] Extensions OPTIONAL 844 -- Extensions is a DER-encoded 845 -- ASN.1 type defined in [8] 846 } 847 848 849 PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse 850 -- OCSPResponse is a DER-encoded 851 -- ASN.1 type defined in [8] 852 853 854A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP. 855KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a 856PA-PK-OCSP-REQ from the client. The KDC MAY either send a cached 857OCSP response or send an on-line request to the OCSP server. 858 859 860In the case that a responderIDList is not sent or is empty, the OCSP 861response must be signed by the authority that issued the 862certificate, unless specified otherwise by a mutually agreed policy 863between the client and the KDC. 864 865 866When using OCSP, the response is signed by the OCSP server, which is 867trusted by the client. Depending on local policy, further 868verification of the validity of the OCSP server may need to be done. 869 870 871 8724. Security Considerations 873 874 875PKINIT raises certain security considerations beyond those that can 876be regulated strictly in protocol definitions. We will address them 877in this section. 878 879 880PKINIT extends the cross-realm model to the public-key 881infrastructure. Users of PKINIT must understand security policies 882and procedures appropriate to the use of Public Key Infrastructures. 883 884 885Standard Kerberos allows the possibility of interactions between 886cryptosystems of varying strengths; this document adds interactions 887with public-key cryptosystems to Kerberos. Some administrative 888policies may allow the use of relatively weak public keys. Using 889such keys to wrap data encrypted under stronger conventional 890cryptosystems may be inappropriate. 891 892 893PKINIT requires keys for symmetric cryptosystems to be generated. 894Some such systems contain "weak" keys. For recommendations regarding 895these weak keys, see RFC 1510bis. 896 897 898PKINIT allows the use of a zero nonce in the PKAuthenticator when 899cached Diffie-Hellman keys are used. In this case, message binding 900is performed using the nonce in the main request in the same way as 901it is done for ordinary AS-REQs (without the PKINIT 902pre-authenticator). The nonce field in the KDC request body is 903signed through the checksum in the PKAuthenticator, which 904cryptographically binds the PKINIT pre-authenticator to the main body 905of the AS Request and also provides message integrity for the full 906AS Request. 907 908 909However, when a PKINIT pre-authenticator in the AS-REP has a 910zero-nonce, and an attacker has somehow recorded this 911pre-authenticator and discovered the corresponding Diffie-Hellman 912private key (e.g., with a brute-force attack), the attacker will be 913able to fabricate his own AS-REP messages that impersonate the KDC 914with this same pre-authenticator. This compromised pre-authenticator 915will remain valid as long as its expiration time has not been reached 916and it is therefore important for clients to check this expiration 917time and for the expiration time to be reasonably short, which 918depends on the size of the Diffie-Hellman group. 919 920 921If a client also caches its Diffie-Hellman keys, then the session key 922 could remain the same during multiple AS-REQ/AS-REP exchanges and an 923 attacker which compromised the session key could fabricate his own 924AS-REP messages with a pre-recorded pre-authenticator until the 925client starts using a new Diffie-Hellman key pair and while the KDC 926pre-authenticator has not yet expired. It is therefore not 927recommended for KDC clients to also cache their Diffie-Hellman keys. 928 929 930Care should be taken in how certificates are chosen for the purposes 931of authentication using PKINIT. Some local policies may require 932that key escrow be used for certain certificate types. Deployers of 933PKINIT should be aware of the implications of using certificates that 934have escrowed keys for the purposes of authentication. 935 936 937PKINIT does not provide for a "return routability" test to prevent 938attackers from mounting a denial-of-service attack on the KDC by 939causing it to perform unnecessary and expensive public-key 940operations. Strictly speaking, this is also true of standard 941Kerberos, although the potential cost is not as great, because 942standard Kerberos does not make use of public-key cryptography. 943 944 945 946 9475. Acknowledgements 948 949 950Some of the ideas on which this document is based arose during 951discussions over several years between members of the SAAG, the IETF 952CAT working group, and the PSRG, regarding integration of Kerberos 953and SPX. Some ideas have also been drawn from the DASS system. 954These changes are by no means endorsed by these groups. This is an 955attempt to revive some of the goals of those groups, and this 956document approaches those goals primarily from the Kerberos 957perspective. Lastly, comments from groups working on similar ideas 958in DCE have been invaluable. 959 960 961 9626. Expiration Date 963 964 965This draft expires September 30, 2004. 966 967 968 9697. Bibliography 970 971 972[1] RFC-Editor: To be replaced by RFC number for 973draft-ietf-krb-wg-kerberos-clarifications. 974 975 976[2] R. Housley. Cryptographic Message Syntax., April 1999. 977Request For Comments 2630. 978 979 980[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 981for the Internet X.509 Public Key Infrastructure Certificate and 982Certificate Revocation List (CRL) Profile, April 2002. Request For 983Comments 3279. 984 985 986[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public 987Key Infrastructure Certificate and Certificate Revocation List 988(CRL) Profile, April 2002. Request for Comments 3280. 989 990 991[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 992Specifications, October 1998. Request for Comments 2437. 993 994 995[6] RFC-Editor: To be replaced by RFC number for 996draft-ietf-krb-wg-crypto. 997 998 999[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and 1000T. Wright. Transport Layer Security (TLS) Extensions, June 2003. 1001Request for Comments 3546. 1002 1003 1004[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 1005Internet X.509 Public Key Infrastructure: Online Certificate Status 1006Protocol - OCSP, June 1999. Request for Comments 2560. 1007 1008 1009[9] NIST, Guidelines for Implementing and Using the NBS Encryption 1010Standard, April 1981. FIPS PUB 74. 1011 1012 1013[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), 1014November 1998. Request for Comments 2409. 1015 1016 1017 10188. Authors 1019 1020 1021Brian Tung 1022Clifford Neuman 1023USC Information Sciences Institute 10244676 Admiralty Way Suite 1001 1025Marina del Rey CA 90292-6695 1026Phone: +1 310 822 1511 1027E-mail: {brian,bcn}@isi.edu 1028 1029 1030Matthew Hur 1031Ari Medvinsky 1032Microsoft Corporation 1033One Microsoft Way 1034Redmond WA 98052 1035Phone: +1 425 707 3336 1036E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 1037 1038 1039Sasha Medvinsky 1040Motorola, Inc. 10416450 Sequence Drive 1042San Diego, CA 92121 1043+1 858 404 2367 1044E-mail: smedvinsky@motorola.com 1045 1046 1047John Wray 1048Iris Associates, Inc. 10495 Technology Park Dr. 1050Westford, MA 01886 1051E-mail: John_Wray@iris.com 1052 1053 1054Jonathan Trostle 1055E-mail: jtrostle@world.std.com