1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman 3Updates: RFC 1510bis USC/ISI 4expires May 31, 2004 Matthew Hur 5 Ari Medvinsky 6 Microsoft Corporation 7 Sasha Medvinsky 8 Motorola, Inc. 9 John Wray 10 Iris Associates, Inc. 11 Jonathan Trostle 12 13 Public Key Cryptography for Initial Authentication in Kerberos 14 150. Status Of This Memo 16 17This document is an Internet-Draft and is in full conformance with 18all provision of Section 10 of RFC 2026. Internet-Drafts are 19working documents of the Internet Engineering Task Force (IETF), its 20areas, and its working groups. Note that other groups may also 21distribute working documents as Internet-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-17.txt and expires May 31, 2004. 36Please send comments to the authors. 37 38 391. Abstract 40 41This draft describes protocol extensions (hereafter called PKINIT) 42to the Kerberos protocol specification (RFC 1510bis [1]). These 43extensions provide a method for integrating public key cryptography 44into the initial authentication exchange, by passing cryptographic 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 draft, we will 58refer to both the AS and the TGS as the KDC.) Finally, the client 59uses the service ticket to authenticate itself to the service. 60 61The advantage afforded by the TGT is that the user need only 62explicitly request a ticket and expose his credentials once. The 63TGT and its associated session key can then be used for any 64subsequent requests. One implication of this is that all further 65authentication is independent of the method by which the initial 66authentication was performed. Consequently, initial authentication 67provides a convenient place to integrate public-key cryptography 68into Kerberos authentication. 69 70As defined, Kerberos authentication exchanges use symmetric-key 71cryptography, in part for performance. (Symmetric-key cryptography 72is typically 10-100 times faster than public-key cryptography, 73depending on the public-key operations. [c]) One cost of using 74symmetric-key cryptography is that the keys must be shared, so that 75before a user can authentication himself, he must already be 76registered with the KDC. 77 78Conversely, public-key cryptography--in conjunction with an 79established certification infrastructure--permits authentication 80without prior registration. Adding it to Kerberos allows the 81widespread use of Kerberized applications by users without requiring 82them to register first--a requirement that has no inherent security 83benefit. 84 85As noted above, a convenient and efficient place to introduce 86public-key cryptography into Kerberos is in the initial 87authentication exchange. This document describes the methods and 88data formats for integrating public-key cryptography into Kerberos 89initial authentication. Another document (PKCROSS) describes a 90similar protocol for Kerberos cross-realm authentication. 91 92 933. Extensions 94 95This section describes extensions to RFC 1510bis for supporting the 96use of public-key cryptography in the initial request for a ticket 97granting ticket (TGT). 98 99Briefly, the following changes to RFC 1510bis are proposed: 100 101 1. If public-key authentication is indicated, the client sends 102 the user's public-key data and an authenticator in a 103 preauthentication field accompanying the usual request. 104 This authenticator is signed by the user's private 105 signature key. 106 107 2. The KDC verifies the client's request against its own 108 policy and certification authorities. 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 randomly generated key, signed using the KDC's 114 signature key and encrypted using the user'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 key data required by the client to obtain the encryption 121 key is returned in a preauthentication field accompanying 122 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. 129Implementation of all specified formats and uses in these sections 130is REQUIRED for compliance with PKINIT. 131 132 1333.1. Definitions 134 135 1363.1.1. Required Algorithms 137 138[What is the current list of required algorithm? --brian] 139 140 1413.1.2. Defined Message and Encryption Types 142 143PKINIT makes use of the following new preauthentication types: 144 145 PA-PK-AS-REQ TBD 146 PA-PK-AS-REP TBD 147 148PKINIT introduces the following new error types: 149 150 KDC_ERR_CLIENT_NOT_TRUSTED 62 151 KDC_ERR_KDC_NOT_TRUSTED 63 152 KDC_ERR_INVALID_SIG 64 153 KDC_ERR_KEY_TOO_WEAK 65 154 KDC_ERR_CERTIFICATE_MISMATCH 66 155 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 156 KDC_ERR_INVALID_CERTIFICATE 71 157 KDC_ERR_REVOKED_CERTIFICATE 72 158 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 159 KDC_ERR_CLIENT_NAME_MISMATCH 75 160 161PKINIT uses the following typed data types for errors: 162 163 TD-DH-PARAMETERS 102 164 TD-TRUSTED-CERTIFIERS 104 165 TD-CERTIFICATE-INDEX 105 166 167PKINIT defines the following encryption types, for use in the AS-REQ 168message (to indicate acceptance of the corresponding encryption OIDs 169in PKINIT): 170 171 dsaWithSHA1-CmsOID 9 172 md5WithRSAEncryption-CmsOID 10 173 sha1WithRSAEncryption-CmsOID 11 174 rc2CBC-EnvOID 12 175 rsaEncryption-EnvOID (PKCS1 v1.5) 13 176 rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14 177 des-ede3-cbc-Env-OID 15 178 179The above encryption types are used (in PKINIT) only within CMS [8] 180structures within the PKINIT preauthentication fields. Their use 181within Kerberos EncryptedData structures is unspecified. 182 183 1843.1.3. Algorithm Identifiers 185 186PKINIT does not define, but does make use of, the following 187algorithm identifiers. 188 189PKINIT uses the following algorithm identifier for Diffie-Hellman 190key agreement [11]: 191 192 dhpublicnumber 193 194PKINIT uses the following signature algorithm identifiers [8, 12]: 195 196 sha-1WithRSAEncryption (RSA with SHA1) 197 md5WithRSAEncryption (RSA with MD5) 198 id-dsa-with-sha1 (DSA with SHA1) 199 200PKINIT uses the following encryption algorithm identifiers [12] for 201encrypting the temporary key with a public key: 202 203 rsaEncryption (PKCS1 v1.5) 204 id-RSAES-OAEP (PKCS1 v2.0) 205 206These OIDs are not to be confused with the encryption types listed 207above. 208 209PKINIT uses the following algorithm identifiers [8] for encrypting 210the reply key with the temporary key: 211 212 des-ede3-cbc (three-key 3DES, CBC mode) 213 rc2-cbc (RC2, CBC mode) 214 215Again, these OIDs are not to be confused with the encryption types 216listed above. 217 218 2193.2. PKINIT Preauthentication Syntax and Use 220 221In this section, we describe the syntax and use of the various 222preauthentication fields employed to implement PKINIT. 223 224 2253.2.1. Client Request 226 227The initial authentication request (AS-REQ) is sent as per RFC 2281510bis, except that a preauthentication field containing data 229signed by the user's private signature key accompanies the request, 230as follows: 231 232 PA-PK-AS-REQ ::= SEQUENCE { 233 -- PAType TBD 234 signedAuthPack [0] ContentInfo, 235 -- Defined in CMS. 236 -- Type is SignedData. 237 -- Content is AuthPack 238 -- (defined below). 239 trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL, 240 -- A list of CAs, trusted by 241 -- the client, used to certify 242 -- KDCs. 243 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 244 -- Defined in CMS. 245 -- Identifies a particular KDC 246 -- certificate, if the client 247 -- already has it. 248 encryptionCert [3] IssuerAndSerialNumber OPTIONAL, 249 -- May identify the user's 250 -- Diffie-Hellman certificate, 251 -- or an RSA encryption key 252 -- certificate. 253 ... 254 } 255 256 TrustedCAs ::= CHOICE { 257 caName [0] Name, 258 -- Fully qualified X.500 name 259 -- as defined in X.509 [11]. 260 issuerAndSerial [1] IssuerAndSerialNumber, 261 -- Identifies a specific CA 262 -- certificate, if the client 263 -- only trusts one. 264 ... 265 } 266 267[Should we even allow principalName as a choice? --brian] 268 269 AuthPack ::= SEQUENCE { 270 pkAuthenticator [0] PKAuthenticator, 271 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 272 -- Defined in X.509, 273 -- reproduced below. 274 -- Present only if the client 275 -- is using ephemeral-ephemeral 276 -- Diffie-Hellman. 277 } 278 279 PKAuthenticator ::= SEQUENCE { 280 cusec [0] INTEGER, 281 ctime [1] KerberosTime, 282 -- cusec and ctime are used as 283 -- in RFC 1510bis, for replay 284 -- prevention. 285 nonce [2] INTEGER, 286 -- Binds reply to request, 287 -- except is zero when client 288 -- will accept cached 289 -- Diffie-Hellman parameters 290 -- from KDC and MUST NOT be 291 -- zero otherwise. 292 paChecksum [3] Checksum, 293 -- Defined in RFC 1510bis. 294 -- Performed over KDC-REQ-BODY, 295 -- must be unkeyed. 296 ... 297 } 298 299 SubjectPublicKeyInfo ::= SEQUENCE { 300 -- As defined in X.509. 301 algorithm AlgorithmIdentifier, 302 -- Equals dhpublicnumber (see 303 -- AlgorithmIdentifier, below) 304 -- for PKINIT. 305 subjectPublicKey BIT STRING 306 -- Equals public exponent 307 -- (INTEGER encoded as payload 308 -- of BIT STRING) for PKINIT. 309 } 310 311 AlgorithmIdentifier ::= SEQUENCE { 312 -- As defined in X.509. 313 algorithm OBJECT IDENTIFIER, 314 -- dhpublicnumber is 315 -- { iso (1) member-body (2) 316 -- US (840) ansi-x942 (10046) 317 -- number-type (2) 1 } 318 -- From RFC 2459 [11]. 319 parameters ANY DEFINED BY algorithm OPTIONAL 320 -- Content is DomainParameters 321 -- (see below) for PKINIT. 322 } 323 324 DomainParameters ::= SEQUENCE { 325 -- As defined in RFC 2459. 326 p INTEGER, 327 -- p is the odd prime, equals 328 -- jq+1. 329 g INTEGER, 330 -- Generator. 331 q INTEGER, 332 -- Divides p-1. 333 j INTEGER OPTIONAL, 334 -- Subgroup factor. 335 validationParms ValidationParms OPTIONAL 336 } 337 338 ValidationParms ::= SEQUENCE { 339 -- As defined in RFC 2459. 340 seed BIT STRING, 341 -- Seed for the system parameter 342 -- generation process. 343 pgenCounter INTEGER 344 -- Integer value output as part 345 -- of the system parameter 346 -- generation process. 347 } 348 349The ContentInfo in the signedAuthPack is filled out as follows: 350 351 1. The eContent field contains data of type AuthPack. It MUST 352 contain the pkAuthenticator, and MAY also contain the 353 user's Diffie-Hellman public value (clientPublicValue). 354 355 2. The eContentType field MUST contain the OID value for 356 pkauthdata: { iso (1) org (3) dod (6) internet (1) 357 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)} 358 359 3. The signerInfos field MUST contain the signature of the 360 AuthPack. 361 362 4. The certificates field MUST contain at least a signature 363 verification certificate chain that the KDC can use to 364 verify the signature on the AuthPack. Additionally, the 365 client may also insert an encryption certificate chain, if 366 (for example) the client is not using ephemeral-ephemeral 367 Diffie-Hellman. 368 369 5. If a Diffie-Hellman key is being used, the parameters SHOULD 370 be chosen from the First or Second defined Oakley Groups. 371 (See RFC 2409 [c].) 372 373 6. The KDC may wish to use cached Diffie-Hellman parameters. 374 To indicate acceptance of caching, the client sends zero in 375 the nonce field of the pkAuthenticator. Zero is not a valid 376 value for this field under any other circumstances. Since 377 zero is used to indicate acceptance of cached parameters, 378 message binding in this case is performed instead using the 379 nonce in the main request. 380 381 3823.2.2. Validation of Client Request 383 384Upon receiving the client's request, the KDC validates it. This 385section describes the steps that the KDC MUST (unless otherwise 386noted) take in validating the request. 387 388The KDC must look for a user certificate in the signedAuthPack. 389If it cannot find one signed by a CA it trusts, it sends back an 390error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 391e-data for this error is a SEQUENCE OF TypedData: 392 393 TypedData ::= SEQUENCE { 394 -- As defined in RFC 1510bis. 395 data-type [0] INTEGER, 396 data-value [1] OCTET STRING 397 } 398 399For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the 400data-value is an OCTET STRING containing the DER encoding of 401 402 TrustedCertifiers ::= SEQUENCE OF Name 403 404If, while verifying the certificate chain, the KDC determines that 405the signature on one of the certificates in the signedAuthPack is 406invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 407The accompanying e-data for this error is a SEQUENCE OF TypedData, 408whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 409OCTET STRING containing the DER encoding of the index into the 410CertificateSet field, ordered as sent by the client: 411 412 CertificateIndex ::= INTEGER 413 -- 0 = first certificate (in 414 -- order of encoding), 415 -- 1 = second certificate, etc. 416 417If more than one signature is invalid, the KDC sends one TypedData 418per invalid signature. 419 420The KDC MAY also check whether any of the certificates in the user's 421chain have been revoked. If any of them have been revoked, the KDC 422returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 423attempts to determine the revocation status but is unable to do so, 424it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. In 425either case, the certificate or certificates affected are identified 426exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see 427above). 428 429If the certificate chain is successfully validated, but the name in 430the user's certificate does not match the name given in the request, 431the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There 432is no accompanying e-data for this error. 433 434Even if the chain is validated, and the names in the certificate and 435the request match, the KDC may decide not to trust the client. For 436example, the certificate may include (or not include) an Enhanced 437Key Usage (EKU) OID in the extensions field. As a matter of local 438policy, the KDC may decide to reject requests on the basis of the 439absence or presence of specific EKU OIDs. In this case, the KDC 440returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the 441benefit of implementors, we define a PKINIT EKU OID as follows: 442{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) 443pkinit (3) pkekuoid (2) }. 444 445If the certificate chain and usage check out, but the client's 446signature on the signedAuthPack fails to verify, the KDC returns an 447error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data 448for this error. 449 450[What about the case when all this checks out but one or more 451certificates is rejected for other reasons? For example, perhaps 452the key is too short for local policy. --DRE] 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. If 456the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT 457or KRB_AP_ERR_SKEW, respectively. 458 459Finally, if the clientPublicValue is filled in, indicating that the 460client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC 461checks to see if the parameters satisfy its policy. If they do not, 462it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying 463e-data is a SEQUENCE OF TypedData, whose data-type is 464TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing 465the DER encoding of a DomainParameters (see above), including 466appropriate Diffie-Hellman parameters with which to retry the 467request. 468 469[This makes no sense. For example, maybe the key is too strong for 470local policy. --DRE] 471 472In order to establish authenticity of the reply, the KDC will sign 473some key data (either the random key used to encrypt the reply in 474the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to 475generate the reply-encrypting key in the case of a ReplyKeyPack). 476The signature certificate to be used is to be selected as follows: 477 478 1. If the client included a kdcCert field in the PA-PK-AS-REQ, 479 use the referred-to certificate, if the KDC has it. If it 480 does not, the KDC returns an error of type 481 KDC_ERR_CERTIFICATE_MISMATCH. 482 483 2. Otherwise, if the client did not include a kdcCert field, 484 but did include a trustedCertifiers field, and the KDC 485 possesses a certificate issued by one of the listed 486 certifiers, use that certificate. if it does not possess 487 one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. 488 489 3. Otherwise, if the client included neither a kdcCert field 490 nor a trustedCertifiers field, and the KDC has only one 491 signature certificate, use that certificate. If it has 492 more than one certificate, it returns an error of type 493 KDC_ERR_CERTIFICATE_MISMATCH. 494 495 4963.2.3. KDC Reply 497 498Assuming that the client's request has been properly validated, the 499KDC proceeds as per RFC 1510bis, except as follows. 500 501The user's name as represented in the AS-REP must be derived from 502the certificate provided in the client's request. If the KDC has 503its own mapping from the name in the certificate to a Kerberos name, 504it uses that Kerberos name. 505 506Otherwise, if the certificate contains a subjectAltName extension 507with PrincipalName, it uses that name. In this case, the realm in 508the ticket is that of the local realm (or some other realm name 509chosen by that realm). (OID and syntax for this extension to be 510specified here.) Otherwise, the KDC returns an error of type 511KDC_ERR_CLIENT_NAME_MISMATCH. 512 513In addition, the certifiers in the certification path of the user's 514certificate MUST be added to an authdata (to be specified at a later 515time). 516 517The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then 518encrypts the reply as usual, but not with the user's long-term key. 519Instead, it encrypts it with either a random encryption key, or a 520key derived through a Diffie-Hellman exchange. Which is the case is 521indicated by the contents of the PA-PK-AS-REP (note tags): 522 523 PA-PK-AS-REP ::= CHOICE { 524 -- PAType YY (TBD) 525 dhSignedData [0] ContentInfo, 526 -- Type is SignedData. 527 -- Content is KDCDHKeyInfo 528 -- (defined below). 529 encKeyPack [1] ContentInfo, 530 -- Type is EnvelopedData. 531 -- Content is ReplyKeyPack 532 -- (defined below). 533 ... 534 } 535 536Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an 537encKeyPack, but not both. The former contains data of type 538KDCDHKeyInfo, and is used only when the reply is encrypted using a 539Diffie-Hellman derived key: 540 541 KDCDHKeyInfo ::= SEQUENCE { 542 subjectPublicKey [0] BIT STRING, 543 -- Equals public exponent 544 -- (g^a mod p). 545 -- INTEGER encoded as payload 546 -- of BIT STRING. 547 nonce [1] INTEGER, 548 -- Binds reply to request. 549 -- Exception: A value of zero 550 -- indicates that the KDC is 551 -- using cached values. 552 dhKeyExpiration [2] KerberosTime OPTIONAL, 553 -- Expiration time for KDC's 554 -- cached values. 555 ... 556 } 557 558The fields of the ContentInfo for dhSignedData are to be filled in 559as follows: 560 561 1. The eContent field contains data of type KDCDHKeyInfo. 562 563 2. The eContentType field contains the OID value for 564 pkdhkeydata: { iso (1) org (3) dod (6) internet (1) 565 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) } 566 567 3. The signerInfos field contains a single signerInfo, which is 568 the signature of the KDCDHKeyInfo. 569 570 4. The certificates field contains a signature verification 571 certificate chain that the client may use to verify the 572 KDC's signature over the KDCDHKeyInfo.) It may only be left 573 empty if the client did not include a trustedCertifiers 574 field in the PA-PK-AS-REQ, indicating that it has the KDC's 575 certificate. 576 577 5. If the client and KDC agree to use cached parameters, the 578 KDC SHOULD return a zero in the nonce field and include the 579 expiration time of the cached values in the dhKeyExpiration 580 field. If this time is exceeded, the client SHOULD NOT use 581 the reply. If the time is absent, the client SHOULD NOT use 582 the reply and MAY resubmit a request with a non-zero nonce, 583 thus indicating non-acceptance of the cached parameters. 584 585The key is derived as follows: Both the KDC and the client calculate 586the value g^(ab) mod p, where a and b are the client and KDC's 587private exponents, respectively. They both take the first N bits of 588this secret value and convert it into a reply key, where N depends 589on the key type. 590 591 1. For example, if the key type is DES, N = 64 bits, where some 592 of the bits are replaced with parity bits, according to FIPS 593 PUB 74 [c]. 594 595 2. If the key type is (three-key) 3DES, N = 192 bits, where 596 some of the bits are replaced with parity bits, again 597 according to FIPS PUB 74. 598 599If the KDC and client are not using Diffie-Hellman, the KDC encrypts 600the reply with an encryption key, packed in the encKeyPack, which 601contains data of type ReplyKeyPack: 602 603 ReplyKeyPack ::= SEQUENCE { 604 replyKey [0] EncryptionKey, 605 -- Defined in RFC 1510bis. 606 -- Used to encrypt main reply. 607 -- MUST be at least as strong as 608 -- enctype of session key. 609 nonce [1] INTEGER, 610 -- Binds reply to request. 611 ... 612 } 613 614[What exactly does "at least as strong" mean? --DRE] 615 616The fields of the ContentInfo for encKeyPack MUST be filled in as 617follows: 618 619 1. The innermost data is of type SignedData. The eContent for 620 this data is of type ReplyKeyPack. 621 622 2. The eContentType for this data contains the OID value for 623 pkrkeydata: { iso (1) org (3) dod (6) internet (1) 624 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) } 625 626 3. The signerInfos field contains a single signerInfo, which is 627 the signature of the ReplyKeyPack. 628 629 4. The certificates field contains a signature verification 630 certificate chain, which the client may use to verify the 631 KDC's signature over the ReplyKeyPack.) It may only be left 632 empty if the client did not include a trustedCertifiers 633 field in the PA-PK-AS-REQ, indicating that it has the KDC's 634 certificate. 635 636 5. The outer data is of type EnvelopedData. The 637 encryptedContent for this data is the SignedData described 638 in items 1 through 4, above. 639 640 6. The encryptedContentType for this data contains the OID 641 value for id-signedData: { iso (1) member-body (2) us (840) 642 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } 643 644 7. The recipientInfos field is a SET which MUST contain exactly 645 one member of type KeyTransRecipientInfo. The encryptedKey 646 for this member contains the temporary key which is 647 encrypted using the client's public key. 648 649 8. Neither the unprotectedAttrs field nor the originatorInfo 650 field is required for PKINIT. 651 652 6533.2.4. Validation of KDC Reply 654 655Upon receipt of the KDC's reply, the client proceeds as follows. If 656the PA-PK-AS-REP contains a dhSignedData, the client obtains and 657verifies the Diffie-Hellman parameters, and obtains the shared key 658as described above. Otherwise, the message contains an encKeyPack, 659and the client decrypts and verifies the temporary encryption key. 660In either case, the client then decrypts the main reply with the 661resulting key, and then proceeds as described in RFC 1510bis. 662 663 6644. Security Considerations 665 666PKINIT raises certain security considerations beyond those that can 667be regulated strictly in protocol definitions. We will address them 668in this section. 669 670PKINIT extends the cross-realm model to the public-key 671infrastructure. Anyone using PKINIT must be aware of how the 672certification infrastructure they are linking to works. 673 674Also, as in standard Kerberos, PKINIT presents the possibility of 675interactions between cryptosystems of varying strengths, and this 676now includes public-key cryptosystems. Many systems, for example, 677allow the use of 512-bit public keys. Using such keys to wrap data 678encrypted under strong conventional cryptosystems, such as 3DES, may 679be inappropriate. 680 681PKINIT calls for randomly generated keys for conventional 682cryptosystems. Many such systems contain systematically "weak" 683keys. For recommendations regarding these weak keys, see RFC 6841510bis. 685 686Care should be taken in how certificates are chosen for the purposes 687of authentication using PKINIT. Some local policies may require 688that key escrow be applied for certain certificate types. People 689deploying PKINIT should be aware of the implications of using 690certificates that have escrowed keys for the purposes of 691authentication. 692 693PKINIT does not provide for a "return routability" test to prevent 694attackers from mounting a denial-of-service attack on the KDC by 695causing it to perform unnecessary and expensive public-key 696operations. Strictly speaking, this is also true of standard 697Kerberos, although the potential cost is not as great, because 698standard Kerberos does not make use of public-key cryptography. 699 700 7015. Acknowledgements 702 703Some of the ideas on which this proposal is based arose during 704discussions over several years between members of the SAAG, the IETF 705CAT working group, and the PSRG, regarding integration of Kerberos 706and SPX. Some ideas have also been drawn from the DASS system. 707These changes are by no means endorsed by these groups. This is an 708attempt to revive some of the goals of those groups, and this 709proposal approaches those goals primarily from the Kerberos 710perspective. Lastly, comments from groups working on similar ideas 711in DCE have been invaluable. 712 713 7146. Expiration Date 715 716This draft expires May 31, 2004. 717 718 7197. Bibliography 720 721[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 722(V5). Request for Comments 1510. 723 724[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 725for Computer Networks, IEEE Communications, 32(9):33-38. September 7261994. 727 728[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 729Using Public Key Cryptography. Symposium On Network and Distributed 730System Security, 1997. 731 732[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 733Protocol. In Proceedings of the USENIX Workshop on Electronic 734Commerce, July 1995. 735 736[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request 737for Comments 2246, January 1999. 738 739[6] B.C. Neuman, Proxy-Based Authorization and Accounting for 740Distributed Systems. In Proceedings of the 13th International 741Conference on Distributed Computing Systems, May 1993. 742 743[7] ITU-T (formerly CCITT) Information technology - Open Systems 744Interconnection - The Directory: Authentication Framework 745Recommendation X.509 ISO/IEC 9594-8 746 747[8] R. Housley. Cryptographic Message Syntax. 748draft-ietf-smime-cms-13.txt, April 1999, approved for publication as 749RFC. 750 751[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA 752Laboratories Technical Note Version 1.5. Revised November 1, 1993 753 754[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data 755Security, Inc. A Description of the RC2(r) Encryption Algorithm. 756March 1998. Request for Comments 2268. 757 758[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 759Key Infrastructure, Certificate and CRL Profile, January 1999. 760Request for Comments 2459. 761 762[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 763Specifications, October 1998. Request for Comments 2437. 764 765[13] ITU-T (formerly CCITT) Information Processing Systems - Open 766Systems Interconnection - Specification of Abstract Syntax Notation 767One (ASN.1) Rec. X.680 ISO/IEC 8824-1 768 769[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA 770Laboratories Technical Note, Version 1.4, Revised November 1, 1993. 771 772 7738. Authors 774 775Brian Tung 776Clifford Neuman 777USC Information Sciences Institute 7784676 Admiralty Way Suite 1001 779Marina del Rey CA 90292-6695 780Phone: +1 310 822 1511 781E-mail: {brian,bcn}@isi.edu 782 783Matthew Hur 784Ari Medvinsky 785Microsoft Corporation 786One Microsoft Way 787Redmond WA 98052 788Phone: +1 425 707 3336 789E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 790 791Sasha Medvinsky 792Motorola, Inc. 7936450 Sequence Drive 794San Diego, CA 92121 795+1 858 404 2367 796E-mail: smedvinsky@motorola.com 797 798John Wray 799Iris Associates, Inc. 8005 Technology Park Dr. 801Westford, MA 01886 802E-mail: John_Wray@iris.com 803 804Jonathan Trostle 805E-mail: jtrostle@world.std.com 806