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