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