idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-26.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 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (May 23, 2005) is 6907 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 1336 -- Looks like a reference, but probably isn't: '1' on line 1339 -- Looks like a reference, but probably isn't: '2' on line 1327 -- Looks like a reference, but probably isn't: '3' on line 1247 == Unused Reference: 'LENSTRA' is defined on line 1088, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP B. Tung 3 Internet-Draft USC Information Sciences Institute 4 Expires: November 24, 2005 L. Zhu 5 Microsoft Corporation 6 May 23, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-26 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes protocol extensions (hereafter called PKINIT) 46 to the Kerberos protocol specification. These extensions provide a 47 method for integrating public key cryptography into the initial 48 authentication exchange, by using asymmetric-key signature and/or 49 encryption algorithms in pre-authentication data fields. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 57 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 58 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 59 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 60 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 61 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7 62 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10 63 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13 64 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 65 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 66 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 72 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 74 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 75 Intellectual Property and Copyright Statements . . . . . . . . 30 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 exposes his 89 long-term secrets only once. The TGT and its associated session key 90 can then be used for any subsequent service ticket requests. One 91 result of this is that all further authentication is independent of 92 the method by which the initial authentication was performed. 93 Consequently, initial authentication provides a convenient place to 94 integrate public-key cryptography into Kerberos authentication. 96 As defined in [CLAR], Kerberos authentication exchanges use 97 symmetric-key cryptography, in part for performance. One 98 disadvantage of using symmetric-key cryptography is that the keys 99 must be shared, so that before a client can authenticate itself, he 100 must already be registered with the KDC. 102 Conversely, public-key cryptography (in conjunction with an 103 established Public Key Infrastructure) permits authentication without 104 prior registration with a KDC. Adding it to Kerberos allows the 105 widespread use of Kerberized applications by clients without 106 requiring them to register first with a KDC--a requirement that has 107 no inherent security benefit. 109 As noted above, a convenient and efficient place to introduce public- 110 key cryptography into Kerberos is in the initial authentication 111 exchange. This document describes the methods and data formats for 112 integrating public-key cryptography into Kerberos initial 113 authentication. 115 2. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 Both the AS and the TGS are referred to as the KDC. 123 In this document, the encryption key used to encrypt the enc-part 124 field of the KDC-REP in the AS-REP [CLAR] is referred to as the AS 125 reply key. 127 3. Extensions 129 This section describes extensions to [CLAR] for supporting the use of 130 public-key cryptography in the initial request for a ticket. 132 Briefly, this document defines the following extensions to [CLAR]: 134 1. The client indicates the use of public-key authentication by 135 including a special preauthenticator in the initial request. This 136 preauthenticator contains the client's public-key data and a 137 signature. 139 2. The KDC tests the client's request against its authentication 140 policy and trusted Certification Authorities (CAs). 142 3. If the request passes the verification tests, the KDC replies as 143 usual, but the reply is encrypted using either: 145 a. a key generated through a Diffie-Hellman (DH) key exchange 146 [RFC2631] [IEEE1363] with the client, signed using the KDC's 147 signature key; or 149 b. a symmetric encryption key, signed using the KDC's signature 150 key and encrypted using the client's public key. 152 Any keying material required by the client to obtain the 153 encryption key for decrypting the KDC reply is returned in a pre- 154 authentication field accompanying the usual reply. 156 4. The client validates the KDC's signature, obtains the encryption 157 key, decrypts the reply, and then proceeds as usual. 159 Section 3.1 of this document enumerates the required algorithms and 160 necessary extension message types. Section 3.2 describes the 161 extension messages in greater detail. 163 3.1 Definitions, Requirements, and Constants 165 3.1.1 Required Algorithms 167 All PKINIT implementations MUST support the following algorithms: 169 o AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3962]. 171 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 173 o AS reply key delivery method: Diffie-Hellman key exchange 174 [RFC2631]. 176 3.1.2 Defined Message and Encryption Types 178 PKINIT makes use of the following new pre-authentication types: 180 PA_PK_AS_REQ 16 181 PA_PK_AS_REP 17 183 PKINIT also makes use of the following new authorization data type: 185 AD_INITIAL_VERIFIED_CAS 9 187 PKINIT introduces the following new error codes: 189 KDC_ERR_CLIENT_NOT_TRUSTED 62 190 KDC_ERR_INVALID_SIG 64 191 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 192 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 193 KDC_ERR_INVALID_CERTIFICATE 71 194 KDC_ERR_REVOKED_CERTIFICATE 72 195 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 196 KDC_ERR_CLIENT_NAME_MISMATCH 75 197 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 199 PKINIT uses the following typed data types for errors: 201 TD_TRUSTED_CERTIFIERS 104 202 TD_INVALID_CERTIFICATES 105 203 TD_DH_PARAMETERS 109 205 PKINIT defines the following encryption types, for use in the AS-REQ 206 message to indicate acceptance of the corresponding algorithms that 207 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in 208 the reply: 210 dsaWithSHA1-CmsOID 9 211 md5WithRSAEncryption-CmsOID 10 212 sha1WithRSAEncryption-CmsOID 11 213 rc2CBC-EnvOID 12 214 rsaEncryption-EnvOID (PKCS1 v1.5) 13 215 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 216 des-ede3-cbc-EnvOID 15 218 The ASN.1 module for all structures defined in this document (plus 219 IMPORT statements for all imported structures) is given in 220 Appendix A. 222 All structures defined in or imported into this document MUST be 223 encoded using Distinguished Encoding Rules (DER) [X690] (unless 224 otherwise noted). All data structures carried in OCTET STRINGs must 225 be encoded according to the rules specified in corresponding 226 specifications. 228 Interoperability note: Some implementations may not be able to decode 229 wrapped CMS objects encoded with BER but not DER; specifically, they 230 may not 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 identifiers for Diffie-Hellman 240 key agreement [RFC3279]: 242 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) 243 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363]) 245 PKINIT uses the following signature algorithm identifiers [RFC3279]: 247 sha-1WithRSAEncryption (RSA with SHA1) 248 md5WithRSAEncryption (RSA with MD5) 249 id-dsa-with-sha1 (DSA with SHA1) 251 PKINIT uses the following encryption algorithm identifiers [RFC3447] 252 for encrypting the temporary key with a public key: 254 rsaEncryption (PKCS1 v1.5) 255 id-RSAES-OAEP (PKCS1 v2.0) 257 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 258 for encrypting the AS reply key with the temporary key: 260 des-ede3-cbc (three-key 3DES, CBC mode) 261 rc2-cbc (RC2, CBC mode) 262 id-aes256-CBC (AES-256, CBC mode) 264 3.2 PKINIT Pre-authentication Syntax and Use 266 This section defines the syntax and use of the various pre- 267 authentication fields employed by PKINIT. 269 3.2.1 Generation of Client Request 271 The initial authentication request (AS-REQ) is sent as per [CLAR]; in 272 addition, a pre-authentication data element, whose padata-type is 273 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 274 type PA-PK-AS-REQ, is included. 276 PA-PK-AS-REQ ::= SEQUENCE { 277 signedAuthPack [0] IMPLICIT OCTET STRING, 278 -- Contains a CMS type ContentInfo encoded 279 -- according to [RFC3852]. 280 -- The contentType field of the type ContentInfo 281 -- is id-signedData (1.2.840.113549.1.7.2), 282 -- and the content field is a SignedData. 283 -- The eContentType field for the type SignedData is 284 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 285 -- eContent field contains the DER encoding of the 286 -- type AuthPack. 287 -- AuthPack is defined below. 288 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 289 -- A list of CAs, trusted by the client, that can 290 -- be used to certify the KDC. 291 -- Each TrustedCA identifies a CA or a CA 292 -- certificate (thereby its public key). 293 -- The information contained in the 294 -- trustedCertifiers SHOULD be used by the KDC as 295 -- hints to guide its selection of an appropriate 296 -- certificate chain to return to the client. 297 kdcPkId [2] IMPLICIT OCTET STRING 298 OPTIONAL, 299 -- Contains a CMS type SignerIdentifier encoded 300 -- according to [RFC3852]. 301 -- Identifies, if present, a particular KDC 302 -- public key that the client already has. 303 ... 304 } 306 DHNonce ::= OCTET STRING 308 TrustedCA ::= SEQUENCE { 309 caName [0] IMPLICIT OCTET STRING, 310 -- Contains a PKIX type Name encoded according to 311 -- [RFC3280]. 313 -- Identifies a CA by the CA's distinguished subject 314 -- name. 315 certificateSerialNumber [1] INTEGER OPTIONAL, 316 -- Specifies the CA certificate's serial number. 317 -- The defintion of the certificate serial number 318 -- is taken from X.509 [X.509-97]. 319 subjectKeyIdentifier [2] OCTET STRING OPTIONAL, 320 -- Identifies the CA's public key by a key 321 -- identifier. When an X.509 certificate is 322 -- referenced, this key identifier matches the X.509 323 -- subjectKeyIdentifier extension value. When other 324 -- certificate formats are referenced, the documents 325 -- that specify the certificate format and their use 326 -- with the CMS must include details on matching the 327 -- key identifier to the appropriate certificate 328 -- field. 329 ... 330 } 332 AuthPack ::= SEQUENCE { 333 pkAuthenticator [0] PKAuthenticator, 334 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 335 -- Type SubjectPublicKeyInfo is defined in 336 -- [RFC3280]. 337 -- Specifies Diffie-Hellman domain parameters 338 -- and the client's public key value [IEEE1363]. 339 -- The DH public key value is encoded as a BIT 340 -- STRING, as specified in Section 2.3.3 of 341 -- [RFC3279]. 342 -- This field is present only if the client wishes 343 -- to use the Diffie-Hellman key agreement method. 344 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 345 OPTIONAL, 346 -- Type AlgorithmIdentifier is defined in 347 -- [RFC3280]. 348 -- List of CMS encryption types supported by the 349 -- client in order of (decreasing) preference. 350 clientDHNonce [3] DHNonce OPTIONAL, 351 -- Present only if the client indicates that it 352 -- wishes to reuse DH keys or to allow the KDC to 353 -- do so (see Section 3.2.3.1). 354 ... 355 } 357 PKAuthenticator ::= SEQUENCE { 358 cusec [0] INTEGER (0..999999), 359 ctime [1] KerberosTime, 360 -- cusec and ctime are used as in [CLAR], for replay 361 -- prevention. 362 nonce [2] INTEGER (0..4294967295), 363 -- Chosen randomly; This nonce does not need to 364 -- match with the nonce in the KDC-REQ-BODY. 365 paChecksum [3] OCTET STRING, 366 -- Contains the SHA1 checksum, performed over 367 -- KDC-REQ-BODY. 368 ... 369 } 371 The ContentInfo [RFC3852] structure for the signedAuthPack field is 372 filled out as follows: 374 1. The contentType field of the type ContentInfo is id-signedData 375 (as defined in [RFC3852]), and the content field is a SignedData 376 (as defined in [RFC3852]). 378 2. The eContentType field for the type SignedData is id-pkauthdata: 379 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 380 pkinit(3) pkauthdata(1) }. 382 3. The eContent field for the type SignedData contains the DER 383 encoding of the type AuthPack. 385 4. The signerInfos field of the type SignedData contains a single 386 signerInfo, which contains the signature over the type AuthPack. 388 5. The certificates field of the type SignedData contains 389 certificates intended to facilitate certification path 390 construction, so that the KDC can verify the signature over the 391 type AuthPack. For path validation, these certificates SHOULD be 392 sufficient to construct at least one certification path from the 393 client certificate to one trust anchor acceptable by the KDC 394 [CAPATH]. The client MUST be capable of including such a set of 395 certificates if configured to do so. The certificates field MUST 396 NOT contain "root" CA certificates. 398 6. The client's Diffie-Hellman public value (clientPublicValue) is 399 included if and only if the client wishes to use the Diffie- 400 Hellman key agreement method. The Diffie-Hellman domain 401 parameters [IEEE1363] for the client's public key are specified 402 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 403 and the client's Diffie-Hellman public key value is mapped to a 404 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 405 using the Diffie-Hellman key agreement method, implementations 406 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 407 known group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP 408 well-known group 14 and Oakley 4096-bit MODP well-known group 16 410 [RFC3526]. 412 The Diffie-Hellman field size should be chosen so as to provide 413 sufficient cryptographic security [RFC3766]. 415 When MODP Diffie-Hellman is used, the exponents should have at 416 least twice as many bits as the symmetric keys that will be 417 derived from them [ODL99]. 419 7. The client may wish to reuse DH keys or to allow the KDC to do so 420 (see Section 3.2.3.1). If so, then the client includes the 421 clientDHNonce field. This nonce string needs to be as long as 422 the longest key length of the symmetric key types that the client 423 supports. This nonce MUST be chosen randomly. 425 3.2.2 Receipt of Client Request 427 Upon receiving the client's request, the KDC validates it. This 428 section describes the steps that the KDC MUST (unless otherwise 429 noted) take in validating the request. 431 The KDC verifies the client's signature in the signedAuthPack field 432 according to [RFC3852]. 434 If, while validating the client's X.509 certificate [RFC3280], the 435 KDC cannot build a certification path to validate the client's 436 certificate, it sends back a KRB-ERROR [CLAR] message with the code 437 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this 438 error message is a TYPED-DATA (as defined in [CLAR]) that contains an 439 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data- 440 value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS: 442 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA 443 -- Identifies a list of CAs trusted by the KDC. 444 -- Each TrustedCA identifies a CA or a CA 445 -- certificate (thereby its public key). 447 Upon receiving this error message, the client SHOULD retry only if it 448 has a different set of certificates (from those of the previous 449 requests) that form a certification path (or a partial path) from one 450 of the trust anchors acceptable by the KDC to its own certificate. 452 If, while processing the certification path, the KDC determines that 453 the signature on one of the certificates in the signedAuthPack field 454 is invalid, it returns a KRB-ERROR [CLAR] message with the code 455 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 456 message is a TYPED-DATA that contains an element whose data-type is 457 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 458 encoding of the type TD-INVALID-CERTIFICATES: 460 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING 461 -- Each OCTET STRING contains a CMS type 462 -- IssuerAndSerialNumber encoded according to 463 -- [RFC3852]. 464 -- Each IssuerAndSerialNumber identifies a 465 -- certificate (sent by the client) with an invalid 466 -- signature. 468 If more than one X.509 certificate signature is invalid, the KDC MAY 469 include one IssuerAndSerialNumber per invalid signature within the 470 TD-INVALID-CERTIFICATES. 472 The client's X.509 certificate is validated according to [RFC3280]. 474 Based on local policy, the KDC may also check whether any X.509 475 certificates in the certification path validating the client's 476 certificate have been revoked. If any of them have been revoked, the 477 KDC MUST return an error message with the code 478 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 479 revocation status but is unable to do so, it SHOULD return an error 480 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 481 certificate or certificates affected are identified exactly as for 482 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 484 Note that the TD_INVALID_CERTIFICATES error data is only used to 485 identify invalid certificates sent by the client in the request. 487 The client's public key is then used to verify the signature. If the 488 signature fails to verify, the KDC MUST return an error message with 489 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 490 this error message. 492 In addition to validating the client's signature, the KDC MUST also 493 check that the client's public key used to verify the client's 494 signature is bound to the client's principal name as specified in the 495 AS-REQ as follows: 497 1. If the KDC has its own binding between either the client's 498 signature-verification public key or the client's certificate and 499 the client's Kerberos principal name, it uses that binding. 501 2. Otherwise, if the client's X.509 certificate contains a Subject 502 Alternative Name (SAN) extension carrying a KRB5PrincipalName 503 (defined below) in the otherName field of the type GeneralName 504 [RFC3280], it binds the client's X.509 certificate to that name. 506 The type of the otherName field is AnotherName. The type-id field 507 of the type AnotherName is id-pksan: 509 id-pksan OBJECT IDENTIFIER ::= 510 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 511 x509-sanan (2) } 513 And the value field of the type AnotherName is a 514 KRB5PrincipalName. 516 KRB5PrincipalName ::= SEQUENCE { 517 realm [0] Realm, 518 principalName [1] PrincipalName 519 } 521 If the KDC does not have its own binding and there is no 522 KRB5PrincipalName name present in the client's X.509 certificate, or 523 if the Kerberos name in the request does not match the 524 KRB5PrincipalName in the client's X.509 certificate (including the 525 realm name), the KDC MUST return an error message with the code 526 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 527 this error message. 529 The KDC MAY require the presence of an Extended Key Usage (EKU) 530 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the 531 client's X.509 certificate: 533 id-pkekuoid OBJECT IDENTIFIER ::= 534 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 535 pkinit(3) pkekuoid(4) } 536 -- PKINIT client authentication. 537 -- Key usage bits that MUST be consistent: 538 -- digitalSignature. 540 If this EKU KeyPurposeId is required but it is not present or if the 541 client certificate is restricted not to be used for PKINIT client 542 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 543 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 544 is no accompanying e-data for this error message. KDCs implementing 545 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc- 546 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 547 are a large number of X.509 client certificates deployed for use with 548 PKINIT which have this EKU. 550 If for any other reasons, the client's public key is not accepted, 551 the KDC MUST return an error message with the code 552 KDC_ERR_CLIENT_NOT_TRUSTED. 554 The KDC MUST check the timestamp to ensure that the request is not a 555 replay, and that the time skew falls within acceptable limits. The 556 recommendations for clock skew times in [CLAR] apply here. If the 557 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 558 KRB_AP_ERR_SKEW, respectively. 560 If the clientPublicValue is filled in, indicating that the client 561 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 562 check to see if the key parameters satisfy its policy. If they do 563 not, it MUST return an error message with the code 564 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 565 TYPED-DATA that contains an element whose data-type is 566 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 567 the type TD-DH-PARAMETERS: 569 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 570 -- Each AlgorithmIdentifier specifies a set of 571 -- Diffie-Hellman domain parameters [IEEE1363]. 572 -- This list is in decreasing preference order. 574 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 575 that the KDC supports in decreasing preference order, from which the 576 client SHOULD pick one to retry the request. 578 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 579 KDC does not possess the corresponding key, the KDC MUST ignore the 580 kdcPkId field as if the client did not include one. 582 If there is a supportedCMSTypes field in the AuthPack, the KDC must 583 check to see if it supports any of the listed types. If it supports 584 more than one of the types, the KDC SHOULD use the one listed first. 585 If it does not support any of them, it MUST return an error message 586 with the code KDC_ERR_ETYPE_NOSUPP [CLAR]. 588 3.2.3 Generation of KDC Reply 590 Assuming that the client's request has been properly validated, the 591 KDC proceeds as per [CLAR], except as follows. 593 The KDC MUST set the initial flag and include an authorization data 594 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued 595 ticket. The ad-data [CLAR] field contains the DER encoding of the 596 type AD-INITIAL-VERIFIED-CAS: 598 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA 599 -- Identifies the certification path based on which 600 -- the client certificate was validated. 601 -- Each TrustedCA identifies a CA or a CA 602 -- certificate (thereby its public key). 604 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 605 containers if the list of CAs satisfies the AS' realm's local policy 606 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 607 [CLAR]). Furthermore, any TGS MUST copy such authorization data from 608 tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting 609 ticket. If the list of CAs satisfies the local KDC's realm's policy, 610 the TGS MAY wrap the data into the AD-IF-RELEVANT container, 611 otherwise it MAY unwrap the authorization data out of the AD-IF- 612 RELEVANT container. 614 Application servers that understand this authorization data type 615 SHOULD apply local policy to determine whether a given ticket bearing 616 such a type *not* contained within an AD-IF-RELEVANT container is 617 acceptable. (This corresponds to the AP server checking the 618 transited field when the TRANSITED-POLICY-CHECKED flag has not been 619 set [CLAR].) If such a data type is contained within an AD-IF- 620 RELEVANT container, AP servers MAY apply local policy to determine 621 whether the authorization data is acceptable. 623 The content of the AS-REP is otherwise unchanged from [CLAR]. The 624 KDC encrypts the reply as usual, but not with the client's long-term 625 key. Instead, it encrypts it with either a shared key derived from a 626 Diffie-Hellman exchange, or a generated encryption key. The contents 627 of the PA-PK-AS-REP indicate which key delivery method is used: 629 PA-PK-AS-REP ::= CHOICE { 630 dhInfo [0] DHRepInfo, 631 -- Selected when Diffie-Hellman key exchange is 632 -- used. 633 encKeyPack [1] IMPLICIT OCTET STRING, 634 -- Selected when public key encryption is used. 635 -- Contains a CMS type ContentInfo encoded 636 -- according to [RFC3852]. 637 -- The contentType field of the type ContentInfo is 638 -- id-envelopedData (1.2.840.113549.1.7.3). 639 -- The content field is an EnvelopedData. 640 -- The contentType field for the type EnvelopedData 641 -- is id-signedData (1.2.840.113549.1.7.2). 642 -- The eContentType field for the inner type 643 -- SignedData (when unencrypted) is id-pkrkeydata 644 -- (1.2.840.113549.1.7.3) and the eContent field 645 -- contains the DER encoding of the type 646 -- ReplyKeyPack. 647 -- ReplyKeyPack is defined in Section 3.2.3.2. 648 ... 649 } 651 DHRepInfo ::= SEQUENCE { 652 dhSignedData [0] IMPLICIT OCTET STRING, 653 -- Contains a CMS type ContentInfo encoded according 654 -- to [RFC3852]. 655 -- The contentType field of the type ContentInfo is 656 -- id-signedData (1.2.840.113549.1.7.2), and the 657 -- content field is a SignedData. 658 -- The eContentType field for the type SignedData is 659 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 660 -- eContent field contains the DER encoding of the 661 -- type KDCDHKeyInfo. 662 -- KDCDHKeyInfo is defined below. 663 serverDHNonce [1] DHNonce OPTIONAL 664 -- Present if and only if dhKeyExpiration is 665 -- present in the KDCDHKeyInfo. 666 } 668 KDCDHKeyInfo ::= SEQUENCE { 669 subjectPublicKey [0] BIT STRING, 670 -- KDC's DH public key. 671 -- The DH public key value is encoded as a BIT 672 -- STRING, as specified in Section 2.3.3 of 673 -- [RFC3279]. 674 nonce [1] INTEGER (0..4294967295), 675 -- Contains the nonce in the PKAuthenticator of the 676 -- request if DH keys are NOT reused, 677 -- 0 otherwise. 678 dhKeyExpiration [2] KerberosTime OPTIONAL, 679 -- Expiration time for KDC's key pair, 680 -- present if and only if DH keys are reused. If 681 -- this field is omitted then the serverDHNonce 682 -- field MUST also be omitted. See Section 3.2.3.1. 683 ... 684 } 686 3.2.3.1 Using Diffie-Hellman Key Exchange 688 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 690 The ContentInfo [RFC3852] structure for the dhSignedData field is 691 filled in as follows: 693 1. The contentType field of the type ContentInfo is id-signedData 694 (as defined in [RFC3852]), and the content field is a SignedData 695 (as defined in [RFC3852]). 697 2. The eContentType field for the type SignedData is the OID value 698 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 699 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 701 3. The eContent field for the type SignedData contains the DER 702 encoding of the type KDCDHKeyInfo. 704 4. The signerInfos field of the type SignedData contains a single 705 signerInfo, which contains the signature over the type 706 KDCDHKeyInfo. 708 5. The certificates field of the type SignedData contains 709 certificates intended to facilitate certification path 710 construction, so that the client can verify the KDC's signature 711 over the type KDCDHKeyInfo. The information contained in the 712 trustedCertifiers in the request SHOULD be used by the KDC as 713 hints to guide its selection of an appropriate certificate chain 714 to return to the client. This field may only. be left empty if 715 the KDC public key specified by the kdcPkId field in the PA-PK- 716 AS-REQ was used for signing. Otherwise, for path validation, 717 these certificates SHOULD be sufficient to construct at least one 718 certification path from the KDC certificate to one trust anchor 719 acceptable by the client [CAPATH]. The KDC MUST be capable of 720 including such a set of certificates if configured to do so. The 721 certificates field MUST NOT contain "root" CA certificates. 723 6. If the client included the clientDHNonce field, then the KDC may 724 choose to reuse its DH keys (see Section 3.2.3.1). If the server 725 reuses DH keys then it MUST include an expiration time in the 726 dhKeyExpiration field. Past the point of the expiration time, 727 the signature over the type DHRepInfo is considered expired/ 728 invalid. When the server reuses DH keys then it MUST include a 729 serverDHNonce at least as long as the length of keys for the 730 symmetric encryption system used to encrypt the AS reply. Note 731 that including the serverDHNonce changes how the client and 732 server calculate the key to use to encrypt the reply; see below 733 for details. The KDC SHOULD NOT reuse DH keys unless the 734 clientDHNonce field is present in the request. 736 The AS reply key is derived as follows: 738 1. Both the KDC and the client calculate the shared secret value as 739 follows: 741 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 742 shared secret value. DHSharedSecret is the value ZZ as 743 described in Section 2.1.1 of [RFC2631]. 745 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party 746 contributing one key pair) is used, let DHSharedSecret be the 747 x-coordinate of the shared secret value (an elliptic curve 748 point). DHSharedSecret is the output of operation ECSVDP-DH as 749 described in Section 7.2.1 of [IEEE1363]. 751 DHSharedSecret is first padded with leading zeros such that the 752 size of DHSharedSecret in octets is the same as that of the 753 modulus, then represented as a string of octets in big-endian 754 order. 756 Implementation note: Both the client and the KDC can cache the 757 triple (ya, yb, DHSharedSecret), where ya is the client's public 758 key and yb is the KDC's public key. If both ya and yb are the 759 same in a later exchange, the cached DHSharedSecret can be used. 761 2. Let K be the key-generation seed length [RFC3961] of the AS reply 762 key whose enctype is selected according to [CLAR]. 764 3. Define the function octetstring2key() as follows: 766 octetstring2key(x) == random-to-key(K-truncate( 767 SHA1(0x00 | x) | 768 SHA1(0x01 | x) | 769 SHA1(0x02 | x) | 770 ... 771 )) 773 where x is an octet string; | is the concatenation operator; 0x00, 774 0x01, 0x02, etc., are each represented as a single octet; random- 775 to-key() is an operation that generates a protocol key from a 776 bitstring of length K; and K-truncate truncates its input to the 777 first K bits. Both K and random-to-key() are as defined in the 778 kcrypto profile [RFC3961] for the enctype of the AS reply key. 780 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 781 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 782 strings. 784 5. The AS reply key k is: 786 k = octetstring2key(DHSharedSecret | n_c | n_k) 788 3.2.3.2 Using Public Key Encryption 790 In this case, the PA-PK-AS-REP contains a ContentInfo structure 791 wrapped in an OCTET STRING. The AS reply key is encrypted in the 792 encKeyPack field, which contains data of type ReplyKeyPack: 794 ReplyKeyPack ::= SEQUENCE { 795 replyKey [0] EncryptionKey, 796 -- Contains the session key used to encrypt the 797 -- enc-part field in the AS-REP. 798 nonce [1] INTEGER (0..4294967295), 799 -- Contains the nonce in the PKAuthenticator of the 800 -- request. 801 ... 802 } 804 The ContentInfo [RFC3852] structure for the encKeyPack field is 805 filled in as follows: 807 1. The contentType field of the type ContentInfo is id-envelopedData 808 (as defined in [RFC3852]), and the content field is an 809 EnvelopedData (as defined in [RFC3852]). 811 2. The contentType field for the type EnvelopedData is id- 812 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 813 pkcs (1) pkcs7 (7) signedData (2) }. 815 3. The eContentType field for the inner type SignedData (when 816 decrypted from the encryptedContent field for the type 817 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 818 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 820 4. The eContent field for the inner type SignedData contains the DER 821 encoding of the type ReplyKeyPack. 823 5. The signerInfos field of the inner type SignedData contains a 824 single signerInfo, which contains the signature over the type 825 ReplyKeyPack. 827 6. The certificates field of the inner type SignedData contains 828 certificates intended to facilitate certification path 829 construction, so that the client can verify the KDC's signature 830 over the type ReplyKeyPack. The information contained in the 831 trustedCertifiers in the request SHOULD be used by the KDC as 832 hints to guide its selection of an appropriate certificate chain 833 to return to the client. This field may only be left empty if 834 the KDC public key specified by the kdcPkId field in the PA-PK- 835 AS-REQ was used for signing. Otherwise, for path validation, 836 these certificates SHOULD be sufficient to construct at least one 837 certification path from the KDC certificate to one trust anchor 838 acceptable by the client [CAPATH]. The KDC MUST be capable of 839 including such a set of certificates if configured to do so. The 840 certificates field MUST NOT contain "root" CA certificates. 842 7. The recipientInfos field of the type EnvelopedData is a SET which 843 MUST contain exactly one member of type KeyTransRecipientInfo. 844 The encryptedKey of this member contains the temporary key which 845 is encrypted using the client's public key. 847 8. The unprotectedAttrs or originatorInfo fields of the type 848 EnvelopedData MAY be present. 850 3.2.4 Receipt of KDC Reply 852 Upon receipt of the KDC's reply, the client proceeds as follows. If 853 the PA-PK-AS-REP contains the dhSignedData field, the client derives 854 the AS reply key using the same procedure used by the KDC as defined 855 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 856 field, and the client decrypts and extracts the temporary key in the 857 encryptedKey field of the member KeyTransRecipientInfo, and then uses 858 that as the AS reply key. 860 In either case, the client MUST verify the signature in the 861 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 862 be validated according to [RFC3280]. In addition, unless the client 863 can otherwise verify that the public key used to verify the KDC's 864 signature is bound to the KDC of the target realm, the KDC's X.509 865 certificate MUST contain a Subject Alternative Name extension 866 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as 867 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 868 matches the name of the TGS of the target realm (as defined in 869 Section 7.3 of [CLAR]). 871 Based on local policy, the client MAY require that the KDC 872 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: 874 id-pkkdcekuoid OBJECT IDENTIFIER ::= 875 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 876 pkinit(3) pkkdcekuoid(5) } 877 -- Signing KDC responses. 878 -- Key usage bits that MUST be consistent: 880 -- digitalSignature. 882 If all applicable checks are satisfied, the client then decrypts the 883 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 884 and then proceeds as described in [CLAR]. 886 Implementation note: CAs issuing KDC certificates SHOULD place all 887 "short" and "fully-qualified" Kerberos realm names of the KDC (one 888 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 889 flexibility. 891 3.3 Interoperability Requirements 893 The client MUST be capable of sending a set of certificates 894 sufficient to allow the KDC to construct a certification path for the 895 client's certificate, if the correct set of certificates is provided 896 through configuration or policy. 898 If the client sends all the X.509 certificates on a certification 899 path to a trust anchor acceptable by the KDC, and the KDC can not 900 verify the client's public key otherwise, the KDC MUST be able to 901 process path validation for the client's certificate based on the 902 certificates in the request. 904 The KDC MUST be capable of sending a set of certificates sufficient 905 to allow the client to construct a certification path for the KDC's 906 certificate, if the correct set of certificates is provided through 907 configuration or policy. 909 If the KDC sends all the X.509 certificates on a certification path 910 to a trust anchor acceptable by the client, and the client can not 911 verify the KDC's public key otherwise, the client MUST be able to 912 process path validation for the KDC's certificate based on the 913 certificates in the reply. 915 3.4 KDC Indication of PKINIT Support 917 If pre-authentication is required, but was not present in the 918 request, per [CLAR] an error message with the code 919 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 920 stored in the e-data field of the KRB-ERROR message to specify which 921 pre-authentication mechanisms are acceptable. The KDC can then 922 indicate the support of PKINIT by including an empty element whose 923 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 925 Otherwise if it is required by the KDC's local policy that the client 926 must be pre-authenticated using the pre-authentication mechanism 927 specified in this document, but no PKINIT pre-authentication was 928 present in the request, an error message with the code 929 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 931 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 932 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 933 STRING), and clients MUST ignore this and any other value. Future 934 extensions to this protocol may specify other data to send instead of 935 an empty OCTET STRING. 937 4. Security Considerations 939 PKINIT raises certain security considerations beyond those that can 940 be regulated strictly in protocol definitions. We will address them 941 in this section. 943 PKINIT extends the cross-realm model to the public-key 944 infrastructure. Users of PKINIT must understand security policies 945 and procedures appropriate to the use of Public Key Infrastructures 946 [RFC3280]. 948 Standard Kerberos allows the possibility of interactions between 949 cryptosystems of varying strengths; this document adds interactions 950 with public-key cryptosystems to Kerberos. Some administrative 951 policies may allow the use of relatively weak public keys. Using 952 such keys to wrap data encrypted under stronger conventional 953 cryptosystems may be inappropriate. 955 PKINIT requires keys for symmetric cryptosystems to be generated. 956 Some such systems contain "weak" keys. For recommendations regarding 957 these weak keys, see [CLAR]. 959 PKINIT allows the use of the same RSA key pair for encryption and 960 signing when doing RSA encryption based key delivery. This is not 961 recommended usage of RSA keys [RFC3447], by using DH based key 962 delivery this is avoided. 964 Care should be taken in how certificates are chosen for the purposes 965 of authentication using PKINIT. Some local policies may require that 966 key escrow be used for certain certificate types. Deployers of 967 PKINIT should be aware of the implications of using certificates that 968 have escrowed keys for the purposes of authentication. Because 969 signing only certificates are normally not escrowed, by using DH 970 based key delivery this is avoided. 972 PKINIT does not provide for a "return routability" test to prevent 973 attackers from mounting a denial-of-service attack on the KDC by 974 causing it to perform unnecessary and expensive public-key 975 operations. Strictly speaking, this is also true of standard 976 Kerberos, although the potential cost is not as great, because 977 standard Kerberos does not make use of public-key cryptography. By 978 using DH based key delivery and reusing DH keys, the necessary crypto 979 processing cost per request can be minimized. 981 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 982 permit empty SEQUENCEs to be encoded. Such empty sequences may only 983 be used if the KDC itself vouches for the user's certificate. 985 5. Acknowledgements 987 The following people have made significant contributions to this 988 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist 989 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 990 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik 991 Jaganathan, Chaskiel M Grundman and Stefan Santesson. 993 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 994 Jonathan Trostle who wrote earlier versions of this document. 996 The authors are indebted to the Kerberos working group chair Jeffrey 997 Hutzelman who kept track of various issues and was enormously helpful 998 during the creation of this document. 1000 Some of the ideas on which this document is based arose during 1001 discussions over several years between members of the SAAG, the IETF 1002 CAT working group, and the PSRG, regarding integration of Kerberos 1003 and SPX. Some ideas have also been drawn from the DASS system. 1004 These changes are by no means endorsed by these groups. This is an 1005 attempt to revive some of the goals of those groups, and this 1006 document approaches those goals primarily from the Kerberos 1007 perspective. 1009 Lastly, comments from groups working on similar ideas in DCE have 1010 been invaluable. 1012 6. IANA Considerations 1014 This document has no actions for IANA. 1016 7. References 1018 7.1 Normative References 1020 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- 1021 krb-wg-kerberos-clarifications. Work in Progress. 1023 [IEEE1363] 1024 IEEE, "Standard Specifications for Public Key 1025 Cryptography", IEEE 1363, 2000. 1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Levels", BCP 14, RFC 2119, March 1997. 1030 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1031 RFC 2412, November 1998. 1033 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1034 RFC 2631, June 1999. 1036 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1037 Identifiers for the Internet X.509 Public Key 1038 Infrastructure Certificate and Certificate Revocation List 1039 (CRL) Profile", RFC 3279, April 2002. 1041 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1042 X.509 Public Key Infrastructure Certificate and 1043 Certificate Revocation List (CRL) Profile", RFC 3280, 1044 April 2002. 1046 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1047 Algorithms", RFC 3370, August 2002. 1049 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1050 Standards (PKCS) #1: RSA Cryptography Specifications 1051 Version 2.1", RFC 3447, February 2003. 1053 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1054 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1055 RFC 3526, May 2003. 1057 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1058 Encryption Algorithm in Cryptographic Message Syntax 1059 (CMS)", RFC 3565, July 2003. 1061 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1062 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1063 RFC 3766, April 2004. 1065 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1066 RFC 3852, July 2004. 1068 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1069 Kerberos 5", RFC 3961, February 2005. 1071 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1072 Encryption for Kerberos 5", RFC 3962, February 2005. 1074 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication 1075 Framework. 1997. 1077 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1078 Rules (BER), Canonical Encoding Rules (CER) and 1079 Distinguished Encoding Rules (DER), ITU-T Recommendation 1080 X.690 (1997) | ISO/IEC International Standard 1081 8825-1:1998. 1083 7.2 Informative References 1085 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1086 pkix-certpathbuild. Work in Progress. 1088 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1089 Sizes", Journal of Cryptology 14 (2001) 255-293. 1091 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1092 future, Designs, Codes, and Cryptography (1999)". 1094 Authors' Addresses 1096 Brian Tung 1097 USC Information Sciences Institute 1098 4676 Admiralty Way Suite 1001, Marina del Rey CA 1099 Marina del Rey, CA 90292 1100 US 1102 Email: brian@isi.edu 1104 Larry Zhu 1105 Microsoft Corporation 1106 One Microsoft Way 1107 Redmond, WA 98052 1108 US 1110 Email: lzhu@microsoft.com 1112 Appendix A. PKINIT ASN.1 Module 1113 KerberosV5-PK-INIT-SPEC { 1114 iso(1) identified-organization(3) dod(6) internet(1) 1115 security(5) kerberosV5(2) modules(4) pkinit(5) 1116 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1118 IMPORTS 1119 SubjectPublicKeyInfo, AlgorithmIdentifier 1120 FROM PKIX1Explicit88 { iso (1) 1121 identified-organization (3) dod (6) internet (1) 1122 security (5) mechanisms (5) pkix (7) id-mod (0) 1123 id-pkix1-explicit (18) } 1124 -- As defined in RFC 3280. 1126 DomainParameters, EcpkParameters 1127 FROM PKIX1Algorithms88 { iso(1) 1128 identified-organization(3) dod(6) 1129 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1130 id-mod-pkix1-algorithms(17) } 1131 -- As defined in RFC 3279. 1133 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey 1134 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1135 dod(6) internet(1) security(5) kerberosV5(2) 1136 modules(4) krb5spec2(2) } ; 1138 id-pkinit OBJECT IDENTIFIER ::= 1139 { iso (1) org (3) dod (6) internet (1) security (5) 1140 kerberosv5 (2) pkinit (3) } 1142 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1143 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1144 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1145 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1146 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1148 pa-pk-as-req INTEGER ::= 16 1149 pa-pk-as-rep INTEGER ::= 17 1151 ad-initial-verified-cas INTEGER ::= 9 1153 td-trusted-certifiers INTEGER ::= 104 1154 td-invalid-certificates INTEGER ::= 105 1155 td-dh-parameters INTEGER ::= 109 1157 PA-PK-AS-REQ ::= SEQUENCE { 1158 signedAuthPack [0] IMPLICIT OCTET STRING, 1159 -- Contains a CMS type ContentInfo encoded 1160 -- according to [RFC3852]. 1162 -- The contentType field of the type ContentInfo 1163 -- is id-signedData (1.2.840.113549.1.7.2), 1164 -- and the content field is a SignedData. 1165 -- The eContentType field for the type SignedData is 1166 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1167 -- eContent field contains the DER encoding of the 1168 -- type AuthPack. 1169 -- AuthPack is defined below. 1170 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 1171 -- A list of CAs, trusted by the client, that can 1172 -- be used to certify the KDC. 1173 -- Each TrustedCA identifies a CA or a CA 1174 -- certificate (thereby its public key). 1175 -- The information contained in the 1176 -- trustedCertifiers SHOULD be used by the KDC as 1177 -- hints to guide its selection of an appropriate 1178 -- certificate chain to return to the client. 1179 kdcPkId [2] IMPLICIT OCTET STRING 1180 OPTIONAL, 1181 -- Contains a CMS type SignerIdentifier encoded 1182 -- according to [RFC3852]. 1183 -- Identifies, if present, a particular KDC 1184 -- public key that the client already has. 1185 ... 1186 } 1188 DHNonce ::= OCTET STRING 1190 TrustedCA ::= SEQUENCE { 1191 caName [0] IMPLICIT OCTET STRING, 1192 -- Contains a PKIX type Name encoded according to 1193 -- [RFC3280]. 1194 -- Identifies a CA by the CA's distinguished subject 1195 -- name. 1196 certificateSerialNumber [1] INTEGER OPTIONAL, 1197 -- Specifies the CA certificate's serial number. 1198 -- The defintion of the certificate serial number 1199 -- is taken from X.509 [X.509-97]. 1200 subjectKeyIdentifier [2] OCTET STRING OPTIONAL, 1201 -- Identifies the CA's public key by a key 1202 -- identifier. When an X.509 certificate is 1203 -- referenced, this key identifier matches the X.509 1204 -- subjectKeyIdentifier extension value. When other 1205 -- certificate formats are referenced, the documents 1206 -- that specify the certificate format and their use 1207 -- with the CMS must include details on matching the 1208 -- key identifier to the appropriate certificate 1209 -- field. 1211 ... 1212 } 1214 AuthPack ::= SEQUENCE { 1215 pkAuthenticator [0] PKAuthenticator, 1216 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1217 -- Type SubjectPublicKeyInfo is defined in 1218 -- [RFC3280]. 1219 -- Specifies Diffie-Hellman domain parameters 1220 -- and the client's public key value [IEEE1363]. 1221 -- The DH public key value is encoded as a BIT 1222 -- STRING, as specified in Section 2.3.3 of 1223 -- [RFC3279]. 1224 -- This field is present only if the client wishes 1225 -- to use the Diffie-Hellman key agreement method. 1226 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1227 OPTIONAL, 1228 -- Type AlgorithmIdentifier is defined in 1229 -- [RFC3280]. 1230 -- List of CMS encryption types supported by the 1231 -- client in order of (decreasing) preference. 1232 clientDHNonce [3] DHNonce OPTIONAL, 1233 -- Present only if the client indicates that it 1234 -- wishes to reuse DH keys or to allow the KDC to 1235 -- do so. 1236 ... 1237 } 1239 PKAuthenticator ::= SEQUENCE { 1240 cusec [0] INTEGER (0..999999), 1241 ctime [1] KerberosTime, 1242 -- cusec and ctime are used as in [CLAR], for replay 1243 -- prevention. 1244 nonce [2] INTEGER (0..4294967295), 1245 -- Chosen randomly; This nonce does not need to 1246 -- match with the nonce in the KDC-REQ-BODY. 1247 paChecksum [3] OCTET STRING, 1248 -- Contains the SHA1 checksum, performed over 1249 -- KDC-REQ-BODY. 1250 ... 1251 } 1253 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA 1254 -- Identifies a list of CAs trusted by the KDC. 1255 -- Each TrustedCA identifies a CA or a CA 1256 -- certificate (thereby its public key). 1258 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING 1259 -- Each OCTET STRING contains a CMS type 1260 -- IssuerAndSerialNumber encoded according to 1261 -- [RFC3852]. 1262 -- Each IssuerAndSerialNumber identifies a 1263 -- certificate (sent by the client) with an invalid 1264 -- signature. 1266 KRB5PrincipalName ::= SEQUENCE { 1267 realm [0] Realm, 1268 principalName [1] PrincipalName 1269 } 1271 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA 1272 -- Identifies the certification path based on which 1273 -- the client certificate was validated. 1274 -- Each TrustedCA identifies a CA or a CA 1275 -- certificate (thereby its public key). 1277 PA-PK-AS-REP ::= CHOICE { 1278 dhInfo [0] DHRepInfo, 1279 -- Selected when Diffie-Hellman key exchange is 1280 -- used. 1281 encKeyPack [1] IMPLICIT OCTET STRING, 1282 -- Selected when public key encryption is used. 1283 -- Contains a CMS type ContentInfo encoded 1284 -- according to [RFC3852]. 1285 -- The contentType field of the type ContentInfo is 1286 -- id-envelopedData (1.2.840.113549.1.7.3). 1287 -- The content field is an EnvelopedData. 1288 -- The contentType field for the type EnvelopedData 1289 -- is id-signedData (1.2.840.113549.1.7.2). 1290 -- The eContentType field for the inner type 1291 -- SignedData (when unencrypted) is id-pkrkeydata 1292 -- (1.2.840.113549.1.7.3) and the eContent field 1293 -- contains the DER encoding of the type 1294 -- ReplyKeyPack. 1295 -- ReplyKeyPack is defined below. 1296 ... 1297 } 1299 DHRepInfo ::= SEQUENCE { 1300 dhSignedData [0] IMPLICIT OCTET STRING, 1301 -- Contains a CMS type ContentInfo encoded according 1302 -- to [RFC3852]. 1303 -- The contentType field of the type ContentInfo is 1304 -- id-signedData (1.2.840.113549.1.7.2), and the 1305 -- content field is a SignedData. 1307 -- The eContentType field for the type SignedData is 1308 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1309 -- eContent field contains the DER encoding of the 1310 -- type KDCDHKeyInfo. 1311 -- KDCDHKeyInfo is defined below. 1312 serverDHNonce [1] DHNonce OPTIONAL 1313 -- Present if and only if dhKeyExpiration is 1314 -- present. 1315 } 1317 KDCDHKeyInfo ::= SEQUENCE { 1318 subjectPublicKey [0] BIT STRING, 1319 -- KDC's DH public key. 1320 -- The DH public key value is encoded as a BIT 1321 -- STRING, as specified in Section 2.3.3 of 1322 -- [RFC3279]. 1323 nonce [1] INTEGER (0..4294967295), 1324 -- Contains the nonce in the PKAuthenticator of the 1325 -- request if DH keys are NOT reused, 1326 -- 0 otherwise. 1327 dhKeyExpiration [2] KerberosTime OPTIONAL, 1328 -- Expiration time for KDC's key pair, 1329 -- present if and only if DH keys are reused. If 1330 -- this field is omitted then the serverDHNonce 1331 -- field MUST also be omitted. 1332 ... 1333 } 1335 ReplyKeyPack ::= SEQUENCE { 1336 replyKey [0] EncryptionKey, 1337 -- Contains the session key used to encrypt the 1338 -- enc-part field in the AS-REP. 1339 nonce [1] INTEGER (0..4294967295), 1340 -- Contains the nonce in the PKAuthenticator of the 1341 -- request. 1342 ... 1343 } 1345 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1346 -- Each AlgorithmIdentifier specifies a set of 1347 -- Diffie-Hellman domain parameters [IEEE1363]. 1348 -- This list is in decreasing preference order. 1349 END 1351 Intellectual Property Statement 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org. 1375 Disclaimer of Validity 1377 This document and the information contained herein are provided on an 1378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1382 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1385 Copyright Statement 1387 Copyright (C) The Internet Society (2005). This document is subject 1388 to the rights, licenses and restrictions contained in BCP 78, and 1389 except as set forth therein, the authors retain all their rights. 1391 Acknowledgment 1393 Funding for the RFC Editor function is currently provided by the 1394 Internet Society.