idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-24.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1374. ** 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: ---------------------------------------------------------------------------- == 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 (February 9, 2005) is 7016 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 1344 -- Looks like a reference, but probably isn't: '1' on line 1346 -- Looks like a reference, but probably isn't: '2' on line 1321 -- Looks like a reference, but probably isn't: '3' on line 1244 -- 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: 10 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP B. Tung 2 Internet-Draft USC Information Sciences Institute 3 Expires: August 13, 2005 L. Zhu 4 Microsoft Corporation 5 February 9, 2005 7 Public Key Cryptography for Initial Authentication in Kerberos 8 draft-ietf-cat-kerberos-pk-init-24 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 13, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes protocol extensions (hereafter called PKINIT) 44 to the Kerberos protocol specification. These extensions provide a 45 method for integrating public key cryptography into the initial 46 authentication exchange, by using asymmetric-key signature and/or 47 encryption algorithms in pre-authentication data fields. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 55 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 56 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 57 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 58 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6 59 3.2.1 Generation of Client Request . . . . . . . . . . . . . 6 60 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10 61 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13 62 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 63 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 64 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23 70 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 72 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 73 Intellectual Property and Copyright Statements . . . . . . . . 30 75 1. Introduction 77 A client typically authenticates itself to a service in Kerberos 78 using three distinct though related exchanges. First, the client 79 requests a ticket-granting ticket (TGT) from the Kerberos 80 authentication server (AS). Then, it uses the TGT to request a 81 service ticket from the Kerberos ticket-granting server (TGS). 82 Usually, the AS and TGS are integrated in a single device known as a 83 Kerberos Key Distribution Center, or KDC. (In this document, both 84 the AS and the TGS are referred to as the KDC.) Finally, the client 85 uses the service ticket to authenticate itself to the service. 87 The advantage afforded by the TGT is that the client exposes his 88 long-term secrets only once. The TGT and its associated session key 89 can then be used for any subsequent service ticket requests. One 90 result of this is that all further authentication is independent of 91 the method by which the initial authentication was performed. 92 Consequently, initial authentication provides a convenient place to 93 integrate public-key cryptography into Kerberos authentication. 95 As defined in [CLAR], Kerberos authentication exchanges use 96 symmetric-key cryptography, in part for performance. One 97 disadvantage of using symmetric-key cryptography is that the keys 98 must be shared, so that before a client can authenticate itself, he 99 must already be registered with the KDC. 101 Conversely, public-key cryptography (in conjunction with an 102 established Public Key Infrastructure) permits authentication without 103 prior registration with a KDC. Adding it to Kerberos allows the 104 widespread use of Kerberized applications by clients without 105 requiring them to register first with a KDC--a requirement that has 106 no inherent security benefit. 108 As noted above, a convenient and efficient place to introduce 109 public-key cryptography into Kerberos is in the initial 110 authentication exchange. This document describes the methods and 111 data formats for integrating public-key cryptography into Kerberos 112 initial authentication. 114 2. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 In this document, the encryption key used to encrypt the enc-part 121 field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC 122 AS reply key. 124 3. Extensions 126 This section describes extensions to [CLAR] for supporting the use of 127 public-key cryptography in the initial request for a ticket. 129 Briefly, this document defines the following extensions to [CLAR]: 131 1. The client indicates the use of public-key authentication by 132 including a special preauthenticator in the initial request. This 133 preauthenticator contains the client's public-key data and a 134 signature. 136 2. The KDC tests the client's request against its authentication 137 policy and trusted Certification Authorities (CAs). 139 3. If the request passes the verification tests, the KDC replies as 140 usual, but the reply is encrypted using either: 142 a. a key generated through a Diffie-Hellman (DH) key exchange 143 [RFC2631][IEEE1363] with the client, signed using the KDC's 144 signature key; or 146 b. a symmetric encryption key, signed using the KDC's signature 147 key and encrypted using the client's public key. 149 Any keying material required by the client to obtain the 150 encryption key for decrypting the KDC reply is returned in a 151 pre-authentication field accompanying the usual reply. 153 4. The client validates the KDC's signature, obtains the encryption 154 key, decrypts the reply, and then proceeds as usual. 156 Section 3.1 of this document enumerates the required algorithms and 157 necessary extension message types. Section 3.2 describes the 158 extension messages in greater detail. 160 3.1 Definitions, Requirements, and Constants 162 3.1.1 Required Algorithms 164 All PKINIT implementations MUST support the following algorithms: 166 o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. 168 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 170 o KDC AS reply key delivery method: Diffie-Hellman key exchange 171 [RFC2631]. 173 3.1.2 Defined Message and Encryption Types 175 PKINIT makes use of the following new pre-authentication types: 177 PA_PK_AS_REQ 16 178 PA_PK_AS_REP 17 180 PKINIT also makes use of the following new authorization data type: 182 AD_INITIAL_VERIFIED_CAS 9 184 PKINIT introduces the following new error codes: 186 KDC_ERR_CLIENT_NOT_TRUSTED 62 187 KDC_ERR_INVALID_SIG 64 188 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 189 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 190 KDC_ERR_INVALID_CERTIFICATE 71 191 KDC_ERR_REVOKED_CERTIFICATE 72 192 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 193 KDC_ERR_CLIENT_NAME_MISMATCH 75 194 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 196 PKINIT uses the following typed data types for errors: 198 TD_TRUSTED_CERTIFIERS 104 199 TD_INVLID_CERTIFICATES 105 200 TD_DH_PARAMETERS 109 202 PKINIT defines the following encryption types, for use in the AS-REQ 203 message to indicate acceptance of the corresponding algorithms that 204 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in 205 the reply: 207 dsaWithSHA1-CmsOID 9 208 md5WithRSAEncryption-CmsOID 10 209 sha1WithRSAEncryption-CmsOID 11 210 rc2CBC-EnvOID 12 211 rsaEncryption-EnvOID (PKCS1 v1.5) 13 212 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 213 des-ede3-cbc-EnvOID 15 215 The ASN.1 module for all structures defined in this document (plus 216 IMPORT statements for all imported structures) is given in 217 Appendix A. 219 All structures defined in or imported into this document MUST be 220 encoded using Distinguished Encoding Rules (DER) [X690] (unless 221 otherwise noted). All data structures carried in OCTET STRINGs must 222 be encoded according to the rules specified in corresponding 223 specifications. 225 Interoperability note: Some implementations may not be able to decode 226 wrapped CMS objects encoded with BER but not DER; specifically, they 227 may not be able to decode infinite length encodings. To maximize 228 interoperability, implementers SHOULD encode CMS objects used in 229 PKINIT with DER. 231 3.1.3 Algorithm Identifiers 233 PKINIT does not define, but does make use of, the following algorithm 234 identifiers. 236 PKINIT uses the following algorithm identifiers for Diffie-Hellman 237 key agreement [RFC3279]: 239 dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631]) 240 id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363]) 242 PKINIT uses the following signature algorithm identifiers [RFC3279]: 244 sha-1WithRSAEncryption (RSA with SHA1) 245 md5WithRSAEncryption (RSA with MD5) 246 id-dsa-with-sha1 (DSA with SHA1) 248 PKINIT uses the following encryption algorithm identifiers [RFC3447] 249 for encrypting the temporary key with a public key: 251 rsaEncryption (PKCS1 v1.5) 252 id-RSAES-OAEP (PKCS1 v2.0) 254 PKINIT uses the following algorithm identifiers [RFC3370][RFC3565] 255 for encrypting the KDC AS reply key with the temporary key: 257 des-ede3-cbc (three-key 3DES, CBC mode) 258 rc2-cbc (RC2, CBC mode) 259 id-aes256-CBC (AES-256, CBC mode) 261 3.2 PKINIT Pre-authentication Syntax and Use 263 This section defines the syntax and use of the various 264 pre-authentication fields employed by PKINIT. 266 3.2.1 Generation of Client Request 268 The initial authentication request (AS-REQ) is sent as per [CLAR]; in 269 addition, a pre-authentication data element, whose padata-type is 270 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 271 type PA-PK-AS-REQ, is included. 273 PA-PK-AS-REQ ::= SEQUENCE { 274 signedAuthPack [0] IMPLICIT OCTET STRING, 275 -- Contains a CMS type ContentInfo encoded 276 -- according to [RFC3852]. 277 -- The contentType field of the type ContentInfo 278 -- is id-signedData (1.2.840.113549.1.7.2), 279 -- and the content field is a SignedData. 280 -- The eContentType field for the type SignedData is 281 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 282 -- eContent field contains the DER encoding of the 283 -- type AuthPack. 284 -- AuthPack is defined below. 285 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 286 -- A list of CAs, trusted by the client, that can 287 -- be used as the trust anchor to validate the KDC's 288 -- signature. 289 -- Each TrustedCA identifies a CA or a CA 290 -- certificate (thereby its public key). 291 kdcPkId [2] IMPLICIT OCTET STRING 292 OPTIONAL, 293 -- Contains a CMS type SignerIdentifier encoded 294 -- according to [RFC3852]. 295 -- Identifies, if present, a particular KDC 296 -- public key that the client already has. 297 ... 298 } 300 DHNonce ::= OCTET STRING 302 TrustedCA ::= SEQUENCE { 303 caName [0] IMPLICIT OCTET STRING, 304 -- Contains a PKIX type Name encoded according to 305 -- [RFC3280]. 306 -- Specifies the CA distinguished subject name. 307 certificateSerialNumber [1] INTEGER OPTIONAL, 308 -- Specifies the certificate serial number. 309 -- The defintion of the certificate serial number 310 -- is taken from X.509 [X.509-97]. 311 subjectKeyIdentifier [2] OCTET STRING OPTIONAL, 312 -- Identifies the CA's public key by a key 313 -- identifier. When an X.509 certificate is 314 -- referenced, this key identifier matches the X.509 315 -- subjectKeyIdentifier extension value. When other 316 -- certificate formats are referenced, the documents 317 -- that specify the certificate format and their use 318 -- with the CMS must include details on matching the 319 -- key identifier to the appropriate certificate 320 -- field. 321 ... 322 } 324 AuthPack ::= SEQUENCE { 325 pkAuthenticator [0] PKAuthenticator, 326 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 327 -- Defined in [RFC3280]. 328 -- The pubic key value (the subjectPublicKey field 329 -- of the type SubjectPublicKeyInfo) MUST be encoded 330 -- according to [RFC3279]. 331 -- Present only if the client wishes to use the 332 -- Diffie-Hellman key agreement method. 333 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 334 OPTIONAL, 335 -- List of CMS encryption types supported by 336 -- client in order of (decreasing) preference. 337 clientDHNonce [3] DHNonce OPTIONAL, 338 -- Present only if the client indicates that it 339 -- wishes to reuse DH keys or to allow the KDC to 340 -- do so (see Section 3.2.3.1). 341 ... 342 } 344 PKAuthenticator ::= SEQUENCE { 345 cusec [0] INTEGER (0..999999), 346 ctime [1] KerberosTime, 347 -- cusec and ctime are used as in [CLAR], for replay 348 -- prevention. 349 nonce [2] INTEGER (0..4294967295), 350 -- Chosen randomly; This nonce does not need to 351 -- match with the nonce in the KDC-REQ-BODY. 352 paChecksum [3] OCTET STRING, 353 -- Contains the SHA1 checksum, performed over 354 -- KDC-REQ-BODY. 355 ... 356 } 358 The ContentInfo [RFC3852] structure for the signedAuthPack field is 359 filled out as follows: 361 1. The contentType field of the type ContentInfo is id-signedData 362 (as defined in [RFC3852]), and the content field is a SignedData 363 (as defined in [RFC3852]). 365 2. The eContentType field for the type SignedData is id-pkauthdata: 366 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 367 pkinit(3) pkauthdata(1) }. 369 3. The eContent field for the type SignedData contains the DER 370 encoding of the type AuthPack. 372 4. The signerInfos field of the type SignedData contains a single 373 signerInfo, which contains the signature over the type AuthPack. 375 5. The certificates field of the type SignedData contains 376 certificates intended to facilitate certification path 377 construction, so that the KDC can verify the signature over the 378 type AuthPack. For path validation, these certificates SHOULD be 379 sufficient to construct at least one certification path from the 380 client certificate to one trust anchor acceptable by the KDC 381 [CAPATH]. The certificates field MUST NOT contain "root" CA 382 certificates. 384 6. The client's Diffie-Hellman public value (clientPublicValue) is 385 included if and only if the client wishes to use the 386 Diffie-Hellman key agreement method. For the Diffie-Hellman key 387 agreement method, implementations MUST support Oakley 1024-bit 388 MODP well-known group 2 [RFC2412] and SHOULD support Oakley 389 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP 390 well-known group 16 [RFC3526]. 392 The Diffie-Hellman field size should be chosen so as to provide 393 sufficient cryptographic security. The following table, based on 394 [LENSTRA], gives approximate comparable key sizes for symmetric- 395 and asymmetric-key cryptosystems based on the best-known 396 algorithms for attacking them. 398 Symmetric | ECC | DH/DSA/RSA 399 -------------+---------+------------ 400 80 | 163 | 1024 401 112 | 233 | 2048 402 128 | 283 | 3072 403 192 | 409 | 7680 404 256 | 571 | 15360 406 Table 1: Comparable key sizes (in bits) 408 When Diffie-Hellma modulo a prime p is used, the exponents should 409 have at least twice as many bits as the symmetric keys that will 410 be derived from them [ODL99]. 412 7. The client may wish to reuse DH keys or to allow the KDC to do so 413 (see Section 3.2.3.1). If so, then the client includes the 414 clientDHNonce field. This nonce string needs to be as long as 415 the longest key length of the symmetric key types that the client 416 supports. This nonce MUST be chosen randomly. 418 3.2.2 Receipt of Client Request 420 Upon receiving the client's request, the KDC validates it. This 421 section describes the steps that the KDC MUST (unless otherwise 422 noted) take in validating the request. 424 The KDC verifies the client's signature in the signedAuthPack field 425 according to [RFC3852]. 427 If, while validating the client's X.509 certificate [RFC3280], the 428 KDC cannot build a certification path to validate the client's 429 certificate, it sends back a KRB-ERROR [CLAR] message with the code 430 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this 431 error message is a TYPED-DATA (as defined in [CLAR]) that contains an 432 element whose data-type is TD_TRUSTED_CERTIFIERS, and whose 433 data-value contains the DER encoding of the type 434 TD-TRUSTED-CERTIFIERS: 436 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA 437 -- Identifies a list of CAs trusted by the KDC. 438 -- Each TrustedCA identifies a CA or a CA 439 -- certificate (thereby its public key). 441 Upon receiving this error message, the client SHOULD retry only if it 442 has a different set of certificates (from those of the previous 443 requests) that form a certification path (or a partial path) from one 444 of the trust anchors selected by the KDC to its own certificate. 446 If, while processing the certification path, the KDC determines that 447 the signature on one of the certificates in the signedAuthPack field 448 is invalid, it returns a KRB-ERROR [CLAR] message with the code 449 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 450 message is a TYPED-DATA that contains an element whose data-type is 451 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 452 encoding of the type TD-INVALID-CERTIFICATES: 454 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING 455 -- Each OCTET STRING contains a CMS type 456 -- IssuerAndSerialNumber encoded according to 457 -- [RFC3852]. 458 -- Each IssuerAndSerialNumber indentifies a 459 -- certificate (sent by the client) with an invalid 460 -- signature. 462 If more than one X.509 certificate signature is invalid, the KDC MAY 463 send one TYPED-DATA element per invalid signature. 465 Based on local policy, the KDC may also check whether any X.509 466 certificates in the certification path validating the client's 467 certificate have been revoked. If any of them have been revoked, the 468 KDC MUST return an error message with the code 469 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 470 revocation status but is unable to do so, it SHOULD return an error 471 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 472 certificate or certificates affected are identified exactly as for 473 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 475 The client's public key is then used to verify the signature. If the 476 signature fails to verify, the KDC MUST return an error message with 477 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 478 this error message. 480 In addition to validating the client's signature, the KDC MUST also 481 check that the client's public key used to verify the client's 482 signature is bound to the client's principal name as specified in the 483 AS-REQ as follows: 485 1. If the KDC has its own binding between either the client's 486 signature-verification public key or the client's certificate and 487 the client's Kerberos principal name, it uses that binding. 489 2. Otherwise, if the client's X.509 certificate contains a 490 SubjectAltName extension with a KRB5PrincipalName (defined below) 491 in the otherName field, it binds the client's X.509 certificate to 492 that name. 494 The otherName field (of type AnotherName) in the SubjectAltName 495 extension MUST contain KRB5PrincipalName as defined below. 497 The type-id field of the type AnotherName is id-pksan: 499 id-pksan OBJECT IDENTIFIER ::= 500 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 501 x509-sanan (2) } 503 The value field of the type AnotherName is the DER encoding of the 504 following ASN.1 type: 506 KRB5PrincipalName ::= SEQUENCE { 507 realm [0] Realm, 508 principalName [1] PrincipalName 509 } 511 If the KDC does not have its own binding and there is no 512 KRB5PrincipalName name present in the client's X.509 certificate, and 513 if the Kerberos name in the request does not match the 514 KRB5PrincipalName in the client's X.509 certificate (including the 515 realm name), the KDC MUST return an error message with the code 516 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 517 this error message. 519 The KDC MAY require the presence of an Extended Key Usage (EKU) 520 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the 521 client's X.509 certificate: 523 id-pkekuoid OBJECT IDENTIFIER ::= 524 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 525 pkinit(3) pkekuoid(4) } 526 -- PKINIT client authentication. 527 -- Key usage bits that MUST be consistent: 528 -- digitalSignature; 529 -- Key usage bits that MAY be consistent: 530 -- nonRepudiation, and (keyEncipherment or keyAgreement). 532 If this EKU is required but is missing, the KDC MUST return an error 533 message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no 534 accompanying e-data for this error message. KDCs implementing this 535 requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon 536 (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a 537 large number of X.509 client certificates deployed for use with 538 PKINIT which have this EKU. 540 If for any other reasons, the client's public key is not accepted, 541 the KDC MUST return an error message with the code 542 KDC_ERR_CLIENT_NOT_TRUSTED. 544 The KDC MUST check the timestamp to ensure that the request is not a 545 replay, and that the time skew falls within acceptable limits. The 546 recommendations for clock skew times in [CLAR] apply here. If the 547 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 548 KRB_AP_ERR_SKEW, respectively. 550 If the clientPublicValue is filled in, indicating that the client 551 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 552 check to see if the key parameters satisfy its policy. If they do 553 not, it MUST return an error message with the code 554 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 555 TYPED-DATA that contains an element whose data-type is 556 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 557 the type TD-DH-PARAMETERS: 559 TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters 560 -- Contains a list of Diffie-Hellman domain 561 -- parameters in decreasing preference order. 563 DHDomainParameters ::= CHOICE { 564 modp [0] DomainParameters, 565 -- Type DomainParameters is defined in [RFC3279]. 566 ec [1] EcpkParameters, 567 -- Type EcpkParameters is defined in [RFC3279]. 568 ... 569 } 571 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 572 that the KDC supports in decreasing preference order, from which the 573 client SHOULD pick one to retry the request. 575 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 576 KDC does not possess the corresponding key, the KDC MUST ignore the 577 kdcPkId field as if the client did not include one. 579 If the client included a trustedCertifiers field, and the KDC does 580 not possesses the private key for any one of the listed certifiers, 581 the KDC MUST ignore the trustedCertifiers field as if the client did 582 not include any. 584 If there is a supportedCMSTypes field in the AuthPack, the KDC must 585 check to see if it supports any of the listed types. If it supports 586 more than one of the types, the KDC SHOULD use the one listed first. 587 If it does not support any of them, it MUST return an error message 588 with the code KDC_ERR_ETYPE_NOSUPP [CLAR]. 590 3.2.3 Generation of KDC Reply 592 Assuming that the client's request has been properly validated, the 593 KDC proceeds as per [CLAR], except as follows. 595 The KDC MUST set the initial flag and include an authorization data 596 element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued 597 ticket. The ad-data [CLAR] field contains the DER encoding of the 598 type AD-INITIAL-VERIFIED-CAS: 600 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA 601 -- Identifies the certification path based on which 602 -- the client certificate was validated. 603 -- Each TrustedCA identifies a CA or a CA 604 -- certificate (thereby its public key). 606 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 607 containers if the list of CAs satisfies the AS' realm's local policy 608 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 609 [CLAR]). Furthermore, any TGS MUST copy such authorization data from 610 tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting 611 ticket, and it can wrap or unwrap the data into or out-of the 612 AD-IF-RELEVANT container, depends on if the list of CAs satisfies the 613 TGS' realm's local policy. 615 Application servers that understand this authorization data type 616 SHOULD apply local policy to determine whether a given ticket bearing 617 such a type *not* contained within an AD-IF-RELEVANT container is 618 acceptable. (This corresponds to the AP server checking the 619 transited field when the TRANSITED-POLICY-CHECKED flag has not been 620 set [CLAR].) If such a data type is contained within an 621 AD-IF-RELEVANT container, AP servers MAY apply local policy to 622 determine whether the authorization data is acceptable. 624 The content of the AS-REP is otherwise unchanged from [CLAR]. The 625 KDC encrypts the reply as usual, but not with the client's long-term 626 key. Instead, it encrypts it with either a shared key derived from a 627 Diffie-Hellman exchange, or a generated encryption key. The contents 628 of the PA-PK-AS-REP indicate which key delivery method is used: 630 PA-PK-AS-REP ::= CHOICE { 631 dhInfo [0] DHRepInfo, 632 -- Selected when Diffie-Hellman key exchange is 633 -- used. 634 encKeyPack [1] IMPLICIT OCTET STRING, 635 -- Selected when public key encryption is used. 636 -- Contains a CMS type ContentInfo encoded 637 -- according to [RFC3852]. 638 -- The contentType field of the type ContentInfo is 639 -- id-envelopedData (1.2.840.113549.1.7.3). 640 -- The content field is an EnvelopedData. 641 -- The contentType field for the type EnvelopedData 642 -- is id-signedData (1.2.840.113549.1.7.2). 643 -- The eContentType field for the inner type 644 -- SignedData (when unencrypted) is id-pkrkeydata 645 -- (1.2.840.113549.1.7.3) and the eContent field 646 -- contains the DER encoding of the type 647 -- ReplyKeyPack. 649 -- ReplyKeyPack is defined in Section 3.2.3.2. 650 ... 651 } 653 DHRepInfo ::= SEQUENCE { 654 dhSignedData [0] IMPLICIT OCTET STRING, 655 -- Contains a CMS type ContentInfo encoded according 656 -- to [RFC3852]. 657 -- The contentType field of the type ContentInfo is 658 -- id-signedData (1.2.840.113549.1.7.2), and the 659 -- content field is a SignedData. 660 -- The eContentType field for the type SignedData is 661 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 662 -- eContent field contains the DER encoding of the 663 -- type KDCDHKeyInfo. 664 -- KDCDHKeyInfo is defined below. 665 serverDHNonce [1] DHNonce OPTIONAL 666 -- Present if and only if dhKeyExpiration is 667 -- present in the KDCDHKeyInfo. 668 } 670 KDCDHKeyInfo ::= SEQUENCE { 671 subjectPublicKey [0] BIT STRING, 672 -- KDC's DH public key. 673 -- The DH pubic key value is mapped to a BIT STRING 674 -- according to [RFC3279]. 675 nonce [1] INTEGER (0..4294967295), 676 -- Contains the nonce in the PKAuthenticator of the 677 -- request if DH keys are NOT reused, 678 -- 0 otherwise. 679 dhKeyExpiration [2] KerberosTime OPTIONAL, 680 -- Expiration time for KDC's key pair, 681 -- present if and only if DH keys are reused. If 682 -- this field is omitted then the serverDHNonce 683 -- field MUST also be omitted. See Section 3.2.3.1. 684 ... 685 } 687 3.2.3.1 Using Diffie-Hellman Key Exchange 689 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 691 The ContentInfo [RFC3852] structure for the dhSignedData field is 692 filled in as follows: 694 1. The contentType field of the type ContentInfo is id-signedData 695 (as defined in [RFC3852]), and the content field is a SignedData 696 (as defined in [RFC3852]). 698 2. The eContentType field for the type SignedData is the OID value 699 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 700 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 702 3. The eContent field for the type SignedData contains the DER 703 encoding of the type KDCDHKeyInfo. 705 4. The signerInfos field of the type SignedData contains a single 706 signerInfo, which contains the signature over the type 707 KDCDHKeyInfo. 709 5. The certificates field of the type SignedData contains 710 certificates intended to facilitate certification path 711 construction, so that the client can verify the KDC's signature 712 over the type KDCDHKeyInfo. This field may only be left empty if 713 the KDC public key specified by the kdcPkId field in the 714 PA-PK-AS-REQ was used for signing. Otherwise, for path 715 validation, these certificates SHOULD be sufficient to construct 716 at least one certification path from the KDC certificate to one 717 trust anchor acceptable by the client [CAPATH]. The certificates 718 field MUST NOT contain "root" CA certificates. 720 6. If the client included the clientDHNonce field, then the KDC may 721 choose to reuse its DH keys (see Section 3.2.3.1). If the server 722 reuses DH keys then it MUST include an expiration time in the 723 dhKeyExperiation field. Past the point of the expiration time, 724 the signature over the type DHRepInfo is considered 725 expired/invalid. When the server reuses DH keys then it MUST 726 include a serverDHNonce at least as long as the length of keys 727 for the symmetric encryption system used to encrypt the AS reply. 728 Note that including the serverDHNonce changes how the client and 729 server calculate the key to use to encrypt the reply; see below 730 for details. The KDC SHOULD NOT reuse DH keys unless the 731 clientDHNonce field is present in the request. 733 The KDC AS reply key is derived as follows: 735 1. Both the KDC and the client calculate the shared secret value as 736 follows: 738 a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let 739 DHSharedSecret be the shared secret value. 741 b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party 742 contributing one key pair) [IEEE1363] is used, let 743 DHSharedSecret be the x-coordinate of the shared secret value 744 (an elliptic curve point). 746 DHSharedSecret is first padded with leading zeros such that the 747 size of DHSharedSecret in octets is the same as that of the 748 modulus, then represented as a string of octets in big-endian 749 order. 751 Implementation note: Both the client and the KDC can cache the 752 triple (ya, yb, DHSharedSecret), where ya is the client's public 753 key and yb is the KDC's public key. If both ya and yb are the 754 same in a later exchange, the cached DHSharedSecret can be used. 756 2. Let K be the key-generation seed length [KCRYPTO] of the KDC AS 757 reply key whose enctype is selected according to [CLAR]. 759 3. Define the function octetstring2key() as follows: 761 octetstring2key(x) == random-to-key(K-truncate( 762 SHA1(0x00 | x) | 763 SHA1(0x01 | x) | 764 SHA1(0x02 | x) | 765 ... 766 )) 768 where x is an octet string; | is the concatenation operator; 0x00, 769 0x01, 0x02, etc., are each represented as a single octet; 770 random-to-key() is an operation that generates a protocol key from 771 a bitstring of length K; and K-truncate truncates its input to the 772 first K bits. Both K and random-to-key() are as defined in the 773 kcrypto profile [KCRYPTO] for the enctype of the KDC AS reply key. 775 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 776 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 777 strings. 779 5. The KDC AS reply key k is: 781 k = octetstring2key(DHSharedSecret | n_c | n_k) 783 3.2.3.2 Using Public Key Encryption 785 In this case, the PA-PK-AS-REP contains a ContentInfo structure 786 wrapped in an OCTET STRING. The KDC AS reply key is encrypted in the 787 encKeyPack field, which contains data of type ReplyKeyPack: 789 ReplyKeyPack ::= SEQUENCE { 790 replyKey [0] EncryptionKey, 791 -- Contains the session key used to encrypt the 792 -- enc-part field in the AS-REP. 793 nonce [1] INTEGER (0..4294967295), 794 -- Contains the nonce in the PKAuthenticator of the 795 -- request. 796 ... 797 } 799 The ContentInfo [RFC3852] structure for the encKeyPack field is 800 filled in as follows: 802 1. The contentType field of the type ContentInfo is id-envelopedData 803 (as defined in [RFC3852]), and the content field is an 804 EnvelopedData (as defined in [RFC3852]). 806 2. The contentType field for the type EnvelopedData is 807 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 808 pkcs (1) pkcs7 (7) signedData (2) }. 810 3. The eContentType field for the inner type SignedData (when 811 decrypted from the encryptedContent field for the type 812 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 813 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 815 4. The eContent field for the inner type SignedData contains the DER 816 encoding of the type ReplyKeyPack. 818 5. The signerInfos field of the inner type SignedData contains a 819 single signerInfo, which contains the signature over the type 820 ReplyKeyPack. 822 6. The certificates field of the inner type SignedData contains 823 certificates intended to facilitate certification path 824 construction, so that the client can verify the KDC's signature 825 over the type ReplyKeyPack. This field may only be left empty if 826 the KDC public key specified by the kdcPkId field in the 827 PA-PK-AS-REQ was used for signing. Otherwise, for path 828 validation, these certificates SHOULD be sufficient to construct 829 at least one certification path from the KDC certificate to one 830 trust anchor acceptable by the client [CAPATH]. The certificates 831 field MUST NOT contain "root" CA certificates. 833 7. The recipientInfos field of the type EnvelopedData is a SET which 834 MUST contain exactly one member of type KeyTransRecipientInfo. 835 The encryptedKey of this member contains the temporary key which 836 is encrypted using the client's public key. 838 8. The unprotectedAttrs or originatorInfo fields of the type 839 EnvelopedData MAY be present. 841 3.2.4 Receipt of KDC Reply 843 Upon receipt of the KDC's reply, the client proceeds as follows. If 844 the PA-PK-AS-REP contains the dhSignedData field, the client derives 845 the KDC AS reply key using the same procedure used by the KDC as 846 defined in Section 3.2.3.1. Otherwise, the message contains the 847 encKeyPack field, and the client decrypts and extracts the temporary 848 key in the encryptedKey field of the member KeyTransRecipientInfo, 849 and then uses that as the KDC AS reply key. 851 In either case, the client MUST verify the signature in the 852 SignedData according to [RFC3852]. Unless the client can otherwise 853 prove that the public key used to verify the KDC's signature is bound 854 to the target KDC, the KDC's X.509 certificate MUST satisfy at least 855 one of the follow two requirements: 857 1. The certificate contains a Subject Alternative Name (SAN) 858 extension carrying a dNSName and that name value matches the 859 following name format: 861 _Service._Proto.Realm 863 Where the Service name is the string literal "kerberos", the 864 Proto can be "udp" or "tcp", and the Realm is the domain style 865 Kerberos realm name [CLAR] of the target KDC. This name format 866 is identical to the owner label format used in the DNS SRV 867 records for specifying the KDC location as described in [CLAR]. 868 For example, the X.509 certificate for the KDC of the Kerberos 869 realm "EXAMPLE.COM" would contain a dNSName value of 870 "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM". 872 2. The certificate contains the EKU KeyPurposeId [RFC3280] 873 id-pkkdcekuoid (defined below) and an SAN extension [RFC3280] 874 carrying an AnotherName whose type-id is id-pksan (as defined in 875 Section 3.2.2) and whose value contains a KRB5PrincipalName name, 876 and the realm name of that KRB5PrincipalName matches the realm 877 name of the target KDC. 879 id-pkkdcekuoid OBJECT IDENTIFIER ::= 880 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 881 pkinit(3) pkkdcekuoid(5) } 882 -- Signing KDC responses. 883 -- Key usage bits that MUST be consistent: 884 -- digitalSignature. 886 If no SAN id-pksan extension is present (but the id-pkkdcekuoid 887 EKU is) in the KDC's X.509 certificate, and the client has a 888 priori knowledge of the KDC's hostname (or IP address), the 889 client SHOULD accept the KDC's X.509 certificate if that 890 certificate contains an SAN extension carrying a dNSName and the 891 dNSName value matches the hostname (or the IP address) of the KDC 892 with which the client believes it is communicating. 894 Matching rules used for the dNSName value are specified in [RFC3280]. 896 If all applicable checks are satisfied, the client then decrypts the 897 enc-part field of the KDC-REP in the AS-REP using the KDC AS reply 898 key, and then proceeds as described in [CLAR]. 900 Implementation note: CAs issuing KDC certificates SHOULD place all 901 "short" and "fully-qualified" Kerberos realm names of the KDC (one 902 per SAN extension) into the KDC certificate to allow maximum 903 flexibility. 905 3.3 Interoperability Requirements 907 The client MUST be capable of sending a set of certificates 908 sufficient to allow the KDC to construct a certification path for the 909 client's certificate, if the correct set of certificates is provided 910 through configuration or policy. 912 If the client sends all the X.509 certificates on a certification 913 path to a trust anchor acceptable by the KDC, and the KDC can not 914 verify the client's public key otherwise, the KDC MUST be able to 915 process path validation for the client's certificate based on the 916 certificates in the request. 918 The KDC MUST be capable of sending a set of certificates sufficient 919 to allow the client to construct a certification path for the KDC's 920 certificate, if the correct set of certificates is provided through 921 configuration or policy. 923 If the KDC sends all the X.509 certificates on a certification path 924 to a trust anchor acceptable by the client, and the client can not 925 verify the KDC's public key otherwise, the client MUST be able to 926 process path validation for the KDC's certificate based on the 927 certificates in the reply. 929 3.4 KDC Indication of PKINIT Support 931 If pre-authentication is required, but was not present in the 932 request, per [CLAR] an error message with the code 933 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 934 stored in the e-data field of the KRB-ERROR message to specify which 935 pre-authentication mechanisms are acceptable. The KDC can then 936 indicate the support of PKINIT by including an empty element whose 937 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 939 Otherwise if it is required by the KDC's local policy that the client 940 must be pre-authenticated using the pre-authentication mechanism 941 specified in this document, but no PKINIT pre-authentication was 942 present in the request, an error message with the code 943 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 945 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 946 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 947 STRING), and clients MUST ignore this and any other value. Future 948 extensions to this protocol may specify other data to send instead of 949 an empty OCTET STRING. 951 4. Security Considerations 953 PKINIT raises certain security considerations beyond those that can 954 be regulated strictly in protocol definitions. We will address them 955 in this section. 957 PKINIT extends the cross-realm model to the public-key 958 infrastructure. Users of PKINIT must understand security policies 959 and procedures appropriate to the use of Public Key Infrastructures 960 [RFC3280]. 962 Standard Kerberos allows the possibility of interactions between 963 cryptosystems of varying strengths; this document adds interactions 964 with public-key cryptosystems to Kerberos. Some administrative 965 policies may allow the use of relatively weak public keys. Using 966 such keys to wrap data encrypted under stronger conventional 967 cryptosystems may be inappropriate. 969 PKINIT requires keys for symmetric cryptosystems to be generated. 970 Some such systems contain "weak" keys. For recommendations regarding 971 these weak keys, see [CLAR]. 973 PKINIT allows the use of the same RSA key pair for encryption and 974 signing when doing RSA encryption based key delivery. This is not 975 recommended usage of RSA keys [RFC3447], by using DH based key 976 delivery this is avoided. 978 Care should be taken in how certificates are chosen for the purposes 979 of authentication using PKINIT. Some local policies may require that 980 key escrow be used for certain certificate types. Deployers of 981 PKINIT should be aware of the implications of using certificates that 982 have escrowed keys for the purposes of authentication. Because 983 signing only certificates are normally not escrowed, by using DH 984 based key delivery this is avoided. 986 PKINIT does not provide for a "return routability" test to prevent 987 attackers from mounting a denial-of-service attack on the KDC by 988 causing it to perform unnecessary and expensive public-key 989 operations. Strictly speaking, this is also true of standard 990 Kerberos, although the potential cost is not as great, because 991 standard Kerberos does not make use of public-key cryptography. By 992 using DH based key delivery and reusing DH keys, the necessary crypto 993 processing cost per request can be minimized. 995 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 996 permit empty SEQUENCEs to be encoded. Such empty sequences may only 997 be used if the KDC itself vouches for the user's certificate. 999 5. Acknowledgements 1001 The following people have made significant contributions to this 1002 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist 1003 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 1004 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik 1005 Jaganathan. 1007 Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky 1008 who wrote earlier versions of this document. 1010 The authors are indebt to the Kerberos working group chair Jeffrey 1011 Hutzelman who kept track of various issues and was enormously helpful 1012 during the creation of this document. 1014 Some of the ideas on which this document is based arose during 1015 discussions over several years between members of the SAAG, the IETF 1016 CAT working group, and the PSRG, regarding integration of Kerberos 1017 and SPX. Some ideas have also been drawn from the DASS system. 1018 These changes are by no means endorsed by these groups. This is an 1019 attempt to revive some of the goals of those groups, and this 1020 document approaches those goals primarily from the Kerberos 1021 perspective. 1023 Lastly, comments from groups working on similar ideas in DCE have 1024 been invaluable. 1026 6. IANA Considerations 1028 This document has no actions for IANA. 1030 7. References 1032 7.1 Normative References 1034 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- 1035 krb-wg-kerberos-clarifications. Work in Progress. 1037 [IEEE1363] 1038 IEEE, "Standard Specifications for Public Key 1039 Cryptography", IEEE 1363, 2000. 1041 [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf- 1042 krb-wg-crypto. Work in Progress. 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, March 1997. 1047 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1048 RFC 2412, November 1998. 1050 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1051 RFC 2631, June 1999. 1053 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and 1054 Identifiers for the Internet X.509 Public Key 1055 Infrastructure Certificate and Certificate Revocation List 1056 (CRL) Profile", RFC 3279, April 2002. 1058 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1059 X.509 Public Key Infrastructure Certificate and 1060 Certificate Revocation List (CRL) Profile", RFC 3280, 1061 April 2002. 1063 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1064 Algorithms", RFC 3370, August 2002. 1066 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1067 Standards (PKCS) #1: RSA Cryptography Specifications 1068 Version 2.1", RFC 3447, February 2003. 1070 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1071 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1072 RFC 3526, May 2003. 1074 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1075 Encryption Algorithm in Cryptographic Message Syntax 1076 (CMS)", RFC 3565, July 2003. 1078 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1079 RFC 3852, July 2004. 1081 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication 1082 Framework. 1997. 1084 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1085 Rules (BER), Canonical Encoding Rules (CER) and 1086 Distinguished Encoding Rules (DER), ITU-T Recommendation 1087 X.690 (1997) | ISO/IEC International Standard 1088 8825-1:1998. 1090 7.2 Informative References 1092 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1093 pkix-certpathbuild. Work in Progress. 1095 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1096 Sizes", Journal of Cryptology 14 (2001) 255-293. 1098 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1099 future, Designs, Codes, and Cryptography (1999)". 1101 Authors' Addresses 1103 Brian Tung 1104 USC Information Sciences Institute 1105 4676 Admiralty Way Suite 1001, Marina del Rey CA 1106 Marina del Rey, CA 90292 1107 US 1109 Email: brian@isi.edu 1111 Larry Zhu 1112 Microsoft Corporation 1113 One Microsoft Way 1114 Redmond, WA 98052 1115 US 1117 Email: lzhu@microsoft.com 1119 Appendix A. PKINIT ASN.1 Module 1120 KerberosV5-PK-INIT-SPEC { 1121 iso(1) identified-organization(3) dod(6) internet(1) 1122 security(5) kerberosV5(2) modules(4) pkinit(5) 1123 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1125 IMPORTS 1126 SubjectPublicKeyInfo, AlgorithmIdentifier 1127 FROM PKIX1Explicit88 { iso (1) 1128 identified-organization (3) dod (6) internet (1) 1129 security (5) mechanisms (5) pkix (7) id-mod (0) 1130 id-pkix1-explicit (18) } 1131 -- As defined in RFC 3280. 1133 DomainParameters, EcpkParameters 1134 FROM PKIX1Algorithms88 { iso(1) 1135 identified-organization(3) dod(6) 1136 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1137 id-mod-pkix1-algorithms(17) } 1138 -- As defined in RFC 3279. 1140 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey 1141 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1142 dod(6) internet(1) security(5) kerberosV5(2) 1143 modules(4) krb5spec2(2) } ; 1145 id-pkinit OBJECT IDENTIFIER ::= 1146 { iso (1) org (3) dod (6) internet (1) security (5) 1147 kerberosv5 (2) pkinit (3) } 1149 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1150 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1151 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1152 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1153 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1155 pa-pk-as-req INTEGER ::= 16 1156 pa-pk-as-rep INTEGER ::= 17 1158 ad-initial-verified-cas INTEGER ::= 9 1160 td-trusted-certifiers INTEGER ::= 104 1161 td-invalid-certificates INTEGER ::= 105 1162 td-dh-parameters INTEGER ::= 109 1164 PA-PK-AS-REQ ::= SEQUENCE { 1165 signedAuthPack [0] IMPLICIT OCTET STRING, 1166 -- Contains a CMS type ContentInfo encoded 1167 -- according to [RFC3852]. 1169 -- The contentType field of the type ContentInfo 1170 -- is id-signedData (1.2.840.113549.1.7.2), 1171 -- and the content field is a SignedData. 1172 -- The eContentType field for the type SignedData is 1173 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1174 -- eContent field contains the DER encoding of the 1175 -- type AuthPack. 1176 -- AuthPack is defined below. 1177 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 1178 -- A list of CAs, trusted by the client, that can 1179 -- be used as the trust anchor to validate the KDC's 1180 -- signature. 1181 -- Each TrustedCA identifies a CA or a CA 1182 -- certificate (thereby its public key). 1183 kdcPkId [2] IMPLICIT OCTET STRING 1184 OPTIONAL, 1185 -- Contains a CMS type SignerIdentifier encoded 1186 -- according to [RFC3852]. 1187 -- Identifies, if present, a particular KDC 1188 -- public key that the client already has. 1189 ... 1190 } 1192 DHNonce ::= OCTET STRING 1194 TrustedCA ::= SEQUENCE { 1195 caName [0] IMPLICIT OCTET STRING, 1196 -- Contains a PKIX type Name encoded according to 1197 -- [RFC3280]. 1198 -- Identifies a CA. 1199 -- Prefer the sid field below if that is available. 1200 certificateSerialNumber [1] INTEGER OPTIONAL, 1201 -- Specifies the certificate serial number. 1202 -- The defintion of the certificate serial number 1203 -- is taken from X.509 [X.509-97]. 1204 subjectKeyIdentifier [2] OCTET STRING OPTIONAL, 1205 -- Identifies the CA's public key by a key 1206 -- identifier. When an X.509 certificate is 1207 -- referenced, this key identifier matches the X.509 1208 -- subjectKeyIdentifier extension value. When other 1209 -- certificate formats are referenced, the documents 1210 -- that specify the certificate format and their use 1211 -- with the CMS must include details on matching the 1212 -- key identifier to the appropriate certificate 1213 -- field. 1214 ... 1215 } 1216 AuthPack ::= SEQUENCE { 1217 pkAuthenticator [0] PKAuthenticator, 1218 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1219 -- Defined in [RFC3280]. 1220 -- The pubic key value (the subjectPublicKey field 1221 -- of the type SubjectPublicKeyInfo) MUST be encoded 1222 -- according to [RFC3279]. 1223 -- Present only if the client wishes to use the 1224 -- Diffie-Hellman key agreement method. 1225 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1226 OPTIONAL, 1227 -- List of CMS encryption types supported by 1228 -- client in order of (decreasing) preference. 1229 clientDHNonce [3] DHNonce OPTIONAL, 1230 -- Present only if the client indicates that it 1231 -- wishes to reuse DH keys or to allow the KDC to 1232 -- do so. 1233 ... 1234 } 1236 PKAuthenticator ::= SEQUENCE { 1237 cusec [0] INTEGER (0..999999), 1238 ctime [1] KerberosTime, 1239 -- cusec and ctime are used as in [CLAR], for replay 1240 -- prevention. 1241 nonce [2] INTEGER (0..4294967295), 1242 -- Chosen randomly; This nonce does not need to 1243 -- match with the nonce in the KDC-REQ-BODY. 1244 paChecksum [3] OCTET STRING, 1245 -- Contains the SHA1 checksum, performed over 1246 -- KDC-REQ-BODY. 1247 ... 1248 } 1250 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA 1251 -- Identifies a list of CAs trusted by the KDC. 1252 -- Each TrustedCA identifies a CA or a CA 1253 -- certificate (thereby its public key). 1255 TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING 1256 -- Each OCTET STRING contains a CMS type 1257 -- IssuerAndSerialNumber encoded according to 1258 -- [RFC3852]. 1259 -- Each IssuerAndSerialNumber indentifies a 1260 -- certificate (sent by the client) with an invalid 1261 -- signature. 1263 KRB5PrincipalName ::= SEQUENCE { 1264 realm [0] Realm, 1265 principalName [1] PrincipalName 1266 } 1268 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA 1269 -- Identifies the certification path based on which 1270 -- the client certificate was validated. 1271 -- Each TrustedCA identifies a CA or a CA 1272 -- certificate (thereby its public key). 1274 PA-PK-AS-REP ::= CHOICE { 1275 dhInfo [0] DHRepInfo, 1276 -- Selected when Diffie-Hellman key exchange is 1277 -- used. 1278 encKeyPack [1] IMPLICIT OCTET STRING, 1279 -- Selected when public key encryption is used. 1280 -- Contains a CMS type ContentInfo encoded 1281 -- according to [RFC3852]. 1282 -- The contentType field of the type ContentInfo is 1283 -- id-envelopedData (1.2.840.113549.1.7.3). 1284 -- The content field is an EnvelopedData. 1285 -- The contentType field for the type EnvelopedData 1286 -- is id-signedData (1.2.840.113549.1.7.2). 1287 -- The eContentType field for the inner type 1288 -- SignedData (when unencrypted) is id-pkrkeydata 1289 -- (1.2.840.113549.1.7.3) and the eContent field 1290 -- contains the DER encoding of the type 1291 -- ReplyKeyPack. 1292 -- ReplyKeyPack is defined below. 1293 ... 1294 } 1296 DHRepInfo ::= SEQUENCE { 1297 dhSignedData [0] IMPLICIT OCTET STRING, 1298 -- Contains a CMS type ContentInfo encoded according 1299 -- to [RFC3852]. 1300 -- The contentType field of the type ContentInfo is 1301 -- id-signedData (1.2.840.113549.1.7.2), and the 1302 -- content field is a SignedData. 1303 -- The eContentType field for the type SignedData is 1304 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1305 -- eContent field contains the DER encoding of the 1306 -- type KDCDHKeyInfo. 1307 -- KDCDHKeyInfo is defined below. 1308 serverDHNonce [1] DHNonce OPTIONAL 1309 -- Present if and only if dhKeyExpiration is 1310 -- present. 1311 } 1312 KDCDHKeyInfo ::= SEQUENCE { 1313 subjectPublicKey [0] BIT STRING, 1314 -- KDC's DH public key. 1315 -- The DH pubic key value is mapped to a BIT STRING 1316 -- according to [RFC3279]. 1317 nonce [1] INTEGER (0..4294967295), 1318 -- Contains the nonce in the PKAuthenticator of the 1319 -- request if DH keys are NOT reused, 1320 -- 0 otherwise. 1321 dhKeyExpiration [2] KerberosTime OPTIONAL, 1322 -- Expiration time for KDC's key pair, 1323 -- present if and only if DH keys are reused. If 1324 -- this field is omitted then the serverDHNonce 1325 -- field MUST also be omitted. 1326 ... 1327 } 1329 ReplyKeyPack ::= SEQUENCE { 1330 replyKey [0] EncryptionKey, 1331 -- Contains the session key used to encrypt the 1332 -- enc-part field in the AS-REP. 1333 nonce [1] INTEGER (0..4294967295), 1334 -- Contains the nonce in the PKAuthenticator of the 1335 -- request. 1336 ... 1337 } 1339 TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters 1340 -- Contains a list of Diffie-Hellman domain 1341 -- parameters in decreasing preference order. 1343 DHDomainParameters ::= CHOICE { 1344 modp [0] DomainParameters, 1345 -- Type DomainParameters is defined in [RFC3279]. 1346 ec [1] EcpkParameters, 1347 -- Type EcpkParameters is defined in [RFC3279]. 1348 ... 1349 } 1350 END 1352 Intellectual Property Statement 1354 The IETF takes no position regarding the validity or scope of any 1355 Intellectual Property Rights or other rights that might be claimed to 1356 pertain to the implementation or use of the technology described in 1357 this document or the extent to which any license under such rights 1358 might or might not be available; nor does it represent that it has 1359 made any independent effort to identify any such rights. Information 1360 on the procedures with respect to rights in RFC documents can be 1361 found in BCP 78 and BCP 79. 1363 Copies of IPR disclosures made to the IETF Secretariat and any 1364 assurances of licenses to be made available, or the result of an 1365 attempt made to obtain a general license or permission for the use of 1366 such proprietary rights by implementers or users of this 1367 specification can be obtained from the IETF on-line IPR repository at 1368 http://www.ietf.org/ipr. 1370 The IETF invites any interested party to bring to its attention any 1371 copyrights, patents or patent applications, or other proprietary 1372 rights that may cover technology that may be required to implement 1373 this standard. Please address the information to the IETF at 1374 ietf-ipr@ietf.org. 1376 Disclaimer of Validity 1378 This document and the information contained herein are provided on an 1379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1386 Copyright Statement 1388 Copyright (C) The Internet Society (2005). This document is subject 1389 to the rights, licenses and restrictions contained in BCP 78, and 1390 except as set forth therein, the authors retain all their rights. 1392 Acknowledgment 1394 Funding for the RFC Editor function is currently provided by the 1395 Internet Society.