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