idnits 2.17.00 (12 Aug 2021) /tmp/idnits26335/draft-ietf-cat-kerberos-pk-init-20.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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 905. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 1110 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.) ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 134: '... implementations MUST support the foll...' RFC 2119 keyword, line 195: '... All structures MUST be encoded using...' RFC 2119 keyword, line 248: '... trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,...' RFC 2119 keyword, line 252: '... kdcCert [2] IssuerAndSerialNumber OPTIONAL,...' RFC 2119 keyword, line 272: '... clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 889 looks like a reference -- Missing reference section? '2' on line 883 looks like a reference -- Missing reference section? '9' on line 746 looks like a reference -- Missing reference section? '8' on line 742 looks like a reference -- Missing reference section? '12' on line 208 looks like a reference -- Missing reference section? '5' on line 732 looks like a reference -- Missing reference section? '0' on line 888 looks like a reference -- Missing reference section? '4' on line 728 looks like a reference -- Missing reference section? '3' on line 855 looks like a reference -- Missing reference section? '10' on line 749 looks like a reference -- Missing reference section? '6' on line 735 looks like a reference -- Missing reference section? '7' on line 738 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 15 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-20.txt Clifford Neuman 3 Updates: CLARIFICATIONS USC/ISI 4 expires 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 13 Public Key Cryptography for Initial Authentication in Kerberos 15 0. Status Of This Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 This document is an Internet-Draft and is in full conformance with 23 all provision of Section 10 of RFC 2026. Internet-Drafts are 24 working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 The distribution of this memo is unlimited. It is filed as 40 draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005. 41 Please send comments to the authors. 43 1. Abstract 45 This document describes protocol extensions (hereafter called 46 PKINIT) to the Kerberos protocol specification ([1], hereafter 47 called CLARIFICATIONS). These extensions provide a method for 48 integrating public key cryptography into the initial authentication 49 exchange, by passing digital certificates and associated 50 authenticators in preauthentication data fields. 52 2. Introduction 54 A client typically authenticates itself to a service in Kerberos 55 using three distinct though related exchanges. First, the client 56 requests a ticket-granting ticket (TGT) from the Kerberos 57 authentication server (AS). Then, it uses the TGT to request a 58 service ticket from the Kerberos ticket-granting server (TGS). 59 Usually, the AS and TGS are integrated in a single device known as 60 a Kerberos Key Distribution Center, or KDC. (In this document, we 61 will refer to both the AS and the TGS as the KDC.) Finally, the 62 client uses the service ticket to authenticate itself to the 63 service. 65 The advantage afforded by the TGT is that the client need explicitly 66 request a ticket and expose his credentials only once. The TGT and 67 its associated session key can then be used for any subsequent 68 requests. One result of this is that all further authentication is 69 independent of the method by which the initial authentication was 70 performed. Consequently, initial authentication provides a 71 convenient place to integrate public-key cryptography into Kerberos 72 authentication. 74 As defined, Kerberos authentication exchanges use symmetric-key 75 cryptography, in part for performance. One cost of using 76 symmetric-key cryptography is that the keys must be shared, so that 77 before a client can authenticate itself, he must already be 78 registered with the KDC. 80 Conversely, public-key cryptography (in conjunction with an 81 established Public Key Infrastructure) permits authentication 82 without prior registration with a KDC. Adding it to Kerberos allows 83 the widespread use of Kerberized applications by clients without 84 requiring them to register first with a KDC--a requirement that has 85 no inherent security benefit. 87 As noted above, a convenient and efficient place to introduce 88 public-key cryptography into Kerberos is in the initial 89 authentication exchange. This document describes the methods and 90 data formats for integrating public-key cryptography into Kerberos 91 initial authentication. 93 3. Extensions 95 This section describes extensions to CLARIFICATIONS for supporting 96 the use of public-key cryptography in the initial request for a 97 ticket. 99 Briefly, this document defines the following extensions to 100 CLARIFICATIONS: 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. 107 2. The KDC tests the client's request against its policy and 108 trusted Certification Authorities (CAs). 110 3. If the request passes the verification tests, the KDC 111 replies as usual, but the reply is encrypted using either: 113 a. a symmetric encryption key, signed using the KDC's 114 signature key and encrypted using the client's encryption 115 key; or 117 b. a key generated through a Diffie-Hellman exchange with 118 the client, signed using the KDC's signature key. 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. 124 4. The client obtains the encryption key, decrypts the reply, 125 and then proceeds as usual. 127 Section 3.1 of this document defines the necessary message formats. 128 Section 3.2 describes their syntax and use in greater detail. 130 3.1. Definitions 132 3.1.1. Required Algorithms 134 All PKINIT implementations MUST support the following algorithms: 136 - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. 138 - Signature algorithm: SHA-1 digest and RSA. 140 - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman 141 with a non-zero nonce. 143 - Unkeyed checksum type for the paChecksum member of 144 PKAuthenticator: SHA1 (unkeyed). 146 3.1.2. Defined Message and Encryption Types 148 PKINIT makes use of the following new preauthentication types: 150 PA-PK-AS-REQ TBD 151 PA-PK-AS-REP TBD 153 PKINIT also makes use of the following new authorization data type: 155 AD-INITIAL-VERIFIED-CAS TBD 157 PKINIT introduces the following new error codes: 159 KDC_ERR_CLIENT_NOT_TRUSTED 62 160 KDC_ERR_KDC_NOT_TRUSTED 63 161 KDC_ERR_INVALID_SIG 64 162 KDC_ERR_KEY_SIZE 65 163 KDC_ERR_CERTIFICATE_MISMATCH 66 164 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 165 KDC_ERR_INVALID_CERTIFICATE 71 166 KDC_ERR_REVOKED_CERTIFICATE 72 167 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 168 KDC_ERR_CLIENT_NAME_MISMATCH 75 170 PKINIT uses the following typed data types for errors: 172 TD-DH-PARAMETERS TBD 173 TD-TRUSTED-CERTIFIERS 104 174 TD-CERTIFICATE-INDEX 105 176 PKINIT defines the following encryption types, for use in the AS-REQ 177 message (to indicate acceptance of the corresponding encryption OIDs 178 in PKINIT): 180 dsaWithSHA1-CmsOID 9 181 md5WithRSAEncryption-CmsOID 10 182 sha1WithRSAEncryption-CmsOID 11 183 rc2CBC-EnvOID 12 184 rsaEncryption-EnvOID (PKCS1 v1.5) 13 185 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 186 des-ede3-cbc-EnvOID 15 188 The above encryption types are used by the client only within the 189 KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their 190 use within Kerberos EncryptedData structures is not specified by this 191 document. 193 The ASN.1 module for all structures defined in this document (plus 194 IMPORT statements for all imported structures) are given in Appendix 195 A. All structures MUST be encoded using Distinguished Encoding 196 Rules (DER). 198 3.1.3. Algorithm Identifiers 200 PKINIT does not define, but does make use of, the following 201 algorithm identifiers. 203 PKINIT uses the following algorithm identifier for Diffie-Hellman 204 key agreement [9]: 206 dhpublicnumber 208 PKINIT uses the following signature algorithm identifiers [8, 12]: 210 sha-1WithRSAEncryption (RSA with SHA1) 211 md5WithRSAEncryption (RSA with MD5) 212 id-dsa-with-sha1 (DSA with SHA1) 214 PKINIT uses the following encryption algorithm identifiers [5] for 215 encrypting the temporary key with a public key: 217 rsaEncryption (PKCS1 v1.5) 218 id-RSAES-OAEP (PKCS1 v2.0) 220 PKINIT uses the following algorithm identifiers [2] for encrypting 221 the reply key with the temporary key: 223 des-ede3-cbc (three-key 3DES, CBC mode) 224 rc2-cbc (RC2, CBC mode) 226 Kerberos data structures require the use of integer etypes, while CMS 227 objects use OIDs. Therefore, each cryptographic algorithm supported 228 by PKINIT is identified both by a CMS OID and by an equivalent 229 Kerberos etype (defined in section 3.1.2). 231 3.2. PKINIT Preauthentication Syntax and Use 233 This section defines the syntax and use of the various 234 preauthentication fields employed by PKINIT. 236 3.2.1. Client Request 238 The initial authentication request (AS-REQ) is sent as per RFC 239 1510bis; in addition, a preauthentication field contains data signed 240 by the client's private signature key, as follows: 242 PA-PK-AS-REQ ::= SEQUENCE { 243 signedAuthPack [0] ContentInfo, 244 -- Defined in CMS [2]. 245 -- Type is SignedData. 246 -- Content is AuthPack 247 -- (defined below). 248 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 249 -- A list of CAs, trusted by 250 -- the client, used to certify 251 -- KDCs. 252 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 253 -- Defined in CMS [2]. 254 -- Identifies a particular KDC 255 -- certificate, if the client 256 -- already has it. 257 ... 258 } 260 TrustedCA ::= CHOICE { 261 caName [0] Name, 262 -- Fully qualified X.500 name 263 -- as defined in RFC 3280 [4]. 264 issuerAndSerial [2] IssuerAndSerialNumber, 265 -- Identifies a specific CA 266 -- certificate. 267 ... 268 } 270 AuthPack ::= SEQUENCE { 271 pkAuthenticator [0] PKAuthenticator, 272 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 273 -- Defined in RFC 3280 [4]. 274 -- Present only if the client 275 -- is using ephemeral-ephemeral 276 -- Diffie-Hellman. 277 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 278 OPTIONAL, 279 -- List of CMS encryption types 280 -- supported by client in order 281 -- of (decreasing) preference. 282 ... 283 } 285 PKAuthenticator ::= SEQUENCE { 286 cusec [0] INTEGER, 287 ctime [1] KerberosTime, 288 -- cusec and ctime are used as 289 -- in CLARIFICATIONS, for replay 290 -- prevention. 291 nonce [2] INTEGER (0..4294967295), 292 -- Binds reply to request, 293 -- MUST be zero when client 294 -- will accept cached 295 -- Diffie-Hellman parameters 296 -- from KDC. MUST NOT be 297 -- zero otherwise. 298 paChecksum [3] Checksum, 299 -- Defined in CLARIFICATIONS. 300 -- Performed over KDC-REQ-BODY, 301 -- MUST be unkeyed. 302 ... 303 } 305 The ContentInfo in the signedAuthPack is filled out as follows: 307 1. The eContent field contains data of type AuthPack. It MUST 308 contain the pkAuthenticator, and MAY also contain the 309 client's Diffie-Hellman public value (clientPublicValue). 311 2. The eContentType field MUST contain the OID value for 312 id-pkauthdata: { iso(1) org(3) dod(6) internet(1) 313 security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} 315 3. The signerInfos field MUST contain the signature over the 316 AuthPack. 318 4. The certificates field MUST contain at least a signature 319 verification certificate chain that the KDC can use to 320 verify the signature over the AuthPack. Additionally, the 321 client MAY insert an encryption certificate chain, if 322 (for example) the client is not using ephemeral-ephemeral 323 Diffie-Hellman. 325 5. If a Diffie-Hellman key is being used, the parameters SHOULD 326 be chosen from the First or Second defined Oakley Groups. 327 (See RFC 2409 [10].) 329 6. The KDC may wish to use cached Diffie-Hellman parameters. 330 To indicate acceptance of caching, the client sends zero in 331 the nonce field of the pkAuthenticator. Zero is not a valid 332 value for this field under any other circumstances. Since 333 zero is used to indicate acceptance of cached parameters, 334 message binding in this case is performed using only the 335 nonce in the main request. 337 3.2.2. Validation of Client Request 339 Upon receiving the client's request, the KDC validates it. This 340 section describes the steps that the KDC MUST (unless otherwise 341 noted) take in validating the request. 343 The KDC must look for a client certificate in the signedAuthPack. 344 If it cannot find one signed by a CA it trusts, it sends back an 345 error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 346 e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC 347 1510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS, 348 and the data-value is an OCTET STRING containing the DER encoding of 350 TrustedCertifiers ::= SEQUENCE OF Name 352 If, while verifying the certificate chain, the KDC determines that 353 the signature on one of the certificates in the signedAuthPack is 354 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 355 The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA, 356 whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 357 OCTET STRING containing the DER encoding of the index into the 358 CertificateSet field, ordered as sent by the client: 360 CertificateIndex ::= IssuerAndSerialNumber 361 -- IssuerAndSerialNumber of 362 -- certificate with invalid signature 364 If more than one certificate signature is invalid, the KDC MAY send 365 one TYPED-DATA per invalid signature. 367 The KDC MAY also check whether any certificates in the client's 368 chain have been revoked. If any of them have been revoked, the KDC 369 MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 370 attempts to determine the revocation status but is unable to do so, 371 it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 372 The certificate or certificates affected are identified exactly as 373 for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 375 In addition to validating the certificate chain, the KDC MUST also 376 check that the certificate properly maps to the client's principal name 377 as specified in the AS-REQ as follows: 379 1. If the KDC has its own mapping from the name in the 380 certificate to a Kerberos name, it uses that Kerberos 381 name. 383 2. Otherwise, if the certificate contains a SubjectAltName 384 extension with a Kerberos name in the otherName field, 385 it uses that name. The otherName field (of type AnotherName) 386 in the SubjectAltName extension MUST contain the following: 388 The type-id is: 390 krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) 391 internet (1) security (5) kerberosv5 (2) 2 } 393 The value is: 395 KRB5PrincipalName ::= SEQUENCE { 396 realm [0] Realm, 397 principalName [1] PrincipalName 398 } 400 If the KDC does not have its own mapping and there is no Kerberos 401 name present in the certificate, or if the name in the request does 402 not match the name in the certificate (including the realm name), or 403 if there is no name in the request, the KDC MUST return error code 404 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 405 for this error. 407 Even if the chain is validated, and the names in the certificate and 408 the request match, the KDC may decide not to trust the client. For 409 example, the certificate may include an Enxtended Key Usage (EKU) OID 410 in the extensions field. As a matter of local policy, the KDC may 411 decide to reject requests on the basis of the absence or presence of 412 specific EKU OIDs. In this case, the KDC MUST return error code 413 KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: 415 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 416 pkinit(3) pkekuoid(4) } 418 If the client's signature on the signedAuthPack fails to verify, the KDC 419 MUST return error KDC_ERR_INVALID_SIG. There is no accompanying 420 e-data for this error. 422 The KDC MUST check the timestamp to ensure that the request is not 423 a replay, and that the time skew falls within acceptable limits. 424 The recommendations clock skew times in CLARIFICATIONS apply here. 425 If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 426 or KRB_AP_ERR_SKEW, respectively. 428 If the clientPublicValue is filled in, indicating that the client 429 wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to 430 see if the parameters satisfy its policy. If they do not, it MUST 431 return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a 432 SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and 433 whose data-value is an OCTET STRING containing the DER encoding of a 434 DomainParameters (see [3]), including appropriate Diffie-Hellman 435 parameters with which to retry the request. 437 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 438 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does 439 not have the corresponding certificate. 441 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client 442 did not include a kdcCert field, but did include a trustedCertifiers 443 field, and the KDC does not possesses a certificate issued by one of 444 the listed certifiers. 446 If there is a supportedCMSTypes field in the AuthPack, the KDC must 447 check to see if it supports any of the listed types. If it supports 448 more than one of the types, the KDC SHOULD use the one listed first. 449 If it does not support any of them, it MUST return an error of type 450 KRB5KDC_ERR_ETYPE_NOSUPP. 452 3.2.3. KDC Reply 454 Assuming that the client's request has been properly validated, the 455 KDC proceeds as per CLARIFICATIONS, except as follows. 457 The KDC MUST set the initial flag and include an authorization data 458 of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is 459 an OCTET STRING containing the DER encoding of InitialVerifiedCAs: 461 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 462 ca [0] Name, 463 Validated [1] BOOLEAN, 464 ... 465 } 467 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 468 containers if the list of CAs satisfies the KDC's realm's policy. 469 (This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 470 Furthermore, any TGS must copy such authorization data from tickets 471 used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 472 including the AD-IF-RELEVANT container, if present. 474 Application servers that understand this authorization data type 475 SHOULD apply local policy to determine whether a given ticket 476 bearing such a type *not* contained within an AD-IF-RELEVANT 477 container is acceptable. (This corresponds to the AP server 478 checking the transited field when the TRANSITED-POLICY-CHECKED flag 479 has not been set.) If such a data type is contained within an 480 AD-IF-RELEVANT container, AP servers MAY apply local policy to 481 determine whether the authorization data is acceptable. 483 The AS-REP is otherwise unchanged from CLARIFICATIONS. The KDC 484 encrypts the reply as usual, but not with the client's long-term 485 key. Instead, it encrypts it with either a generated encryption 486 key, or a key derived from a Diffie-Hellman exchange. The contents 487 of the PA-PK-AS-REP indicate the type of encryption key that was 488 used: 490 PA-PK-AS-REP ::= CHOICE { 491 dhSignedData [0] ContentInfo, 492 -- Type is SignedData. 493 -- Content is KDCDHKeyInfo 494 -- (defined below). 495 encKeyPack [1] ContentInfo, 496 -- Type is EnvelopedData. 497 -- Content is SignedData over 498 -- ReplyKeyPack (defined below). 499 ... 500 } 502 KDCDHKeyInfo ::= SEQUENCE { 503 subjectPublicKey [0] BIT STRING, 504 -- Equals public exponent 505 -- (g^a mod p). 506 -- INTEGER encoded as payload 507 -- of BIT STRING. 508 nonce [1] INTEGER, 509 -- Binds reply to request. 510 -- Exception: A value of zero 511 -- indicates that the KDC is 512 -- using cached values. 513 dhKeyExpiration [2] KerberosTime OPTIONAL, 514 -- Expiration time for KDC's 515 -- cached values. 516 ... 517 } 519 The fields of the ContentInfo for dhSignedData are to be filled in 520 as follows: 522 1. The eContent field contains data of type KDCDHKeyInfo. 524 2. The eContentType field contains the OID value for 525 id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 526 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } 528 3. The signerInfos field contains a single signerInfo, which is 529 the signature of the KDCDHKeyInfo. 531 4. The certificates field contains a signature verification 532 certificate chain that the client will use to verify the 533 KDC's signature over the KDCDHKeyInfo. This field may only 534 be left empty if the client did include a kdcCert field in 535 the PA-PK-AS-REQ, indicating that it has the KDC's 536 certificate. 538 5. If the client and KDC agree to use cached parameters, the 539 KDC MUST return a zero in the nonce field and include the 540 expiration time of the cached values in the dhKeyExpiration 541 field. If this time is exceeded, the client MUST NOT use 542 the reply. If the time is absent, the client MUST NOT use 543 the reply and MAY resubmit a request with a non-zero nonce, 544 thus indicating non-acceptance of the cached parameters. 546 The key is derived as follows: Both the KDC and the client calculate 547 the value g^(ab) mod p, where a and b are the client's and KDC's 548 private exponents, respectively. They both take the first k bits of 549 this secret value as a key generation seed, where the parameter k 550 (the size of the seed) is dependent on the selected key type, as 551 specified in [6]. The seed is then converted into a protocol key by 552 applying to it a random-to-key function, which is also dependent on 553 key type. 555 If the KDC and client are not using Diffie-Hellman, the KDC encrypts 556 the reply with an encryption key, packed in the encKeyPack, which 557 contains data of type ReplyKeyPack: 559 ReplyKeyPack ::= SEQUENCE { 560 replyKey [0] EncryptionKey, 561 -- Defined in CLARIFICATIONS. 562 -- Used to encrypt main reply. 563 -- MUST be at least as strong 564 -- as session key. (Using the 565 -- same enctype and a strong 566 -- prng should suffice, if no 567 -- stronger encryption system 568 -- is available.) 569 nonce [1] INTEGER (0..4294967295), 570 -- Binds reply to request. 571 ... 572 } 574 The fields of the ContentInfo for encKeyPack MUST be filled in as 575 follows: 577 1. The content is of type SignedData. The eContent for 578 the SignedData is of type ReplyKeyPack. 580 2. The eContentType for the SignedData contains the OID value 581 for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) 582 security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } 584 3. The signerInfos field contains a single signerInfo, which is 585 the signature of the ReplyKeyPack. 587 4. The certificates field contains a signature verification 588 certificate chain that the client will use to verify the 589 KDC's signature over the ReplyKeyPack. This field may only 590 be left empty if the client included a kdcCert field in the 591 PA-PK-AS-REQ, indicating that it has the KDC's certificate. 593 5. The contentType for the EnvelopedData contains the OID value 594 for id-signedData: { iso (1) member-body (2) us (840) rsadsi 595 (113549) pkcs (1) pkcs7 (7) signedData (2) } 597 6. The recipientInfos field is a SET which MUST contain exactly 598 one member of type KeyTransRecipientInfo. The encryptedKey 599 for this member contains the temporary key which is 600 encrypted using the client's public key. 602 7. The unprotectedAttrs or originatorInfo fields MAY be 603 present. 605 3.2.4. Validation of KDC Reply 607 Upon receipt of the KDC's reply, the client proceeds as follows. If 608 the PA-PK-AS-REP contains a dhSignedData, the client obtains and 609 verifies the Diffie-Hellman parameters, and obtains the shared key 610 as described above. Otherwise, the message contains an encKeyPack, 611 and the client decrypts and verifies the temporary encryption key. 613 In either case, the client MUST check to see if the included 614 certificate contains a subjectAltName extension of type dNSName or 615 iPAddress (if the KDC is specified by IP address instead of name). 616 If it does, it MUST check to see if that extension matches the KDC 617 it believes it is communicating with, with matching rules specified 618 in RFC 2459. Exception: If the client has some external information 619 as to the identity of the KDC, this check MAY be omitted. 621 The client also MUST check that the KDC's certificate contains an 622 extendedKeyUsage OID of id-pkkdcekuoid: 624 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 625 pkinit(3) pkkdcekuoid(5) } 627 If all applicable checks are satisfied, the client then decrypts the 628 main reply with the resulting key, and then proceeds as described in 629 CLARIFICATIONS. 631 4. Security Considerations 633 PKINIT raises certain security considerations beyond those that can 634 be regulated strictly in protocol definitions. We will address them 635 in this section. 637 PKINIT extends the cross-realm model to the public-key 638 infrastructure. Users of PKINIT must understand security policies 639 and procedures appropriate to the use of Public Key Infrastructures. 641 Standard Kerberos allows the possibility of interactions between 642 cryptosystems of varying strengths; this document adds interactions 643 with public-key cryptosystems to Kerberos. Some administrative 644 policies may allow the use of relatively weak public keys. Using 645 such keys to wrap data encrypted under stronger conventional 646 cryptosystems may be inappropriate. 648 PKINIT requires keys for symmetric cryptosystems to be generated. 649 Some such systems contain "weak" keys. For recommendations regarding 650 these weak keys, see CLARIFICATIONS. 652 PKINIT allows the use of a zero nonce in the PKAuthenticator when 653 cached Diffie-Hellman keys are used. In this case, message binding 654 is performed using the nonce in the main request in the same way as 655 it is done for ordinary AS-REQs (without the PKINIT 656 pre-authenticator). The nonce field in the KDC request body is 657 signed through the checksum in the PKAuthenticator, which 658 cryptographically binds the PKINIT pre-authenticator to the main 659 body of the AS Request and also provides message integrity for the 660 full AS Request. 662 However, when a PKINIT pre-authenticator in the AS-REP has a 663 zero-nonce, and an attacker has somehow recorded this 664 pre-authenticator and discovered the corresponding Diffie-Hellman 665 private key (e.g., with a brute-force attack), the attacker will be 666 able to fabricate his own AS-REP messages that impersonate the KDC 667 with this same pre-authenticator. This compromised pre-authenticator 668 will remain valid as long as its expiration time has not been reached 669 and it is therefore important for clients to check this expiration 670 time and for the expiration time to be reasonably short, which 671 depends on the size of the Diffie-Hellman group. 673 If a client also caches its Diffie-Hellman keys, then the session key 674 could remain the same during multiple AS-REQ/AS-REP exchanges and an 675 attacker which compromised the session key could fabricate his own 676 AS-REP messages with a pre-recorded pre-authenticator until the 677 client starts using a new Diffie-Hellman key pair and while the KDC 678 pre-authenticator has not yet expired. It is therefore not 679 recommended for KDC clients to also cache their Diffie-Hellman keys. 681 Care should be taken in how certificates are chosen for the purposes 682 of authentication using PKINIT. Some local policies may require 683 that key escrow be used for certain certificate types. Deployers of 684 PKINIT should be aware of the implications of using certificates that 685 have escrowed keys for the purposes of authentication. 687 PKINIT does not provide for a "return routability" test to prevent 688 attackers from mounting a denial-of-service attack on the KDC by 689 causing it to perform unnecessary and expensive public-key 690 operations. Strictly speaking, this is also true of standard 691 Kerberos, although the potential cost is not as great, because 692 standard Kerberos does not make use of public-key cryptography. 694 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 695 permit empty SEQUENCEs to be encoded. Such empty sequences may only 696 be used if the KDC itself vouches for the user's certificate. [This 697 seems to reflect the consensus of the Kerberos working group.] 699 5. Acknowledgements 701 Some of the ideas on which this document is based arose during 702 discussions over several years between members of the SAAG, the IETF 703 CAT working group, and the PSRG, regarding integration of Kerberos 704 and SPX. Some ideas have also been drawn from the DASS system. 705 These changes are by no means endorsed by these groups. This is an 706 attempt to revive some of the goals of those groups, and this 707 document approaches those goals primarily from the Kerberos 708 perspective. Lastly, comments from groups working on similar ideas 709 in DCE have been invaluable. 711 6. Expiration Date 713 This draft expires January 25, 2004. 715 7. Bibliography 717 [1] RFC-Editor: To be replaced by RFC number for 718 draft-ietf-krb-wg-kerberos-clarifications. 720 [2] R. Housley. Cryptographic Message Syntax., April 1999. 721 Request For Comments 2630. 723 [3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 724 for the Internet X.509 Public Key Infrastructure Certificate and 725 Certificate Revocation List (CRL) Profile, April 2002. Request For 726 Comments 3279. 728 [4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public 729 Key Infrastructure Certificate and Certificate Revocation List 730 (CRL) Profile, April 2002. Request for Comments 3280. 732 [5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 733 Specifications, October 1998. Request for Comments 2437. 735 [6] RFC-Editor: To be replaced by RFC number for 736 draft-ietf-krb-wg-crypto. 738 [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and 739 T. Wright. Transport Layer Security (TLS) Extensions, June 2003. 740 Request for Comments 3546. 742 [8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 743 Internet X.509 Public Key Infrastructure: Online Certificate Status 744 Protocol - OCSP, June 1999. Request for Comments 2560. 746 [9] NIST, Guidelines for Implementing and Using the NBS Encryption 747 Standard, April 1981. FIPS PUB 74. 749 [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), 750 November 1998. Request for Comments 2409. 752 8. Authors 754 Brian Tung 755 Clifford Neuman 756 USC Information Sciences Institute 757 4676 Admiralty Way Suite 1001 758 Marina del Rey CA 90292-6695 759 Phone: +1 310 822 1511 760 E-mail: {brian,bcn}@isi.edu 762 Matthew Hur 763 Ari Medvinsky 764 Microsoft Corporation 765 One Microsoft Way 766 Redmond WA 98052 767 Phone: +1 425 707 3336 768 E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 770 Sasha Medvinsky 771 Motorola, Inc. 772 6450 Sequence Drive 773 San Diego, CA 92121 774 +1 858 404 2367 775 E-mail: smedvinsky@motorola.com 777 John Wray 778 Iris Associates, Inc. 779 5 Technology Park Dr. 780 Westford, MA 01886 781 E-mail: John_Wray@iris.com 783 Jonathan Trostle 784 E-mail: jtrostle@world.std.com 786 Appendix A. PKINIT ASN.1 Module 788 KerberosV5-PK-INIT-SPEC { 789 iso(1) identified-organization(3) dod(6) internet(1) 790 security(5) kerberosV5(2) modules(4) pkinit(TBD) 791 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 793 IMPORTS 794 SubjectPublicKeyInfo, AlgorithmIdentifier, Name 795 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 796 dod (6) internet (1) security (5) mechanisms (5) 797 pkix (7) id-mod (0) id-pkix1-explicit (18) } 799 ContentInfo, IssuerAndSerialNumber 800 FROM CryptographicMessageSyntax { iso(1) member-body(2) 801 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 802 modules(0) cms(1) } 804 KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey 805 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 806 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 807 krb5spec2(2) } ; 809 id-pkinit OBJECT IDENTIFIER ::= 810 { iso (1) org (3) dod (6) internet (1) security (5) 811 kerberosv5 (2) pkinit (3) } 813 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } 814 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 815 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 816 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 817 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 819 pa-pk-as-req INTEGER ::= TBD 820 pa-pk-as-rep INTEGER ::= TBD 821 pa-pk-ocsp-req INTEGER ::= TBD 822 pa-pk-ocsp-rep INTEGER ::= TBD 824 ad-initial-verified-cas INTEGER ::= TBD 826 td-dh-parameters INTEGER ::= TBD 827 td-trusted-certifiers INTEGER ::= 104 828 td-certificate-index INTEGER ::= 105 830 PA-PK-AS-REQ ::= SEQUENCE { 831 signedAuthPack [0] ContentInfo, 832 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 833 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 834 ... 835 } 837 TrustedCA ::= CHOICE { 838 caName [0] Name, 839 issuerAndSerial [2] IssuerAndSerialNumber, 840 ... 841 } 843 AuthPack ::= SEQUENCE { 844 pkAuthenticator [0] PKAuthenticator, 845 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 846 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 847 OPTIONAL, 848 ... 849 } 851 PKAuthenticator ::= SEQUENCE { 852 cusec [0] INTEGER, 853 ctime [1] KerberosTime, 854 nonce [2] INTEGER (0..4294967295), 855 paChecksum [3] Checksum, 856 ... 857 } 859 TrustedCertifiers ::= SEQUENCE OF Name 861 CertificateIndex ::= IssuerAndSerialNumber 863 KRB5PrincipalName ::= SEQUENCE { 864 realm [0] Realm, 865 principalName [1] PrincipalName 866 } 868 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 869 ca [0] Name, 870 validated [1] BOOLEAN, 871 ... 872 } 874 PA-PK-AS-REP ::= CHOICE { 875 dhSignedData [0] ContentInfo, 876 encKeyPack [1] ContentInfo, 877 ... 878 } 880 KDCDHKeyInfo ::= SEQUENCE { 881 subjectPublicKey [0] BIT STRING, 882 nonce [1] INTEGER, 883 dhKeyExpiration [2] KerberosTime OPTIONAL, 884 ... 885 } 887 ReplyKeyPack ::= SEQUENCE { 888 replyKey [0] EncryptionKey, 889 nonce [1] INTEGER (0..4294967295), 890 ... 891 } 893 END 895 Copyright (C) The Internet Society (2004). This document is subject 896 to the rights, licenses and restrictions contained in BCP 78, and 897 except as set forth therein, the authors retain all their rights. 899 This document and the information contained herein are provided on an 900 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 901 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 902 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 903 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 904 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 905 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.