1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-20.txt Clifford Neuman 3Updates: CLARIFICATIONS USC/ISI 4expires January 25, 2005 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 19This document is an Internet-Draft and is in full conformance with 20all provision of Section 10 of RFC 2026. Internet-Drafts are 21working documents of the Internet Engineering Task Force (IETF), its 22areas, and its working groups. Note that other groups may also 23distribute working documents as Internet-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-20.txt and expires January 25, 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], hereafter 45called CLARIFICATIONS). These extensions provide a method for 46integrating public key cryptography into the initial authentication 47exchange, by passing digital certificates and associated 48authenticators in preauthentication data fields. 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 CLARIFICATIONS for supporting 96the use of public-key cryptography in the initial request for a 97ticket. 98 99Briefly, this document defines the following extensions to 100CLARIFICATIONS: 101 102 1. The client indicates the use of public-key authentication by 103 including a special preauthenticator in the initial request. 104 This preauthenticator contains the client's public-key data 105 and a signature. 106 107 2. The KDC tests the client's request against its policy and 108 trusted Certification Authorities (CAs). 109 110 3. If the request passes the verification tests, the KDC 111 replies as usual, but the reply is encrypted using either: 112 113 a. a symmetric encryption key, signed using the KDC's 114 signature key and encrypted using the client's encryption 115 key; or 116 117 b. a key generated through a Diffie-Hellman exchange with 118 the client, signed using the KDC's signature key. 119 120 Any keying material required by the client to obtain the 121 Encryption key is returned in a preauthentication field 122 accompanying the usual reply. 123 124 4. The client obtains the encryption key, decrypts the reply, 125 and then proceeds as usual. 126 127Section 3.1 of this document defines the necessary message formats. 128Section 3.2 describes their syntax and use in greater detail. 129 130 1313.1. Definitions 132 133 1343.1.1. Required Algorithms 135 136All PKINIT implementations MUST support the following algorithms: 137 138 - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. 139 140 - Signature algorithm: SHA-1 digest and RSA. 141 142 - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman 143 with a non-zero nonce. 144 145 - Unkeyed checksum type for the paChecksum member of 146 PKAuthenticator: SHA1 (unkeyed). 147 148 1493.1.2. Defined Message and Encryption Types 150 151PKINIT makes use of the following new preauthentication types: 152 153 PA-PK-AS-REQ TBD 154 PA-PK-AS-REP TBD 155 156PKINIT also makes use of the following new authorization data type: 157 158 AD-INITIAL-VERIFIED-CAS TBD 159 160PKINIT introduces the following new error codes: 161 162 KDC_ERR_CLIENT_NOT_TRUSTED 62 163 KDC_ERR_KDC_NOT_TRUSTED 63 164 KDC_ERR_INVALID_SIG 64 165 KDC_ERR_KEY_SIZE 65 166 KDC_ERR_CERTIFICATE_MISMATCH 66 167 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 168 KDC_ERR_INVALID_CERTIFICATE 71 169 KDC_ERR_REVOKED_CERTIFICATE 72 170 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 171 KDC_ERR_CLIENT_NAME_MISMATCH 75 172 173PKINIT uses the following typed data types for errors: 174 175 TD-DH-PARAMETERS TBD 176 TD-TRUSTED-CERTIFIERS 104 177 TD-CERTIFICATE-INDEX 105 178 179PKINIT defines the following encryption types, for use in the AS-REQ 180message (to indicate acceptance of the corresponding encryption OIDs 181in PKINIT): 182 183 dsaWithSHA1-CmsOID 9 184 md5WithRSAEncryption-CmsOID 10 185 sha1WithRSAEncryption-CmsOID 11 186 rc2CBC-EnvOID 12 187 rsaEncryption-EnvOID (PKCS1 v1.5) 13 188 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 189 des-ede3-cbc-EnvOID 15 190 191The above encryption types are used by the client only within the 192KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their 193use within Kerberos EncryptedData structures is not specified by this 194document. 195 196The ASN.1 module for all structures defined in this document (plus 197IMPORT statements for all imported structures) are given in Appendix 198A. All structures MUST be encoded using Distinguished Encoding 199Rules (DER). 200 201 2023.1.3. Algorithm Identifiers 203 204PKINIT does not define, but does make use of, the following 205algorithm identifiers. 206 207PKINIT uses the following algorithm identifier for Diffie-Hellman 208key agreement [9]: 209 210 dhpublicnumber 211 212PKINIT uses the following signature algorithm identifiers [8, 12]: 213 214 sha-1WithRSAEncryption (RSA with SHA1) 215 md5WithRSAEncryption (RSA with MD5) 216 id-dsa-with-sha1 (DSA with SHA1) 217 218PKINIT uses the following encryption algorithm identifiers [5] for 219encrypting the temporary key with a public key: 220 221 rsaEncryption (PKCS1 v1.5) 222 id-RSAES-OAEP (PKCS1 v2.0) 223 224PKINIT uses the following algorithm identifiers [2] for encrypting 225the reply key with the temporary key: 226 227 des-ede3-cbc (three-key 3DES, CBC mode) 228 rc2-cbc (RC2, CBC mode) 229 230Kerberos data structures require the use of integer etypes, while CMS 231objects use OIDs. Therefore, each cryptographic algorithm supported 232by PKINIT is identified both by a CMS OID and by an equivalent 233Kerberos etype (defined in section 3.1.2). 234 235 2363.2. PKINIT Preauthentication Syntax and Use 237 238This section defines the syntax and use of the various 239preauthentication fields employed by PKINIT. 240 241 2423.2.1. Client Request 243 244The initial authentication request (AS-REQ) is sent as per RFC 2451510bis; in addition, a preauthentication field contains data signed 246by the client's private signature key, as follows: 247 248 PA-PK-AS-REQ ::= SEQUENCE { 249 signedAuthPack [0] ContentInfo, 250 -- Defined in CMS [2]. 251 -- Type is SignedData. 252 -- Content is AuthPack 253 -- (defined below). 254 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 255 -- A list of CAs, trusted by 256 -- the client, used to certify 257 -- KDCs. 258 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 259 -- Defined in CMS [2]. 260 -- Identifies a particular KDC 261 -- certificate, if the client 262 -- already has it. 263 ... 264 } 265 266 TrustedCA ::= CHOICE { 267 caName [0] Name, 268 -- Fully qualified X.500 name 269 -- as defined in RFC 3280 [4]. 270 issuerAndSerial [2] IssuerAndSerialNumber, 271 -- Identifies a specific CA 272 -- certificate. 273 ... 274 } 275 276 AuthPack ::= SEQUENCE { 277 pkAuthenticator [0] PKAuthenticator, 278 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 279 -- Defined in RFC 3280 [4]. 280 -- Present only if the client 281 -- is using ephemeral-ephemeral 282 -- Diffie-Hellman. 283 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 284 OPTIONAL, 285 -- List of CMS encryption types 286 -- supported by client in order 287 -- of (decreasing) preference. 288 ... 289 } 290 291 PKAuthenticator ::= SEQUENCE { 292 cusec [0] INTEGER, 293 ctime [1] KerberosTime, 294 -- cusec and ctime are used as 295 -- in CLARIFICATIONS, for replay 296 -- prevention. 297 nonce [2] INTEGER (0..4294967295), 298 -- Binds reply to request, 299 -- MUST be zero when client 300 -- will accept cached 301 -- Diffie-Hellman parameters 302 -- from KDC. MUST NOT be 303 -- zero otherwise. 304 paChecksum [3] Checksum, 305 -- Defined in CLARIFICATIONS. 306 -- Performed over KDC-REQ-BODY, 307 -- MUST be unkeyed. 308 ... 309 } 310 311The ContentInfo in the signedAuthPack is filled out as follows: 312 313 1. The eContent field contains data of type AuthPack. It MUST 314 contain the pkAuthenticator, and MAY also contain the 315 client's Diffie-Hellman public value (clientPublicValue). 316 317 2. The eContentType field MUST contain the OID value for 318 id-pkauthdata: { iso(1) org(3) dod(6) internet(1) 319 security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} 320 321 3. The signerInfos field MUST contain the signature over the 322 AuthPack. 323 324 4. The certificates field MUST contain at least a signature 325 verification certificate chain that the KDC can use to 326 verify the signature over the AuthPack. Additionally, the 327 client MAY insert an encryption certificate chain, if 328 (for example) the client is not using ephemeral-ephemeral 329 Diffie-Hellman. 330 331 5. If a Diffie-Hellman key is being used, the parameters SHOULD 332 be chosen from the First or Second defined Oakley Groups. 333 (See RFC 2409 [10].) 334 335 6. The KDC may wish to use cached Diffie-Hellman parameters. 336 To indicate acceptance of caching, the client sends zero in 337 the nonce field of the pkAuthenticator. Zero is not a valid 338 value for this field under any other circumstances. Since 339 zero is used to indicate acceptance of cached parameters, 340 message binding in this case is performed using only the 341 nonce in the main request. 342 343 3443.2.2. Validation of Client Request 345 346Upon receiving the client's request, the KDC validates it. This 347section describes the steps that the KDC MUST (unless otherwise 348noted) take in validating the request. 349 350The KDC must look for a client certificate in the signedAuthPack. 351If it cannot find one signed by a CA it trusts, it sends back an 352error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 353e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC 3541510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS, 355and the data-value is an OCTET STRING containing the DER encoding of 356 357 TrustedCertifiers ::= SEQUENCE OF Name 358 359If, while verifying the certificate chain, the KDC determines that 360the signature on one of the certificates in the signedAuthPack is 361invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 362The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA, 363whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 364OCTET STRING containing the DER encoding of the index into the 365CertificateSet field, ordered as sent by the client: 366 367 CertificateIndex ::= IssuerAndSerialNumber 368 -- IssuerAndSerialNumber of 369 -- certificate with invalid signature 370 371If more than one certificate signature is invalid, the KDC MAY send 372one TYPED-DATA per invalid signature. 373 374The KDC MAY also check whether any certificates in the client's 375chain have been revoked. If any of them have been revoked, the KDC 376MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 377attempts to determine the revocation status but is unable to do so, 378it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 379The certificate or certificates affected are identified exactly as 380for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 381 382In addition to validating the certificate chain, the KDC MUST also 383check that the certificate properly maps to the client's principal name 384as specified in the AS-REQ as follows: 385 386 1. If the KDC has its own mapping from the name in the 387 certificate to a Kerberos name, it uses that Kerberos 388 name. 389 390 2. Otherwise, if the certificate contains a SubjectAltName 391 extension with a Kerberos name in the otherName field, 392 it uses that name. The otherName field (of type AnotherName) 393 in the SubjectAltName extension MUST contain the following: 394 395 The type-id is: 396 397 krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) 398 internet (1) security (5) kerberosv5 (2) 2 } 399 400 The value is: 401 402 KRB5PrincipalName ::= SEQUENCE { 403 realm [0] Realm, 404 principalName [1] PrincipalName 405 } 406 407If the KDC does not have its own mapping and there is no Kerberos 408name present in the certificate, or if the name in the request does 409not match the name in the certificate (including the realm name), or 410if there is no name in the request, the KDC MUST return error code 411KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 412for this error. 413 414Even if the chain is validated, and the names in the certificate and 415the request match, the KDC may decide not to trust the client. For 416example, the certificate may include an Enxtended Key Usage (EKU) OID 417in the extensions field. As a matter of local policy, the KDC may 418decide to reject requests on the basis of the absence or presence of 419specific EKU OIDs. In this case, the KDC MUST return error code 420KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: 421 422 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 423 pkinit(3) pkekuoid(4) } 424 425If the client's signature on the signedAuthPack fails to verify, the KDC 426MUST return error KDC_ERR_INVALID_SIG. There is no accompanying 427e-data for this error. 428 429The KDC MUST check the timestamp to ensure that the request is not 430a replay, and that the time skew falls within acceptable limits. 431The recommendations clock skew times in CLARIFICATIONS apply here. 432If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 433or KRB_AP_ERR_SKEW, respectively. 434 435If the clientPublicValue is filled in, indicating that the client 436wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to 437see if the parameters satisfy its policy. If they do not, it MUST 438return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a 439SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and 440whose data-value is an OCTET STRING containing the DER encoding of a 441DomainParameters (see [3]), including appropriate Diffie-Hellman 442parameters with which to retry the request. 443 444The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 445client included a kdcCert field in the PA-PK-AS-REQ and the KDC does 446not have the corresponding certificate. 447 448The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client 449did not include a kdcCert field, but did include a trustedCertifiers 450field, and the KDC does not possesses a certificate issued by one of 451the listed certifiers. 452 453If there is a supportedCMSTypes field in the AuthPack, the KDC must 454check to see if it supports any of the listed types. If it supports 455more than one of the types, the KDC SHOULD use the one listed first. 456If it does not support any of them, it MUST return an error of type 457KRB5KDC_ERR_ETYPE_NOSUPP. 458 459 4603.2.3. KDC Reply 461 462Assuming that the client's request has been properly validated, the 463KDC proceeds as per CLARIFICATIONS, except as follows. 464 465The KDC MUST set the initial flag and include an authorization data 466of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is 467an OCTET STRING containing the DER encoding of InitialVerifiedCAs: 468 469 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 470 ca [0] Name, 471 Validated [1] BOOLEAN, 472 ... 473 } 474 475The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 476containers if the list of CAs satisfies the KDC's realm's policy. 477(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 478Furthermore, any TGS must copy such authorization data from tickets 479used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 480including the AD-IF-RELEVANT container, if present. 481 482Application servers that understand this authorization data type 483SHOULD apply local policy to determine whether a given ticket 484bearing such a type *not* contained within an AD-IF-RELEVANT 485container is acceptable. (This corresponds to the AP server 486checking the transited field when the TRANSITED-POLICY-CHECKED flag 487has not been set.) If such a data type is contained within an 488AD-IF-RELEVANT container, AP servers MAY apply local policy to 489determine whether the authorization data is acceptable. 490 491The AS-REP is otherwise unchanged from CLARIFICATIONS. The KDC 492encrypts the reply as usual, but not with the client's long-term 493key. Instead, it encrypts it with either a generated encryption 494key, or a key derived from a Diffie-Hellman exchange. The contents 495of the PA-PK-AS-REP indicate the type of encryption key that was 496used: 497 498 PA-PK-AS-REP ::= CHOICE { 499 dhSignedData [0] ContentInfo, 500 -- Type is SignedData. 501 -- Content is KDCDHKeyInfo 502 -- (defined below). 503 encKeyPack [1] ContentInfo, 504 -- Type is EnvelopedData. 505 -- Content is SignedData over 506 -- ReplyKeyPack (defined below). 507 ... 508 } 509 510 KDCDHKeyInfo ::= SEQUENCE { 511 subjectPublicKey [0] BIT STRING, 512 -- Equals public exponent 513 -- (g^a mod p). 514 -- INTEGER encoded as payload 515 -- of BIT STRING. 516 nonce [1] INTEGER, 517 -- Binds reply to request. 518 -- Exception: A value of zero 519 -- indicates that the KDC is 520 -- using cached values. 521 dhKeyExpiration [2] KerberosTime OPTIONAL, 522 -- Expiration time for KDC's 523 -- cached values. 524 ... 525 } 526 527The fields of the ContentInfo for dhSignedData are to be filled in 528as follows: 529 530 1. The eContent field contains data of type KDCDHKeyInfo. 531 532 2. The eContentType field contains the OID value for 533 id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 534 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } 535 536 3. The signerInfos field contains a single signerInfo, which is 537 the signature of the KDCDHKeyInfo. 538 539 4. The certificates field contains a signature verification 540 certificate chain that the client will use to verify the 541 KDC's signature over the KDCDHKeyInfo. This field may only 542 be left empty if the client did include a kdcCert field in 543 the PA-PK-AS-REQ, indicating that it has the KDC's 544 certificate. 545 546 5. If the client and KDC agree to use cached parameters, the 547 KDC MUST return a zero in the nonce field and include the 548 expiration time of the cached values in the dhKeyExpiration 549 field. If this time is exceeded, the client MUST NOT use 550 the reply. If the time is absent, the client MUST NOT use 551 the reply and MAY resubmit a request with a non-zero nonce, 552 thus indicating non-acceptance of the cached parameters. 553 554The key is derived as follows: Both the KDC and the client calculate 555the value g^(ab) mod p, where a and b are the client's and KDC's 556private exponents, respectively. They both take the first k bits of 557this secret value as a key generation seed, where the parameter k 558(the size of the seed) is dependent on the selected key type, as 559specified in [6]. The seed is then converted into a protocol key by 560applying to it a random-to-key function, which is also dependent on 561key type. 562 563If the KDC and client are not using Diffie-Hellman, the KDC encrypts 564the reply with an encryption key, packed in the encKeyPack, which 565contains data of type ReplyKeyPack: 566 567 ReplyKeyPack ::= SEQUENCE { 568 replyKey [0] EncryptionKey, 569 -- Defined in CLARIFICATIONS. 570 -- Used to encrypt main reply. 571 -- MUST be at least as strong 572 -- as session key. (Using the 573 -- same enctype and a strong 574 -- prng should suffice, if no 575 -- stronger encryption system 576 -- is available.) 577 nonce [1] INTEGER (0..4294967295), 578 -- Binds reply to request. 579 ... 580 } 581 582The fields of the ContentInfo for encKeyPack MUST be filled in as 583follows: 584 585 1. The content is of type SignedData. The eContent for 586 the SignedData is of type ReplyKeyPack. 587 588 2. The eContentType for the SignedData contains the OID value 589 for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) 590 security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } 591 592 3. The signerInfos field contains a single signerInfo, which is 593 the signature of the ReplyKeyPack. 594 595 4. The certificates field contains a signature verification 596 certificate chain that the client will use to verify the 597 KDC's signature over the ReplyKeyPack. This field may only 598 be left empty if the client included a kdcCert field in the 599 PA-PK-AS-REQ, indicating that it has the KDC's certificate. 600 601 5. The contentType for the EnvelopedData contains the OID value 602 for id-signedData: { iso (1) member-body (2) us (840) rsadsi 603 (113549) pkcs (1) pkcs7 (7) signedData (2) } 604 605 6. The recipientInfos field is a SET which MUST contain exactly 606 one member of type KeyTransRecipientInfo. The encryptedKey 607 for this member contains the temporary key which is 608 encrypted using the client's public key. 609 610 7. The unprotectedAttrs or originatorInfo fields MAY be 611 present. 612 613 6143.2.4. Validation of KDC Reply 615 616Upon receipt of the KDC's reply, the client proceeds as follows. If 617the PA-PK-AS-REP contains a dhSignedData, the client obtains and 618verifies the Diffie-Hellman parameters, and obtains the shared key 619as described above. Otherwise, the message contains an encKeyPack, 620and the client decrypts and verifies the temporary encryption key. 621 622In either case, the client MUST check to see if the included 623certificate contains a subjectAltName extension of type dNSName or 624iPAddress (if the KDC is specified by IP address instead of name). 625If it does, it MUST check to see if that extension matches the KDC 626it believes it is communicating with, with matching rules specified 627in RFC 2459. Exception: If the client has some external information 628as to the identity of the KDC, this check MAY be omitted. 629 630The client also MUST check that the KDC's certificate contains an 631extendedKeyUsage OID of id-pkkdcekuoid: 632 633 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 634 pkinit(3) pkkdcekuoid(5) } 635 636If all applicable checks are satisfied, the client then decrypts the 637main reply with the resulting key, and then proceeds as described in 638CLARIFICATIONS. 639 640 6414. Security Considerations 642 643PKINIT raises certain security considerations beyond those that can 644be regulated strictly in protocol definitions. We will address them 645in this section. 646 647PKINIT extends the cross-realm model to the public-key 648infrastructure. Users of PKINIT must understand security policies 649and procedures appropriate to the use of Public Key Infrastructures. 650 651Standard Kerberos allows the possibility of interactions between 652cryptosystems of varying strengths; this document adds interactions 653with public-key cryptosystems to Kerberos. Some administrative 654policies may allow the use of relatively weak public keys. Using 655such keys to wrap data encrypted under stronger conventional 656cryptosystems may be inappropriate. 657 658PKINIT requires keys for symmetric cryptosystems to be generated. 659Some such systems contain "weak" keys. For recommendations regarding 660these weak keys, see CLARIFICATIONS. 661 662PKINIT allows the use of a zero nonce in the PKAuthenticator when 663cached Diffie-Hellman keys are used. In this case, message binding 664is performed using the nonce in the main request in the same way as 665it is done for ordinary AS-REQs (without the PKINIT 666pre-authenticator). The nonce field in the KDC request body is 667signed through the checksum in the PKAuthenticator, which 668cryptographically binds the PKINIT pre-authenticator to the main 669body of the AS Request and also provides message integrity for the 670full AS Request. 671 672However, when a PKINIT pre-authenticator in the AS-REP has a 673zero-nonce, and an attacker has somehow recorded this 674pre-authenticator and discovered the corresponding Diffie-Hellman 675private key (e.g., with a brute-force attack), the attacker will be 676able to fabricate his own AS-REP messages that impersonate the KDC 677with this same pre-authenticator. This compromised pre-authenticator 678will remain valid as long as its expiration time has not been reached 679and it is therefore important for clients to check this expiration 680time and for the expiration time to be reasonably short, which 681depends on the size of the Diffie-Hellman group. 682 683If a client also caches its Diffie-Hellman keys, then the session key 684could remain the same during multiple AS-REQ/AS-REP exchanges and an 685attacker which compromised the session key could fabricate his own 686AS-REP messages with a pre-recorded pre-authenticator until the 687client starts using a new Diffie-Hellman key pair and while the KDC 688pre-authenticator has not yet expired. It is therefore not 689recommended for KDC clients to also cache their Diffie-Hellman keys. 690 691Care should be taken in how certificates are chosen for the purposes 692of authentication using PKINIT. Some local policies may require 693that key escrow be used for certain certificate types. Deployers of 694PKINIT should be aware of the implications of using certificates that 695have escrowed keys for the purposes of authentication. 696 697PKINIT does not provide for a "return routability" test to prevent 698attackers from mounting a denial-of-service attack on the KDC by 699causing it to perform unnecessary and expensive public-key 700operations. Strictly speaking, this is also true of standard 701Kerberos, although the potential cost is not as great, because 702standard Kerberos does not make use of public-key cryptography. 703 704The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 705permit empty SEQUENCEs to be encoded. Such empty sequences may only 706be used if the KDC itself vouches for the user's certificate. [This 707seems to reflect the consensus of the Kerberos working group.] 708 709 7105. Acknowledgements 711 712Some of the ideas on which this document is based arose during 713discussions over several years between members of the SAAG, the IETF 714CAT working group, and the PSRG, regarding integration of Kerberos 715and SPX. Some ideas have also been drawn from the DASS system. 716These changes are by no means endorsed by these groups. This is an 717attempt to revive some of the goals of those groups, and this 718document approaches those goals primarily from the Kerberos 719perspective. Lastly, comments from groups working on similar ideas 720in DCE have been invaluable. 721 722 7236. Expiration Date 724 725This draft expires January 25, 2004. 726 727 7287. Bibliography 729 730[1] RFC-Editor: To be replaced by RFC number for 731draft-ietf-krb-wg-kerberos-clarifications. 732 733[2] R. Housley. Cryptographic Message Syntax., April 1999. 734Request For Comments 2630. 735 736[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 737for the Internet X.509 Public Key Infrastructure Certificate and 738Certificate Revocation List (CRL) Profile, April 2002. Request For 739Comments 3279. 740 741[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public 742Key Infrastructure Certificate and Certificate Revocation List 743(CRL) Profile, April 2002. Request for Comments 3280. 744 745[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 746Specifications, October 1998. Request for Comments 2437. 747 748[6] RFC-Editor: To be replaced by RFC number for 749draft-ietf-krb-wg-crypto. 750 751[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and 752T. Wright. Transport Layer Security (TLS) Extensions, June 2003. 753Request for Comments 3546. 754 755[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 756Internet X.509 Public Key Infrastructure: Online Certificate Status 757Protocol - OCSP, June 1999. Request for Comments 2560. 758 759[9] NIST, Guidelines for Implementing and Using the NBS Encryption 760Standard, April 1981. FIPS PUB 74. 761 762[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), 763November 1998. Request for Comments 2409. 764 765 7668. Authors 767 768Brian Tung 769Clifford Neuman 770USC Information Sciences Institute 7714676 Admiralty Way Suite 1001 772Marina del Rey CA 90292-6695 773Phone: +1 310 822 1511 774E-mail: {brian,bcn}@isi.edu 775 776Matthew Hur 777Ari Medvinsky 778Microsoft Corporation 779One Microsoft Way 780Redmond WA 98052 781Phone: +1 425 707 3336 782E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 783 784Sasha Medvinsky 785Motorola, Inc. 7866450 Sequence Drive 787San Diego, CA 92121 788+1 858 404 2367 789E-mail: smedvinsky@motorola.com 790 791John Wray 792Iris Associates, Inc. 7935 Technology Park Dr. 794Westford, MA 01886 795E-mail: John_Wray@iris.com 796 797Jonathan Trostle 798E-mail: jtrostle@world.std.com 799 800 801Appendix A. PKINIT ASN.1 Module 802 803KerberosV5-PK-INIT-SPEC { 804 iso(1) identified-organization(3) dod(6) internet(1) 805 security(5) kerberosV5(2) modules(4) pkinit(TBD) 806} DEFINITIONS EXPLICIT TAGS ::= BEGIN 807 808 IMPORTS 809 SubjectPublicKeyInfo, AlgorithmIdentifier, Name 810 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 811 dod (6) internet (1) security (5) mechanisms (5) 812 pkix (7) id-mod (0) id-pkix1-explicit (18) } 813 814 ContentInfo, IssuerAndSerialNumber 815 FROM CryptographicMessageSyntax { iso(1) member-body(2) 816 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 817 modules(0) cms(1) } 818 819 KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey 820 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 821 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 822 krb5spec2(2) } ; 823 824 id-pkinit OBJECT IDENTIFIER ::= 825 { iso (1) org (3) dod (6) internet (1) security (5) 826 kerberosv5 (2) pkinit (3) } 827 828 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } 829 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 830 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 831 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 832 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 833 834 pa-pk-as-req INTEGER ::= TBD 835 pa-pk-as-rep INTEGER ::= TBD 836 pa-pk-ocsp-req INTEGER ::= TBD 837 pa-pk-ocsp-rep INTEGER ::= TBD 838 839 ad-initial-verified-cas INTEGER ::= TBD 840 841 td-dh-parameters INTEGER ::= TBD 842 td-trusted-certifiers INTEGER ::= 104 843 td-certificate-index INTEGER ::= 105 844 845 PA-PK-AS-REQ ::= SEQUENCE { 846 signedAuthPack [0] ContentInfo, 847 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 848 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 849 ... 850 } 851 852 TrustedCA ::= CHOICE { 853 caName [0] Name, 854 issuerAndSerial [2] IssuerAndSerialNumber, 855 ... 856 } 857 858 AuthPack ::= SEQUENCE { 859 pkAuthenticator [0] PKAuthenticator, 860 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 861 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 862 OPTIONAL, 863 ... 864 } 865 866 PKAuthenticator ::= SEQUENCE { 867 cusec [0] INTEGER, 868 ctime [1] KerberosTime, 869 nonce [2] INTEGER (0..4294967295), 870 paChecksum [3] Checksum, 871 ... 872 } 873 874 TrustedCertifiers ::= SEQUENCE OF Name 875 876 CertificateIndex ::= IssuerAndSerialNumber 877 878 KRB5PrincipalName ::= SEQUENCE { 879 realm [0] Realm, 880 principalName [1] PrincipalName 881 } 882 883 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 884 ca [0] Name, 885 validated [1] BOOLEAN, 886 ... 887 } 888 889 PA-PK-AS-REP ::= CHOICE { 890 dhSignedData [0] ContentInfo, 891 encKeyPack [1] ContentInfo, 892 ... 893 } 894 895 KDCDHKeyInfo ::= SEQUENCE { 896 subjectPublicKey [0] BIT STRING, 897 nonce [1] INTEGER, 898 dhKeyExpiration [2] KerberosTime OPTIONAL, 899 ... 900 } 901 902 ReplyKeyPack ::= SEQUENCE { 903 replyKey [0] EncryptionKey, 904 nonce [1] INTEGER (0..4294967295), 905 ... 906 } 907 908END 909