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