idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-22.txt: 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 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1091. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1081. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-cat-kerberos-pk-init', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-cat-kerberos-pk-init', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-cat-kerberos-pk-init', but the file name used is 'draft-ietf-cat-kerberos-pk-init-22' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (December 6, 2004) is 7074 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1042 -- Looks like a reference, but probably isn't: '1' on line 1051 -- Looks like a reference, but probably isn't: '2' on line 1032 -- Looks like a reference, but probably isn't: '3' on line 986 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS74' -- Possible downref: Non-RFC (?) normative reference: ref. 'KCRYPTO' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 2630 (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 10 errors (**), 1 flaw (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP B. Tung 3 Internet-Draft C. Neuman 4 Expires: June 6, 2005 USC Information Sciences Institute 5 L. Zhu 6 M. Hur 7 Microsoft Corporation 8 S. Medvinsky 9 Motorola, Inc. 10 December 6, 2004 12 Public Key Cryptography for Initial Authentication in Kerberos 13 draft-ietf-cat-kerberos-pk-init 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 6, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document describes protocol extensions (hereafter called PKINIT) 49 to the Kerberos protocol specification. These extensions provide a 50 method for integrating public key cryptography into the initial 51 authentication exchange, by passing digital certificates and 52 associated authenticators in preauthentication data fields. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1 Definitions, Requirements, and Constants . . . . . . . . . 5 60 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 5 61 3.1.2 Defined Message and Encryption Types . . . . . . . . . 6 62 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 7 63 3.2 PKINIT Preauthentication Syntax and Use . . . . . . . . . 7 64 3.2.1 Client Request . . . . . . . . . . . . . . . . . . . . 8 65 3.2.2 Validation of Client Request . . . . . . . . . . . . . 10 66 3.2.3 KDC Reply . . . . . . . . . . . . . . . . . . . . . . 12 67 3.2.4 Validation of KDC Reply . . . . . . . . . . . . . . . 17 68 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 17 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 22 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 74 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24 75 Intellectual Property and Copyright Statements . . . . . . . . 28 77 1. Introduction 79 A client typically authenticates itself to a service in Kerberos 80 using three distinct though related exchanges. First, the client 81 requests a ticket-granting ticket (TGT) from the Kerberos 82 authentication server (AS). Then, it uses the TGT to request a 83 service ticket from the Kerberos ticket-granting server (TGS). 84 Usually, the AS and TGS are integrated in a single device known as a 85 Kerberos Key Distribution Center, or KDC. Finally, the client uses 86 the service ticket to authenticate itself to the service. 88 The advantage afforded by the TGT is that the client need explicitly 89 request a ticket and expose his credentials only once. The TGT and 90 its associated session key can then be used for any subsequent 91 requests. One result of this is that all further authentication is 92 independent of the method by which the initial authentication was 93 performed. Consequently, initial authentication provides a 94 convenient place to integrate public-key cryptography into Kerberos 95 authentication. 97 As defined, Kerberos authentication exchanges use symmetric-key 98 cryptography, in part for performance. One cost of using 99 symmetric-key cryptography is that the keys must be shared, so that 100 before a client can authenticate itself, he must already be 101 registered with the KDC. 103 Conversely, public-key cryptography (in conjunction with an 104 established Public Key Infrastructure) permits authentication without 105 prior registration with a KDC. Adding it to Kerberos allows the 106 widespread use of Kerberized applications by clients without 107 requiring them to register first with a KDC--a requirement that has 108 no inherent security benefit. 110 As noted above, a convenient and efficient place to introduce 111 public-key cryptography into Kerberos is in the initial 112 authentication exchange. This document describes the methods and 113 data formats for integrating public-key cryptography into Kerberos 114 initial authentication. 116 2. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 In this document, we will refer to both the AS and the TGS as the 123 KDC. 125 3. Extensions 127 This section describes extensions to [CLAR] for supporting the use of 128 public-key cryptography in the initial request for a ticket. 130 Briefly, this document defines the following extensions to [CLAR]: 132 1. The client indicates the use of public-key authentication by 133 including a special preauthenticator in the initial request. This 134 preauthenticator contains the client's public-key data and a 135 signature. 137 2. The KDC tests the client's request against its policy and trusted 138 Certification Authorities (CAs). 140 3. If the request passes the verification tests, the KDC replies as 141 usual, but the reply is encrypted using either: 143 a. a symmetric encryption key, signed using the KDC's signature 144 key and encrypted using the client's encryption key; or 146 b. a key generated through a Diffie-Hellman exchange with the 147 client, signed using the KDC's signature key. 149 Any keying material required by the client to obtain the 150 Encryption key is returned in a preauthentication field 151 accompanying the usual reply. 153 4. The client obtains the encryption key, decrypts the reply, and 154 then proceeds as usual. 156 Section 3.1 of this document defines the necessary message formats. 157 Section 3.2 describes their syntax and use in greater detail. 159 3.1 Definitions, Requirements, and Constants 161 3.1.1 Required Algorithms 163 All PKINIT implementations MUST support the following algorithms: 165 o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. 167 o Signature algorithm: SHA-1 digest and RSA. 169 o Reply key delivery method: RSA or ephemeral-ephemeral 170 Diffie-Hellman. 172 3.1.2 Defined Message and Encryption Types 174 PKINIT makes use of the following new preauthentication types: 176 PA-PK-AS-REQ 16 177 PA-PK-AS-REP 17 179 PKINIT also makes use of the following new authorization data type: 181 AD-INITIAL-VERIFIED-CAS 9 183 PKINIT introduces the following new error codes: 185 KDC_ERR_CLIENT_NOT_TRUSTED 62 186 KDC_ERR_KDC_NOT_TRUSTED 63 187 KDC_ERR_INVALID_SIG 64 188 KDC_ERR_KEY_SIZE 65 189 KDC_ERR_CERTIFICATE_MISMATCH 66 190 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 191 KDC_ERR_INVALID_CERTIFICATE 71 192 KDC_ERR_REVOKED_CERTIFICATE 72 193 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 194 KDC_ERR_CLIENT_NAME_MISMATCH 75 196 PKINIT uses the following typed data types for errors: 198 TD-TRUSTED-CERTIFIERS 104 199 TD-CERTIFICATE-INDEX 105 200 TD-DH-PARAMETERS 109 202 PKINIT defines the following encryption types, for use in the 203 KRB_AS_REQ message (to indicate acceptance of the corresponding 204 encryption OIDs in PKINIT): 206 dsaWithSHA1-CmsOID 9 207 md5WithRSAEncryption-CmsOID 10 208 sha1WithRSAEncryption-CmsOID 11 209 rc2CBC-EnvOID 12 210 rsaEncryption-EnvOID (PKCS1 v1.5) 13 211 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 212 des-ede3-cbc-EnvOID 15 214 The above encryption types are used by the client only within the 215 KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports. 216 Their use within Kerberos EncryptedData structures is not specified 217 by this document. 219 The ASN.1 module for all structures defined in this document (plus 220 IMPORT statements for all imported structures) are given in Appendix 221 A. 223 All structures defined in this document MUST be encoded using 224 Distinguished Encoding Rules (DER) [X690]. All imported data 225 structures must be encoded according to the rules specified in 226 Kerberos [CLAR] or CMS [RFC2630] as appropriate. 228 Interoperability note: Some implementations may not be able to decode 229 CMS objects encoded with BER but not DER; specifically, they may not 230 be able to decode infinite length encodings. To maximize 231 interoperability, implementers SHOULD encode CMS objects used in 232 PKINIT with DER. 234 3.1.3 Algorithm Identifiers 236 PKINIT does not define, but does make use of, the following algorithm 237 identifiers. 239 PKINIT uses the following algorithm identifier for Diffie-Hellman key 240 agreement [FIPS74]: 242 dhpublicnumber 244 PKINIT uses the following signature algorithm identifiers [RFC3279]: 246 sha-1WithRSAEncryption (RSA with SHA1) 247 md5WithRSAEncryption (RSA with MD5) 248 id-dsa-with-sha1 (DSA with SHA1) 250 PKINIT uses the following encryption algorithm identifiers [RFC2437] 251 for encrypting the temporary key with a public key: 253 rsaEncryption (PKCS1 v1.5) 254 id-RSAES-OAEP (PKCS1 v2.0) 256 PKINIT uses the following algorithm identifiers [RFC2630] for 257 encrypting the reply key with the temporary key: 259 des-ede3-cbc (three-key 3DES, CBC mode) 260 rc2-cbc (RC2, CBC mode) 261 aes256_CBC (AES-256, CBC mode) 263 3.2 PKINIT Preauthentication Syntax and Use 265 This section defines the syntax and use of the various 266 preauthentication fields employed by PKINIT. 268 3.2.1 Client Request 270 The initial authentication request (KRB_AS_REQ) is sent as per 271 [CLAR]; in addition, a preauthentication field contains data signed 272 by the client's private signature key, as follows: 274 WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { 275 -- Contains a BER encoding of ContentInfo. 276 }) 278 WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { 279 -- Contains a BER encoding of IssuerAndSerialNumber. 280 }) 282 PA-PK-AS-REQ ::= SEQUENCE { 283 signedAuthPack [0] IMPLICIT WrapContentInfo, 284 -- Type is SignedData. 285 -- Content is AuthPack 286 -- (defined below). 287 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 288 -- A list of CAs, trusted by 289 -- the client, used to certify 290 -- KDCs. 291 kdcCert [2] IMPLICIT WrapIssuerAndSerial 292 OPTIONAL, 293 -- Identifies a particular KDC 294 -- certificate, if the client 295 -- already has it. 296 clientDHNonce [3] DHNonce OPTIONAL, 297 ... 298 } 300 TrustedCA ::= CHOICE { 301 caName [1] Name, 302 -- Fully qualified X.500 name 303 -- as defined in [RFC3280]. 304 issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, 305 -- Identifies a specific CA 306 -- certificate. 307 ... 308 } 309 AuthPack ::= SEQUENCE { 310 pkAuthenticator [0] PKAuthenticator, 311 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 312 -- Defined in [RFC3280]. 313 -- Present only if the client 314 -- is using ephemeral-ephemeral 315 -- Diffie-Hellman. 316 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 317 OPTIONAL, 318 -- List of CMS encryption types 319 -- supported by client in order 320 -- of (decreasing) preference. 321 ... 322 } 324 PKAuthenticator ::= SEQUENCE { 325 cusec [0] INTEGER (0..999999), 326 ctime [1] KerberosTime, 327 -- cusec and ctime are used as 328 -- in [CLAR], for replay 329 -- prevention. 330 nonce [2] INTEGER (0..4294967295), 331 paChecksum [3] OCTET STRING, 332 -- Contains the SHA1 checksum, 333 -- performed over KDC-REQ-BODY. 334 ... 335 } 337 The ContentInfo in the signedAuthPack is filled out as follows: 339 1. The eContent field contains data of type AuthPack. It MUST 340 contain the pkAuthenticator, and MAY also contain the client's 341 Diffie-Hellman public value (clientPublicValue). 343 2. The eContentType field MUST contain the OID value for 344 id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5) 345 kerberosv5(2) pkinit(3) pkauthdata(1) }. 347 3. The signerInfos field MUST contain the signature over the 348 AuthPack. 350 4. The certificates field MUST contain at least a signature 351 verification certificate chain that the KDC can use to verify the 352 signature over the AuthPack. The certificate chain(s) MUST NOT 353 contain the root CA certificate. 355 5. If a Diffie-Hellman key is being used, the parameters MUST be 356 chosen from Oakley Group 2 or 14. Implementations MUST support 357 Group 2; they are RECOMMENDED to support Group 14 (See 358 [RFC2409]). 360 6. The client may wish to cache DH parameters or to allow the KDC to 361 do so. If so, then the client must include the clientDHNonce 362 field. The nonce string needs to be as long as the longest key 363 length of the symmetric key types that the client supports. The 364 nonce MUST be chosen randomly. 366 3.2.2 Validation of Client Request 368 Upon receiving the client's request, the KDC validates it. This 369 section describes the steps that the KDC MUST (unless otherwise 370 noted) take in validating the request. 372 The KDC must look for a client certificate in the signedAuthPack. If 373 it cannot find one signed by a CA it trusts, it sends back an error 374 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 375 this error is a TYPED-DATA (as defined in [CLAR]). For this error, 376 the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER 377 encoding of 379 TrustedCertifiers ::= SEQUENCE OF Name 381 If, while verifying the certificate chain, the KDC determines that 382 the signature on one of the certificates in the signedAuthPack is 383 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 384 The accompanying e-data for this error is a TYPED-DATA, whose 385 data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER 386 encoding of the index into the CertificateSet field, ordered as sent 387 by the client: 389 CertificateIndex ::= IssuerAndSerialNumber 390 -- IssuerAndSerialNumber of 391 -- certificate with invalid signature. 393 If more than one certificate signature is invalid, the KDC MAY send 394 one TYPED-DATA per invalid signature. 396 The KDC MAY also check whether any certificates in the client's chain 397 have been revoked. If any of them have been revoked, the KDC MUST 398 return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC 399 attempts to determine the revocation status but is unable to do so, 400 it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. 402 The certificate or certificates affected are identified exactly as 403 for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). 405 In addition to validating the certificate chain, the KDC MUST also 406 check that the certificate properly maps to the client's principal 407 name as specified in the KRB_AS_REQ as follows: 409 1. If the KDC has its own mapping from the name in the certificate 410 to a Kerberos name, it uses that Kerberos name. 412 2. Otherwise, if the certificate contains a SubjectAltName extension 413 with a Kerberos name in the otherName field, it uses that name. 415 The otherName field (of type AnotherName) in the SubjectAltName 416 extension MUST contain krb5PrincipalName as defined below. 418 The type-id is: 420 krb5PrincipalName OBJECT IDENTIFIER ::= iso (1) org (3) dod (6) 421 internet (1) security (5) kerberosv5 (2) 2 423 The value is the DER encoding of the following ASN.1 type: 425 KRB5PrincipalName ::= SEQUENCE { 426 realm [0] Realm, 427 principalName [1] PrincipalName 428 } 430 If the KDC does not have its own mapping and there is no Kerberos 431 name present in the certificate, or if the name in the request does 432 not match the name in the certificate (including the realm name), or 433 if there is no name in the request, the KDC MUST return error code 434 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 435 this error. 437 Even if the certificate chain is validated, and the names in the 438 certificate and the request match, the KDC may decide to reject 439 requests on the basis of the absence or presence of specific EKU 440 OIDs. For example, the certificate may include an Extended Key Usage 441 (EKU) OID of id-pkekuoid in the extensions field: 443 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 444 pkinit(3) pkekuoid(4) } 446 The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the 447 client's cerficate is not accepted. 449 If the client's signature on the signedAuthPack fails to verify, the 450 KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying 451 e-data for this error. 453 The KDC MUST check the timestamp to ensure that the request is not a 454 replay, and that the time skew falls within acceptable limits. The 455 recommendations clock skew times in [CLAR] apply here. If the check 456 fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 457 KRB_AP_ERR_SKEW, respectively. 459 If the clientPublicValue is filled in, indicating that the client 460 wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to 461 see if the parameters satisfy its policy. If they do not, it MUST 462 return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a 463 TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose data-value 464 is the DER encoding of a DomainParameters (see [RFC3279]), including 465 appropriate Diffie-Hellman parameters with which to retry the 466 request. 468 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 469 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does 470 not have the corresponding certificate. 472 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client 473 did not include a kdcCert field, but did include a trustedCertifiers 474 field, and the KDC does not possesses a certificate issued by one of 475 the listed certifiers. 477 If there is a supportedCMSTypes field in the AuthPack, the KDC must 478 check to see if it supports any of the listed types. If it supports 479 more than one of the types, the KDC SHOULD use the one listed first. 480 If it does not support any of them, it MUST return an error of type 481 KRB5KDC_ERR_ETYPE_NOSUPP. 483 3.2.3 KDC Reply 485 Assuming that the client's request has been properly validated, the 486 KDC proceeds as per [CLAR], except as follows. 488 The KDC MUST set the initial flag and include an authorization data 489 of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is 490 an OCTET STRING containing the DER encoding of InitialVerifiedCAs: 492 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 493 ca [0] Name, 494 Validated [1] BOOLEAN, 495 ... 496 } 498 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 499 containers if the list of CAs satisfies the KDC's realm's policy 500 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag). 501 Furthermore, any TGS must copy such authorization data from tickets 502 used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 503 including the AD-IF-RELEVANT container, if present. 505 Application servers that understand this authorization data type 506 SHOULD apply local policy to determine whether a given ticket bearing 507 such a type *not* contained within an AD-IF-RELEVANT container is 508 acceptable. (This corresponds to the AP server checking the 509 transited field when the TRANSITED-POLICY-CHECKED flag has not been 510 set.) If such a data type is contained within an AD-IF-RELEVANT 511 container, AP servers MAY apply local policy to determine whether the 512 authorization data is acceptable. 514 The KRB_AS_REP is otherwise unchanged from [CLAR]. The KDC encrypts 515 the reply as usual, but not with the client's long-term key. 516 Instead, it encrypts it with either a generated encryption key, or a 517 key derived from a Diffie-Hellman exchange. The contents of the 518 PA-PK-AS-REP indicate the type of encryption key that was used: 520 PA-PK-AS-REP ::= CHOICE { 521 dhInfo [0] DHRepInfo, 522 encKeyPack [1] IMPLICIT WrapContentInfo, 523 -- Type is EnvelopedData. 524 -- Content is SignedData over 525 -- ReplyKeyPack (defined below). 526 ... 527 } 529 DHRepInfo ::= SEQUENCE { 530 dhSignedData [0] ContentInfo, 531 -- Type is SignedData. 532 -- Content is KDCDHKeyInfo 533 -- (defined below). 534 serverDHNonce [1] DHNonce OPTIONAL 535 } 537 KDCDHKeyInfo ::= SEQUENCE { 538 subjectPublicKey [0] BIT STRING, 539 -- Equals public exponent 540 -- (g^a mod p). 541 -- INTEGER encoded as payload 542 -- of BIT STRING. 543 nonce [1] INTEGER (0..4294967295), 544 dhKeyExpiration [2] KerberosTime OPTIONAL, 545 -- Expiration time for KDC's 546 -- cached values. If this field 547 -- is omitted then the 548 -- serverDHNonce field MUST also 549 -- be omitted. 550 ... 551 } 553 The fields of the ContentInfo for dhSignedData are to be filled in as 554 follows: 556 1. The eContent field contains data of type KDCDHKeyInfo. 558 2. The eContentType field contains the OID value for id-pkdhkeydata: 559 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 560 pkinit(3) pkdhkeydata(2) }. 562 3. The signerInfos field contains a single signerInfo, which is the 563 signature of the KDCDHKeyInfo. 565 4. The certificates field contains a signature verification 566 certificate chain that the client will use to verify the KDC's 567 signature over the KDCDHKeyInfo. This field may only be left 568 empty if the client did include a kdcCert field in the 569 PA-PK-AS-REQ, indicating that it has the KDC's certificate. The 570 certificate chain MUST NOT contain the root CA certificate. 572 5. If the client included the clientDHNonce field, then the KDC may 573 choose to reuse its DH parameters. If the server reuses DH 574 parameters then it MUST include an expiration time in the 575 dhKeyExperiation field. Past the point of the expiration time, 576 the signature of the DHRepInfo is considered invalid. When the 577 server reuses DH parameters then it MUST include a serverDHNonce 578 at least as long as the length of keys for the symmetric 579 encryption system used to encrypt the AS reply. Note that 580 including the serverDHNonce changes how the client and server 581 calculate the key to use to encrypt the reply; see below for 582 details. Clients MUST NOT reuse DH parameters unless the 583 response includes the serverDHNonce field. 585 If the Diffie-Hellman key exchange is used, the KDC reply key [CLAR] 586 is derived as follows: 588 1. Both the KDC and the client calculate the shared secret value 590 DHKey = g^(ab) mod p 592 where a and b are the client's and KDC's private exponents, 593 respectively. DHKey, padded first with leading zeros as needed to 594 make it as long as the modulus p, is represented as a string of 595 octets in big-endian order (such that the size of DHKey in octets 596 is the size of the modulus p). 598 2. Let K be the key-generation seed length [KCRYPTO] of the reply 599 key whose enctype is selected according to [CLAR]. 601 3. Define the function octetstring2key() as follows: 603 octetstring2key(x) == random-to-key(K-truncate( 604 SHA1(0x00 | x) | 605 SHA1(0x01 | x) | 606 SHA1(0x02 | x) | 607 ... 608 )) 610 where x is an octet string; | is the concatenation operator; 0x00, 611 0x01, 0x02, etc., are each represented as a single octet; 612 random-to-key() is an operation that generates a protocolkey from 613 a bitstring of length K; and K-truncate truncates its input to K 614 bits. Both K and random-to-key() are defined in the kcrypto 615 profile [KCRYPTO] for the enctype of the reply key. 617 4. When cached DH parameters are used, let n_c be the clientDHNonce, 618 and n_k be the serverDHNonce; otherwise, let both n_c and n_k be 619 empty octet strings. 621 5. The KDC reply key k is: 623 k = octetstring2key(DHKey | n_c | n_k) 625 If the Diffie-Hellman key exchange is not used, the KDC reply key 626 [CLAR] is encrypted in the encKeyPack, which contains data of type 627 ReplyKeyPack: 629 ReplyKeyPack ::= SEQUENCE { 630 replyKey [0] EncryptionKey, 631 -- Defined in [CLAR]. 632 -- Used to encrypt main reply. 633 -- MUST be at least as strong 634 -- as session key. (Using the 635 -- same enctype and a strong 636 -- prng should suffice, if no 637 -- stronger encryption system 638 -- is available.) 639 nonce [1] INTEGER (0..4294967295), 640 -- Contains the nonce in 641 -- the KDCDHKeyInfo. 642 ... 643 } 645 The fields of the ContentInfo for encKeyPack MUST be filled in as 646 follows: 648 1. The content is of type SignedData. The eContent for the 649 SignedData is of type ReplyKeyPack. 651 2. The eContentType for the SignedData contains the OID value for 652 id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5) 653 kerberosv5(2) pkinit(3) pkrkeydata(3) }. 655 3. The signerInfos field contains a single signerInfo, which is the 656 signature of the ReplyKeyPack. 658 4. The certificates field contains a signature verification 659 certificate chain that the client will use to verify the KDC's 660 signature over the ReplyKeyPack. This field may only be left 661 empty if the client included a kdcCert field in the PA-PK-AS-REQ, 662 indicating that it has the KDC's certificate. The certificate 663 chain MUST NOT contain the root CA certificate. 665 5. The contentType for the EnvelopedData contains the OID value for 666 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 667 pkcs (1) pkcs7 (7) signedData (2) }. 669 6. The recipientInfos field is a SET which MUST contain exactly one 670 member of type KeyTransRecipientInfo. The encryptedKey for this 671 member contains the temporary key which is encrypted using the 672 client's public key. 674 7. The unprotectedAttrs or originatorInfo fields MAY be present. 676 3.2.4 Validation of KDC Reply 678 Upon receipt of the KDC's reply, the client proceeds as follows. If 679 the PA-PK-AS-REP contains a dhSignedData, the client obtains and 680 verifies the Diffie-Hellman parameters, and obtains the shared key as 681 described above. Otherwise, the message contains an encKeyPack, and 682 the client decrypts and verifies the temporary encryption key. 684 In either case, the client MUST check to see if the included 685 certificate contains a subjectAltName extension of type dNSName or 686 iPAddress (if the KDC is specified by IP address instead of name). 687 If it does, it MUST check to see if that extension matches the KDC it 688 believes it is communicating with, with matching rules specified in 689 RFC 2459. Exception: If the client has some external information as 690 to the identity of the KDC, this check MAY be omitted. 692 The client also MUST check that the KDC's certificate contains an 693 extendedKeyUsage OID of id-pkkdcekuoid: 695 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 696 pkinit(3) pkkdcekuoid(5) } 698 If all applicable checks are satisfied, the client then decrypts the 699 main reply with the resulting key, and then proceeds as described in 700 [1]. 702 3.3 KDC Indication of PKINIT Support 704 If pre-authentication is required, but was not present in the 705 request, per [CLAR] an error message with the code 706 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 707 stored in the e-data field of the KRB-ERROR message to specify which 708 pre-authentication mechanisms are acceptable. The KDC can then 709 indicate the support of PKINIT by including a PA-PK-AS-REQ element in 710 that METHOD-DATA object. 712 Otherwise if it is required by the KDC's local policy that the client 713 must be pre-authenticated using the preauthentication mechanism 714 specified in this document, but no PKINIT pre-authentication was 715 present in the request, an error message with the code 716 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 718 The padata-value for the PA-PK-AS-REQ entry in the METHOD-DATA object 719 is an empty octet string and SHOULD be ignored otherwise. 721 4. Security Considerations 723 PKINIT raises certain security considerations beyond those that can 724 be regulated strictly in protocol definitions. We will address them 725 in this section. 727 PKINIT extends the cross-realm model to the public-key 728 infrastructure. Users of PKINIT must understand security policies 729 and procedures appropriate to the use of Public Key Infrastructures. 731 Standard Kerberos allows the possibility of interactions between 732 cryptosystems of varying strengths; this document adds interactions 733 with public-key cryptosystems to Kerberos. Some administrative 734 policies may allow the use of relatively weak public keys. Using 735 such keys to wrap data encrypted under stronger conventional 736 cryptosystems may be inappropriate. 738 PKINIT requires keys for symmetric cryptosystems to be generated. 739 Some such systems contain "weak" keys. For recommendations regarding 740 these weak keys, see [CLAR]. 742 PKINIT allows the use of a zero nonce in the PKAuthenticator when 743 cached Diffie-Hellman keys are used. In this case, message binding 744 is performed using the nonce in the main request in the same way as 745 it is done for ordinary KRB_AS_REQs (without the PKINIT 746 pre-authenticator). The nonce field in the KDC request body is 747 signed through the checksum in the PKAuthenticator, which 748 cryptographically binds the PKINIT pre-authenticator to the main body 749 of the AS Request and also provides message integrity for the full AS 750 Request. 752 However, when a PKINIT pre-authenticator in the KRB_AS_REP has a 753 zero-nonce, and an attacker has somehow recorded this 754 pre-authenticator and discovered the corresponding Diffie-Hellman 755 private key (e.g., with a brute-force attack), the attacker will be 756 able to fabricate his own KRB_AS_REP messages that impersonate the 757 KDC with this same pre-authenticator. This compromised 758 pre-authenticator will remain valid as long as its expiration time 759 has not been reached and it is therefore important for clients to 760 check this expiration time and for the expiration time to be 761 reasonably short, which depends on the size of the Diffie-Hellman 762 group. 764 Care should be taken in how certificates are chosen for the purposes 765 of authentication using PKINIT. Some local policies may require that 766 key escrow be used for certain certificate types. Deployers of 767 PKINIT should be aware of the implications of using certificates that 768 have escrowed keys for the purposes of authentication. 770 PKINIT does not provide for a "return routability" test to prevent 771 attackers from mounting a denial-of-service attack on the KDC by 772 causing it to perform unnecessary and expensive public-key 773 operations. Strictly speaking, this is also true of standard 774 Kerberos, although the potential cost is not as great, because 775 standard Kerberos does not make use of public-key cryptography. 777 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 778 permit empty SEQUENCEs to be encoded. Such empty sequences may only 779 be used if the KDC itself vouches for the user's certificate. [This 780 seems to reflect the consensus of the Kerberos working group.] 782 5. Acknowledgements 784 The following people have made significant contributions to this 785 draft: Paul Leach, Sam Hartman, Love Hornquist Astrand, Ken Raeburn, 786 Nicolas Williams, John Wray, Jonathan Trostle, Tom Yu and Jeff 787 Hutzelman. 789 Some of the ideas on which this document is based arose during 790 discussions over several years between members of the SAAG, the IETF 791 CAT working group, and the PSRG, regarding integration of Kerberos 792 and SPX. Some ideas have also been drawn from the DASS system. 793 These changes are by no means endorsed by these groups. This is an 794 attempt to revive some of the goals of those groups, and this 795 document approaches those goals primarily from the Kerberos 796 perspective. Lastly, comments from groups working on similar ideas 797 in DCE have been invaluable. 799 6. IANA Considerations 801 This document has no actions for IANA. 803 7 Normative References 805 [CLAR] Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The 806 Kerberos Network Authentication Service (V5)", 807 draft-ietf-krb-wg-kerberos-clarifications, work in 808 progress. 810 [FIPS74] NIST, Guidelines for Implementing and Using 811 the NBS Encryption Standard, April 1981. FIPS PUB 74. 813 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 814 Kerberos 5", December 2004. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 820 (IKE)", RFC 2409, November 1998. 822 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 823 Specifications Version 2.0", RFC 2437, October 1998. 825 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 826 June 1999. 828 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and 829 Identifiers for the Internet X.509 Public Key 830 Infrastructure Certificate and Certificate Revocation List 831 (CRL) Profile", RFC 3279, April 2002. 833 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 834 X.509 Public Key Infrastructure Certificate and 835 Certificate Revocation List (CRL) Profile", RFC 3280, 836 April 2002. 838 [X690] ASN.1 encoding rules: Specification of Basic 839 Encoding Rules (BER), Canonical Encoding Rules (CER) and 840 Distinguished Encoding Rules (DER), ITU-T Recommendation 841 X.690 (1997) | ISO/IEC International Standard 842 8825-1:1998. 844 Authors' Addresses 846 Brian Tung 847 USC Information Sciences Institute 848 4676 Admiralty Way Suite 1001, Marina del Rey CA 849 Marina del Rey, CA 90292 850 US 852 EMail: brian@isi.edu 854 Clifford Neuman 855 USC Information Sciences Institute 856 4676 Admiralty Way Suite 1001, Marina del Rey CA 857 Marina del Rey, CA 90292 858 US 860 EMail: brian@isi.edu 862 Larry Zhu 863 Microsoft Corporation 864 One Microsoft Way 865 Redmond, WA 98052 866 US 868 EMail: lzhu@microsoft.com 870 Matt Hur 871 Microsoft Corporation 872 One Microsoft Way 873 Redmond, WA 98052 874 US 876 EMail: matthur@microsoft.com 878 Sasha Medvinsky 879 Motorola, Inc. 880 6450 Sequence Drive 881 San Diego, CA 92121 882 US 884 EMail: smedvinsky@motorola.com 886 Appendix A. PKINIT ASN.1 Module 888 KerberosV5-PK-INIT-SPEC { 889 iso(1) identified-organization(3) dod(6) internet(1) 890 security(5) kerberosV5(2) modules(4) pkinit(3) 891 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 893 IMPORTS 894 SubjectPublicKeyInfo, AlgorithmIdentifier, Name 895 FROM PKIX1Explicit88 { iso (1) 896 identified-organization (3) dod (6) internet (1) 897 security (5) mechanisms (5) pkix (7) id-mod (0) 898 id-pkix1-explicit (18) } 900 ContentInfo, IssuerAndSerialNumber 901 FROM CryptographicMessageSyntax { iso(1) member-body(2) 902 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 903 modules(0) cms(1) } 905 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey 906 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 907 dod(6) internet(1) security(5) kerberosV5(2) 908 modules(4) krb5spec2(2) } ; 910 id-pkinit OBJECT IDENTIFIER ::= 911 { iso (1) org (3) dod (6) internet (1) security (5) 912 kerberosv5 (2) pkinit (3) } 914 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } 915 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 916 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 917 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 918 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 920 pa-pk-as-req INTEGER ::= 16 921 pa-pk-as-rep INTEGER ::= 17 923 ad-initial-verified-cas INTEGER ::= 9 925 td-trusted-certifiers INTEGER ::= 104 926 td-certificate-index INTEGER ::= 105 927 td-dh-parameters INTEGER ::= 109 928 WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { 929 -- Contains a BER encoding of ContentInfo. 930 }) 932 WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { 933 -- Contains a BER encoding of IssuerAndSerialNumber. 934 }) 936 PA-PK-AS-REQ ::= SEQUENCE { 937 signedAuthPack [0] IMPLICIT WrapContentInfo, 938 -- Type is SignedData. 939 -- Content is AuthPack 940 -- (defined below). 941 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 942 -- A list of CAs, trusted by 943 -- the client, used to certify 944 -- KDCs. 945 kdcCert [2] IMPLICIT WrapIssuerAndSerial 946 OPTIONAL, 947 -- Identifies a particular KDC 948 -- certificate, if the client 949 -- already has it. 950 clientDHNonce [3] DHNonce OPTIONAL, 951 ... 952 } 954 TrustedCA ::= CHOICE { 955 caName [1] Name, 956 -- Fully qualified X.500 name 957 -- as defined in [RFC3280]. 958 issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, 959 -- Identifies a specific CA 960 -- certificate. 961 ... 962 } 964 AuthPack ::= SEQUENCE { 965 pkAuthenticator [0] PKAuthenticator, 966 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 967 -- Defined in [RFC3280]. 968 -- Present only if the client 969 -- is using ephemeral-ephemeral 970 -- Diffie-Hellman. 971 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 972 OPTIONAL, 973 -- List of CMS encryption types 974 -- supported by client in order 975 -- of (decreasing) preference. 976 ... 977 } 979 PKAuthenticator ::= SEQUENCE { 980 cusec [0] INTEGER (0..999999), 981 ctime [1] KerberosTime, 982 -- cusec and ctime are used as 983 -- in [CLAR], for replay 984 -- prevention. 985 nonce [2] INTEGER (0..4294967295), 986 paChecksum [3] OCTET STRING, 987 -- Contains the SHA1 checksum, 988 -- performed over KDC-REQ-BODY. 989 ... 990 } 992 TrustedCertifiers ::= SEQUENCE OF Name 994 CertificateIndex ::= IssuerAndSerialNumber 996 KRB5PrincipalName ::= SEQUENCE { 997 realm [0] Realm, 998 principalName [1] PrincipalName 999 } 1001 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 1002 ca [0] Name, 1003 Validated [1] BOOLEAN, 1004 ... 1005 } 1007 PA-PK-AS-REP ::= CHOICE { 1008 dhInfo [0] DHRepInfo, 1009 encKeyPack [1] IMPLICIT WrapContentInfo, 1010 -- Type is EnvelopedData. 1011 -- Content is SignedData over 1012 -- ReplyKeyPack (defined below). 1013 ... 1015 } 1017 DHRepInfo ::= SEQUENCE { 1018 dhSignedData [0] ContentInfo, 1019 -- Type is SignedData. 1020 -- Content is KDCDHKeyInfo 1021 -- (defined below). 1022 serverDHNonce [1] DHNonce OPTIONAL 1023 } 1025 KDCDHKeyInfo ::= SEQUENCE { 1026 subjectPublicKey [0] BIT STRING, 1027 -- Equals public exponent 1028 -- (g^a mod p). 1029 -- INTEGER encoded as payload 1030 -- of BIT STRING. 1031 nonce [1] INTEGER (0..4294967295), 1032 dhKeyExpiration [2] KerberosTime OPTIONAL, 1033 -- Expiration time for KDC's 1034 -- cached values. If this field 1035 -- is omitted then the 1036 -- serverDHNonce field MUST also 1037 -- be omitted. 1038 ... 1039 } 1041 ReplyKeyPack ::= SEQUENCE { 1042 replyKey [0] EncryptionKey, 1043 -- Defined in [CLAR]. 1044 -- Used to encrypt main reply. 1045 -- MUST be at least as strong 1046 -- as session key. (Using the 1047 -- same enctype and a strong 1048 -- prng should suffice, if no 1049 -- stronger encryption system 1050 -- is available.) 1051 nonce [1] INTEGER (0..4294967295), 1052 -- Contains the nonce in 1053 -- the KDCDHKeyInfo. 1054 ... 1055 } 1057 END 1059 Intellectual Property Statement 1061 The IETF takes no position regarding the validity or scope of any 1062 Intellectual Property Rights or other rights that might be claimed to 1063 pertain to the implementation or use of the technology described in 1064 this document or the extent to which any license under such rights 1065 might or might not be available; nor does it represent that it has 1066 made any independent effort to identify any such rights. Information 1067 on the procedures with respect to rights in RFC documents can be 1068 found in BCP 78 and BCP 79. 1070 Copies of IPR disclosures made to the IETF Secretariat and any 1071 assurances of licenses to be made available, or the result of an 1072 attempt made to obtain a general license or permission for the use of 1073 such proprietary rights by implementers or users of this 1074 specification can be obtained from the IETF on-line IPR repository at 1075 http://www.ietf.org/ipr. 1077 The IETF invites any interested party to bring to its attention any 1078 copyrights, patents or patent applications, or other proprietary 1079 rights that may cover technology that may be required to implement 1080 this standard. Please address the information to the IETF at 1081 ietf-ipr@ietf.org. 1083 Disclaimer of Validity 1085 This document and the information contained herein are provided on an 1086 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1087 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1088 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1089 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1090 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1091 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1093 Copyright Statement 1095 Copyright (C) The Internet Society (2004). This document is subject 1096 to the rights, licenses and restrictions contained in BCP 78, and 1097 except as set forth therein, the authors retain all their rights. 1099 Acknowledgment 1101 Funding for the RFC Editor function is currently provided by the 1102 Internet Society.