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