idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-19.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-24) 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. ** 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 1055 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 4 instances of too long lines in the document, the longest one being 2 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 126: '... implementations MUST support the foll...' RFC 2119 keyword, line 237: '... trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL,...' RFC 2119 keyword, line 241: '... kdcCert [2] IssuerAndSerialNumber OPTIONAL,...' RFC 2119 keyword, line 246: '... encryptionCert [3] IssuerAndSerialNumber OPTIONAL,...' RFC 2119 keyword, line 266: '... clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,...' (42 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 798 looks like a reference -- Missing reference section? '2' on line 801 looks like a reference -- Missing reference section? '9' on line 827 looks like a reference -- Missing reference section? '8' on line 823 looks like a reference -- Missing reference section? '12' on line 197 looks like a reference -- Missing reference section? '5' on line 813 looks like a reference -- Missing reference section? '0' on line 691 looks like a reference -- Missing reference section? '3' on line 804 looks like a reference -- Missing reference section? '4' on line 809 looks like a reference -- Missing reference section? '10' on line 830 looks like a reference -- Missing reference section? '6' on line 816 looks like a reference -- Missing reference section? '7' on line 819 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 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-19.txt Clifford Neuman 3 Updates: RFC 1510bis USC/ISI 4 expires September 30, 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-19.txt and expires September 30, 36 2004. Please send comments to the authors. 38 1. Abstract 40 This document 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 digital 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 document, 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 client need 60 explicitly request a ticket and expose his credentials only once. The 61 TGT and its associated session key can then be used for any 62 subsequent requests. One result 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. One cost of using 70 symmetric-key cryptography is that the keys must be shared, so that 71 before a client can authenticate itself, he must already be 72 registered with the KDC. 74 Conversely, public-key cryptography (in conjunction with an 75 established Public Key Infrastructure) permits authentication 76 without prior registration with a KDC. Adding it to Kerberos allows the 77 widespread use of Kerberized applications by clients without requiring 78 them to register first with a KDC: a requirement that has no inherent 79 security benefit. 81 As noted above, a convenient and efficient place to introduce 82 public-key cryptography into Kerberos is in the initial 83 authentication exchange. This document describes the methods and 84 data formats for integrating public-key cryptography into Kerberos 85 initial authentication. 87 3. Extensions 89 This section describes extensions to RFC 1510bis for supporting the 90 use of public-key cryptography in the initial request for a ticket. 92 Briefly, this document defines the following extensions to RFC 1510bis: 94 1. The client indicates the use of public-key authentication by 95 including a special preauthenticator in the initial request. 96 This preauthenticator contains the client's public-key data 97 and a signature. 99 2. 2. The KDC tests the client's request against its policy and 100 trusted Certification Authorities (CAs). 102 3. If the request passes the verification tests, the KDC 103 replies as usual, but the reply is encrypted using either: 105 a. a symmetric encryption key, signed using the KDC?s 106 signature key and encrypted using the client?s encryption 107 key; or 109 b. a key generated through a Diffie-Hellman exchange with 110 the client, signed using the KDC's signature key. 112 Any keying material required by the client to obtain the 113 Encryption key is returned in a preauthentication field in 114 the usual reply. 116 4. The client obtains the encryption key, decrypts the reply, 117 and then proceeds as usual. 119 Section 3.1 of this document defines the necessary message formats. 120 Section 3.2 describes their syntax and use in greater detail. 122 3.1. Definitions 124 3.1.1. Required Algorithms 126 All PKINIT implementations MUST support the following algorithms: 128 - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype; 130 - Signature algorithm: SHA-1 digest and RSA; 132 - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman 133 with a non-zero nonce; 135 - Unkeyed checksum type for the paChecksum member of 136 PKAuthenticator: SHA1 (unkeyed). 138 3.1.2. Defined Message and Encryption Types 140 PKINIT makes use of the following new preauthentication types: 142 PA-PK-AS-REQ TBD 143 PA-PK-AS-REP TBD 144 PA-PK-OCSP-REQ TBD 145 PA-PK-OCSP-REP TBD 147 PKINIT also makes use of the following new authorization data type: 149 AD-INITIAL-VERIFIED-CAS TBD 151 PKINIT introduces the following new error codes: 153 KDC_ERR_CLIENT_NOT_TRUSTED 62 154 KDC_ERR_KDC_NOT_TRUSTED 63 155 KDC_ERR_INVALID_SIG 64 156 KDC_ERR_KEY_SIZE 65 157 KDC_ERR_CERTIFICATE_MISMATCH 66 158 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 159 KDC_ERR_INVALID_CERTIFICATE 71 160 KDC_ERR_REVOKED_CERTIFICATE 72 161 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 162 KDC_ERR_CLIENT_NAME_MISMATCH 75 164 PKINIT uses the following typed data types for errors: 166 TD-DH-PARAMETERS TBD 167 TD-TRUSTED-CERTIFIERS 104 168 TD-CERTIFICATE-INDEX 105 170 PKINIT defines the following encryption types, for use in the AS-REQ 171 message (to indicate acceptance of the corresponding encryption OIDs 172 in PKINIT): 174 dsaWithSHA1-CmsOID 9 175 md5WithRSAEncryption-CmsOID 10 176 sha1WithRSAEncryption-CmsOID 11 177 rc2CBC-EnvOID 12 178 rsaEncryption-EnvOID (PKCS1 v1.5) 13 179 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 180 des-ede3-cbc-EnvOID 15 182 The above encryption types are used by the client only within the 183 KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their 184 use within Kerberos EncryptedData structures is not specified by this 185 document. 187 3.1.3. Algorithm Identifiers 189 PKINIT does not define, but does make use of, the following 190 algorithm identifiers. 192 PKINIT uses the following algorithm identifier for Diffie-Hellman 193 key agreement [9]: 195 dhpublicnumber 197 PKINIT uses the following signature algorithm identifiers [8, 12]: 199 sha-1WithRSAEncryption (RSA with SHA1) 200 md5WithRSAEncryption (RSA with MD5) 201 id-dsa-with-sha1 (DSA with SHA1) 203 PKINIT uses the following encryption algorithm identifiers [5] for 204 encrypting the temporary key with a public key: 206 rsaEncryption (PKCS1 v1.5) 207 id-RSAES-OAEP (PKCS1 v2.0) 209 PKINIT uses the following algorithm identifiers [2] for encrypting 210 the reply key with the temporary key: 212 des-ede3-cbc (three-key 3DES, CBC mode) 213 rc2-cbc (RC2, CBC mode) 215 Kerberos data structures require the use of integer etypes, while CMS 216 objects use OIDs. Therefore, each cryptographic algorithm supported 217 by PKINIT is identified both by a CMS OID and by an equivalent 218 Kerberos etype (defined in section 3.1.2). 220 3.2. PKINIT Preauthentication Syntax and Use 222 This section defines the syntax and use of the various 223 preauthentication fields employed by PKINIT. 225 3.2.1. Client Request 227 The initial authentication request (AS-REQ) is sent as per RFC 228 1510bis; the preauthentication field contains data signed by the 229 client's private signature key as follows: 231 PA-PK-AS-REQ ::= SEQUENCE { 232 signedAuthPack [0] ContentInfo, 233 -- Defined in CMS [2]. 234 -- Type is SignedData. 235 -- Content is AuthPack 236 -- (defined below). 237 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 238 -- A list of CAs, trusted by 239 -- the client, used to certify 240 -- KDCs. 241 kdcCert [2] IssuerAndSerialNumber OPTIONAL, 242 -- Defined in CMS [2]. 243 -- Identifies a particular KDC 244 -- certificate, if the client 245 -- already has it. 246 encryptionCert [3] IssuerAndSerialNumber OPTIONAL, 247 -- May identify the client's 248 -- Diffie-Hellman certificate, 249 -- or an RSA encryption key 250 -- certificate. 251 ... 252 } 254 TrustedCA ::= CHOICE { 255 caName [0] Name, 256 -- Fully qualified X.500 name 257 -- as defined in RFC 3280 [4]. 258 issuerAndSerial [1] IssuerAndSerialNumber, 259 -- Identifies a specific CA 260 -- certificate. 261 ... 262 } 264 AuthPack ::= SEQUENCE { 265 pkAuthenticator [0] PKAuthenticator, 266 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 267 -- Defined in RFC 3280 [4]. 268 -- Present only if the client 269 -- is using ephemeral-ephemeral 270 -- Diffie-Hellman. 271 ... 272 } 274 PKAuthenticator ::= SEQUENCE { 275 cusec [0] INTEGER, 276 ctime [1] KerberosTime, 277 -- cusec and ctime are used as 278 -- in RFC 1510bis, for replay 279 -- prevention. 280 nonce [2] INTEGER, 281 -- Binds reply to request, 282 -- MUST be zero when client 283 -- will accept cached 284 -- Diffie-Hellman parameters 285 -- from KDC. MUST NOT be 286 -- zero otherwise. 287 -- MUST be 0 <= nonce < 2^32. 288 paChecksum [3] Checksum, 289 -- Defined in RFC 1510bis [1]. 290 -- Performed over KDC-REQ-BODY, 291 -- MUST be unkeyed. 292 ... 293 } 295 IMPORTS 296 -- from RFC 3280 [4] 297 SubjectPublicKeyInfo, AlgorithmIdentifier, Name 298 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 299 dod (6) internet (1) security (5) mechanisms (5) 300 pkix (7) id-mod (0) id-pkix1-explicit (18) } 302 IMPORTS 303 -- from RFC 2630 [2] 304 ContentInfo, IssuerAndSerialNumber 305 FROM CryptographicMessageSyntax { iso(1) member-body(2) 306 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 307 modules(0) cms(1) } 309 IMPORTS 310 -- from RFC 1510bis [1] 311 KerberosTime, Checksum 312 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 313 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 314 krb5spec2(2) } 316 The ContentInfo in the signedAuthPack is filled out as follows: 318 1. The eContent field contains data of type AuthPack. It MUST 319 contain the pkAuthenticator, and MAY also contain the 320 client's Diffie-Hellman public value (clientPublicValue). 322 2. The eContentType field MUST contain the OID value for 323 pkauthdata: { iso (1) org (3) dod (6) internet (1) 324 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)} 326 3. The signerInfos field MUST contain the signature over the 327 AuthPack. 329 4. The certificates field MUST contain at least a signature 330 verification certificate chain that the KDC can use to 331 verify the signature over the AuthPack. Additionally, the 332 client MAY insert an encryption certificate chain, if 333 (for example) the client is not using ephemeral-ephemeral 334 Diffie-Hellman. 336 5. If a Diffie-Hellman key is being used, the parameters SHOULD 337 be chosen from the First or Second defined Oakley Groups. 338 (See RFC 2409 [10].) 340 6. The KDC may wish to use cached Diffie-Hellman parameters. 341 To indicate acceptance of caching, the client sends zero in 342 the nonce field of the pkAuthenticator. Zero is not a valid 343 value for this field under any other circumstances. Since 344 zero is used to indicate acceptance of cached parameters, 345 message binding in this case is performed using only the 346 nonce in the main request. 348 3.2.2. Validation of Client Request 350 Upon receiving the client's request, the KDC validates it. This 351 section describes the steps that the KDC MUST (unless otherwise 352 noted) take in validating the request. 354 The KDC must look for a client certificate in the signedAuthPack. 355 If it cannot find one signed by a CA it trusts, it sends back an 356 error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying 357 e-data for this error is a SEQUENCE OF TYPED-DATA: 359 TYPED-DATA ::= SEQUENCE { 360 -- As defined in RFC 1510bis. 361 data-type [0] INTEGER, 362 data-value [1] OCTET STRING 363 } 365 IMPORTS 366 -- from RFC 1510bis [1] 367 TYPED-DATA, Checksum 368 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 369 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 370 krb5spec2(2) } 372 For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the 373 data-value is an OCTET STRING containing the DER encoding of 375 TrustedCertifiers ::= SEQUENCE OF Name 377 If, while verifying the certificate chain, the KDC determines that 378 the signature on one of the certificates in the signedAuthPack is 379 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 380 The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA, 381 whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an 382 OCTET STRING containing the DER encoding of the index into the 383 CertificateSet field, ordered as sent by the client: 385 CertificateIndex ::= IssuerAndSerialNumber 386 -- IssuerAndSerialNumber of 387 -- certificate with invalid signature 389 If more than one certificate signature is invalid, the KDC MAY send one 390 TYPED-DATA per invalid signature. 392 The KDC MAY also check whether any of the certificates in the client's 393 chain have been revoked. If any of them have been revoked, the KDC 394 MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 395 attempts to determine the revocation status but is unable to do so, 396 it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 397 The certificate or certificates affected are identified exactly as 398 for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 400 In addition to validating the certificate chain, the KDC MUST also 401 check that the certificate properly maps to the client's principal name 402 as specified in the AS-REQ as follows: 404 1. If the KDC has its own mapping from the name in the 405 certificate to a Kerberos name, it uses that Kerberos 406 name. 408 2. Otherwise, if the certificate contains a SubjectAltName 409 extension with a Kerberos name in the otherName field, 410 it uses that name. The otherName field (of type AnotherName) in 411 the SubjectAltName extension MUST contain the following: 413 The type-id is: 415 krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) 416 internet (1) security (5) kerberosv5 (2) 2 } 418 The value is: 420 KRB5PrincipalName ::= SEQUENCE { 421 realm [0] Realm, 422 principalName [1] PrincipalName 423 } 425 IMPORTS 426 -- from RFC 3280 [4] 427 GeneralName 428 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 429 dod (6) internet (1) security (5) mechanisms (5) 430 pkix (7) id-mod (0) id-pkix1-explicit (18) } 432 IMPORTS 433 -- from RFC 1510bis [1] 434 PrincipalName, Realm 435 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 436 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 437 krb5spec2(2) } 439 If the KDC does not have its own mapping and there is no Kerberos 440 name present in the certificate, or if the name in the request does 441 not match the name in the certificate (including the realm name), or 442 if there is no name in the request, the KDC MUST return error code 443 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 444 for this error. If the name in the request is [special "blank" 445 name], the KDC MAY insert a different name in the reply. 447 Even if the chain is validated, and the names in the certificate and 448 the request match, the KDC may decide not to trust the client. For 449 example, the certificate may include an Enxtended Key Usage (EKU) OID 450 in the extensions field. As a matter of local policy, the KDC may 451 decide to reject requests on the basis of the absence or presence of 452 specific EKU OIDs. In this case, the KDC MUST return error code 453 KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: 455 { iso (1) org (3) dod (6) internet (1) security (5) 456 kerberosv5 (2) pkinit (3) pkekuoid (4) } 458 If the client's signature on the signedAuthPack fails to verify, the KDC 459 MUST return error KDC_ERR_INVALID_SIG. There is no accompanying 460 e-data for this error. 462 The KDC MUST check the timestamp to ensure that the request is not 463 a replay, and that the time skew falls within acceptable limits. 464 The recommendations clock skew times in RFC 1510bis [1] apply here. 465 If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 466 or KRB_AP_ERR_SKEW, respectively. 468 If the clientPublicValue is filled in, indicating that the 469 client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC 470 checks to see if the parameters satisfy its policy. If they do not, 471 it MUST return error code KDC_ERR_KEY_SIZE. The accompanying e-data is 472 a SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose 473 data-value is an OCTET STRING containing the DER encoding of a 474 DomainParameters (see [3]), including appropriate Diffie-Hellman 475 parameters with which to retry the request. 477 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 478 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not 479 have the corresponding certificate. 481 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did 482 not include a kdcCert field, but did include a trustedCertifiers field, 483 and the KDC does not possesses a certificate issued by one of the listed 484 certifiers. 486 3.2.3. KDC Reply 488 Assuming that the client's request has been properly validated, the 489 KDC proceeds as per RFC 1510bis, except as follows. 491 The KDC MUST set the initial flag and include an authorization data of 492 type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is an 493 OCTET STRING containing the DER encoding of InitialVerifiedCAs: 495 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 496 ca [0] Name, 497 Validated [1] BOOLEAN, 498 ... 499 } 501 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 502 containers if the list of CAs satisfies the KDC's realm's policy. 503 (This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 504 Furthermore, any TGS must copy such authorization data from tickets 505 used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 506 including the AD-IF-RELEVANT container, if present. 508 AP servers that understand this authorization data type SHOULD apply 509 local policy to determine whether a given ticket bearing such a type 510 (not contained within an AD-IF-RELEVANT container) is acceptable. 511 (This corresponds to the AP server checking the transited field when 512 the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data 513 type is contained within an AD-IF-RELEVANT container, AP servers 514 MAY apply local policy to determine whether the authorization 515 data is acceptable. 517 The AS-REP is otherwise unchanged from RFC 1510bis. The KDC encrypts 518 the reply as usual, but not with the client's long-term key. 519 Instead, it encrypts it with either a generated encryption key, or a 520 key derived from a Diffie-Hellman exchange. The contents of the 521 PA-PK-AS-REP indicate the type of encryption key that was used: 523 PA-PK-AS-REP ::= CHOICE { 524 dhSignedData [0] ContentInfo, 525 -- Type is SignedData. 526 -- Content is KDCDHKeyInfo 527 -- (defined below). 528 encKeyPack [1] ContentInfo, 529 -- Type is SignedData. 530 -- Content is ReplyKeyPack 531 -- (defined below). 532 ... 533 } 535 KDCDHKeyInfo ::= SEQUENCE { 536 subjectPublicKey [0] BIT STRING, 537 -- Equals public exponent 538 -- (g^a mod p). 539 -- INTEGER encoded as payload 540 -- of BIT STRING. 541 nonce [1] INTEGER, 542 -- Binds reply to request. 543 -- Exception: A value of zero 544 -- indicates that the KDC is 545 -- using cached values. 546 dhKeyExpiration [2] KerberosTime OPTIONAL, 547 -- Expiration time for KDC's 548 -- cached values. 549 ... 550 } 552 The fields of the ContentInfo for dhSignedData are to be filled in 553 as follows: 555 1. The eContent field contains data of type KDCDHKeyInfo. 557 2. The eContentType field contains the OID value for 558 pkdhkeydata: { iso (1) org (3) dod (6) internet (1) 559 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) } 561 3. The signerInfos field contains a single signerInfo, which is 562 the signature of the KDCDHKeyInfo. 564 4. The certificates field contains a signature verification 565 certificate chain that the client will use to verify the 566 KDC's signature over the KDCDHKeyInfo. This field may only 567 be left empty if the client did include a kdcCert field in 568 the PA-PK-AS-REQ, indicating that it has the KDC's certificate. 570 5. If the client and KDC agree to use cached parameters, the 571 KDC MUST return a zero in the nonce field and include the 572 expiration time of the cached values in the dhKeyExpiration 573 field. If this time is exceeded, the client MUST NOT use 574 the reply. If the time is absent, the client MUST NOT use 575 the reply and MAY resubmit a request with a non-zero nonce, 576 thus indicating non-acceptance of the cached parameters. 578 The key is derived as follows: Both the KDC and the client calculate 579 the value g^(ab) mod p, where a and b are the client's and KDC's 580 private exponents, respectively. They both take the first k bits of 581 this secret value as a key generation seed, where the parameter k 582 (the size of the seed) is dependent on the selected key type, as 583 specified in [6]. The seed is then converted into a protocol key by 584 applying to it a random-to-key function, which is also dependent on 585 key type. 587 1. For example, if the encryption type is DES with MD4, k = 64 588 bits and the random-to-key function consists of replacing 589 some of the bits with parity bits, according to FIPS PUB 74 590 [9]. 592 2. If the encryption type is three-key 3DES with HMAC-SHA1, 593 k = 168 bits and the random-to-key function is 594 DES3random-to-key as defined in [6]. This function inserts 595 parity bits to create a 192-bit 3DES protocol key that is 596 compliant with FIPS PUB 74 [9]. This key is used to 597 generate additional keys Ke and Ki, for encryption and 598 integrity protection, respectively, using the key usage 599 value of 3, as per [6] for the handling of the encrypted 600 part of the AS-REP. 602 If the KDC and client are not using Diffie-Hellman, the KDC encrypts 603 the reply with an encryption key, packed in the encKeyPack, which 604 contains data of type ReplyKeyPack: 606 ReplyKeyPack ::= SEQUENCE { 607 replyKey [0] EncryptionKey, 608 -- Defined in RFC 1510bis. 609 -- Used to encrypt main reply. 610 -- MUST be at least as strong 611 -- as session key. (Using the 612 -- same enctype and a strong 613 -- prng should suffice, if no 614 -- stronger encryption system 615 -- is available.) 616 nonce [1] INTEGER, 617 -- Binds reply to request. 618 -- MUST be 0 < nonce < 2^32. 619 ... 620 } 622 IMPORTS 623 -- from RFC 1510bis [1] 624 EncryptionKey 625 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 626 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 627 krb5spec2(2) } 629 The fields of the ContentInfo for encKeyPack MUST be filled in as 630 follows: 632 1. The content is of type SignedData. The eContent for 633 the SignedData is of type ReplyKeyPack. 635 2. The eContentType for the SignedData contains the OID value for 636 pkrkeydata: { iso (1) org (3) dod (6) internet (1) 637 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) } 639 3. The signerInfos field contains a single signerInfo, which is 640 the signature of the ReplyKeyPack. 642 4. The certificates field contains a signature verification 643 certificate chain that the client will use to verify the 644 KDC's signature over the ReplyKeyPack. This field may only 645 be left empty if the client did include a kdcCert field in 646 the PA-PK-AS-REQ, indicating that it has the KDC's certificate. 648 5. The encryptedContentType for the EnvelopedData contains the OID 649 value for id-signedData: { iso (1) member-body (2) us (840) 650 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } 652 6. The recipientInfos field is a SET which MUST contain exactly 653 one member of type KeyTransRecipientInfo. The encryptedKey 654 for this member contains the temporary key which is 655 encrypted using the client's public key. 657 7. The unprotectedAttrs or originatorInfo fields MAY be present. 659 3.2.4. Validation of KDC Reply 661 Upon receipt of the KDC's reply, the client proceeds as follows. If 662 the PA-PK-AS-REP contains a dhSignedData, the client obtains and 663 verifies the Diffie-Hellman parameters, and obtains the shared key 664 as described above. Otherwise, the message contains an encKeyPack, 665 and the client decrypts and verifies the temporary encryption key. 666 In either case, the client then decrypts the main reply with the 667 resulting key, and then proceeds as described in RFC 1510bis. 669 3.2.5. Support for OCSP 671 OCSP (Online Certificate Status Protocol) [8] allows the use of 672 on-line requests for a client or server to determine the validity of 673 each other's certificates. It is particularly useful for clients 674 authenticating each other across a constrained network. These 675 clients will not have to download the entire CRL to check for the 676 validity of the KDC's certificate. 678 In these cases, the KDC generally has better connectivity to the 679 OCSP server, and it therefore processes the OCSP request and 680 response and sends the results to the client. The mechanism defined 681 in this section allow a client to request an OCSP response from the 682 KDC when using PKINIT. This is similar to the way that OCSP is 683 handled in [7]. 685 OCSP support is provided in PKINIT through the use of additional 686 preauthentication data. The following new preauthentication types 687 are defined: 689 PA-PK-OCSP-REQ ::= SEQUENCE { 690 -- PAType TBD 691 responderIDList [0] SEQUENCE of ResponderID OPTIONAL, 692 -- ResponderID is a DER-encoded 693 -- ASN.1 type defined in [8] 694 requestExtensions [1] Extensions OPTIONAL 695 -- Extensions is a DER-encoded 696 -- ASN.1 type defined in [8] 697 } 699 PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse 700 -- OCSPResponse is a DER-encoded 701 -- ASN.1 type defined in [8] 703 A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP. 704 KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a 705 PA-PK-OCSP-REQ from the client. The KDC MAY either send a cached 706 OCSP response or send an on-line request to the OCSP server. 708 In the case that a responderIDList is not sent or is empty, the OCSP 709 response must be signed by the authority that issued the 710 certificate, unless specified otherwise by a mutually agreed policy 711 between the client and the KDC. 713 When using OCSP, the response is signed by the OCSP server, which is 714 trusted by the client. Depending on local policy, further 715 verification of the validity of the OCSP server may need to be done. 717 4. Security Considerations 719 PKINIT raises certain security considerations beyond those that can 720 be regulated strictly in protocol definitions. We will address them 721 in this section. 723 PKINIT extends the cross-realm model to the public-key 724 infrastructure. Users of PKINIT must understand security policies 725 and procedures appropriate to the use of Public Key Infrastructures. 727 Standard Kerberos allows the possibility of interactions between 728 cryptosystems of varying strengths; this document adds interactions 729 with public-key cryptosystems to Kerberos. Some administrative 730 policies may allow the use of relatively weak public keys. Using 731 such keys to wrap data encrypted under stronger conventional 732 cryptosystems may be inappropriate. 734 PKINIT requires keys for symmetric cryptosystems to be generated. 735 Some such systems contain "weak" keys. For recommendations regarding 736 these weak keys, see RFC 1510bis. 738 PKINIT allows the use of a zero nonce in the PKAuthenticator when 739 cached Diffie-Hellman keys are used. In this case, message binding 740 is performed using the nonce in the main request in the same way as 741 it is done for ordinary AS-REQs (without the PKINIT 742 pre-authenticator). The nonce field in the KDC request body is 743 signed through the checksum in the PKAuthenticator, which 744 cryptographically binds the PKINIT pre-authenticator to the main body 745 of the AS Request and also provides message integrity for the full 746 AS Request. 748 However, when a PKINIT pre-authenticator in the AS-REP has a 749 zero-nonce, and an attacker has somehow recorded this 750 pre-authenticator and discovered the corresponding Diffie-Hellman 751 private key (e.g., with a brute-force attack), the attacker will be 752 able to fabricate his own AS-REP messages that impersonate the KDC 753 with this same pre-authenticator. This compromised pre-authenticator 754 will remain valid as long as its expiration time has not been reached 755 and it is therefore important for clients to check this expiration 756 time and for the expiration time to be reasonably short, which 757 depends on the size of the Diffie-Hellman group. 759 If a client also caches its Diffie-Hellman keys, then the session key 760 could remain the same during multiple AS-REQ/AS-REP exchanges and an 761 attacker which compromised the session key could fabricate his own 762 AS-REP messages with a pre-recorded pre-authenticator until the 763 client starts using a new Diffie-Hellman key pair and while the KDC 764 pre-authenticator has not yet expired. It is therefore not 765 recommended for KDC clients to also cache their Diffie-Hellman keys. 767 Care should be taken in how certificates are chosen for the purposes 768 of authentication using PKINIT. Some local policies may require 769 that key escrow be used for certain certificate types. Deployers of 770 PKINIT should be aware of the implications of using certificates that 771 have escrowed keys for the purposes of authentication. 773 PKINIT does not provide for a "return routability" test to prevent 774 attackers from mounting a denial-of-service attack on the KDC by 775 causing it to perform unnecessary and expensive public-key 776 operations. Strictly speaking, this is also true of standard 777 Kerberos, although the potential cost is not as great, because 778 standard Kerberos does not make use of public-key cryptography. 780 5. Acknowledgements 782 Some of the ideas on which this document is based arose during 783 discussions over several years between members of the SAAG, the IETF 784 CAT working group, and the PSRG, regarding integration of Kerberos 785 and SPX. Some ideas have also been drawn from the DASS system. 786 These changes are by no means endorsed by these groups. This is an 787 attempt to revive some of the goals of those groups, and this 788 document approaches those goals primarily from the Kerberos 789 perspective. Lastly, comments from groups working on similar ideas 790 in DCE have been invaluable. 792 6. Expiration Date 794 This draft expires September 30, 2004. 796 7. Bibliography 798 [1] RFC-Editor: To be replaced by RFC number for 799 draft-ietf-krb-wg-kerberos-clarifications. 801 [2] R. Housley. Cryptographic Message Syntax., April 1999. 802 Request For Comments 2630. 804 [3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 805 for the Internet X.509 Public Key Infrastructure Certificate and 806 Certificate Revocation List (CRL) Profile, April 2002. Request For 807 Comments 3279. 809 [4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public 810 Key Infrastructure Certificate and Certificate Revocation List 811 (CRL) Profile, April 2002. Request for Comments 3280. 813 [5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 814 Specifications, October 1998. Request for Comments 2437. 816 [6] RFC-Editor: To be replaced by RFC number for 817 draft-ietf-krb-wg-crypto. 819 [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and 820 T. Wright. Transport Layer Security (TLS) Extensions, June 2003. 821 Request for Comments 3546. 823 [8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 824 Internet X.509 Public Key Infrastructure: Online Certificate Status 825 Protocol - OCSP, June 1999. Request for Comments 2560. 827 [9] NIST, Guidelines for Implementing and Using the NBS Encryption 828 Standard, April 1981. FIPS PUB 74. 830 [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), 831 November 1998. Request for Comments 2409. 833 8. Authors 835 Brian Tung 836 Clifford Neuman 837 USC Information Sciences Institute 838 4676 Admiralty Way Suite 1001 839 Marina del Rey CA 90292-6695 840 Phone: +1 310 822 1511 841 E-mail: {brian,bcn}@isi.edu 843 Matthew Hur 844 Ari Medvinsky 845 Microsoft Corporation 846 One Microsoft Way 847 Redmond WA 98052 848 Phone: +1 425 707 3336 849 E-mail: matthur@microsoft.com, arimed@windows.microsoft.com 851 Sasha Medvinsky 852 Motorola, Inc. 853 6450 Sequence Drive 854 San Diego, CA 92121 855 +1 858 404 2367 856 E-mail: smedvinsky@motorola.com 858 John Wray 859 Iris Associates, Inc. 860 5 Technology Park Dr. 861 Westford, MA 01886 862 E-mail: John_Wray@iris.com 864 Jonathan Trostle 865 E-mail: jtrostle@world.std.com