idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-30.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1772. ** 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. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, -- The KDC's DH public key. -- The DH public key value is encoded as a BIT -- STRING according to [RFC3279]. nonce [1] INTEGER (0..4294967295), -- Contains the nonce in the pkAuthenticator field -- in the request if the DH keys are NOT reused, -- 0 otherwise. dhKeyExpiration [2] KerberosTime OPTIONAL, -- Expiration time for KDC's key pair, -- present if and only if the DH keys are reused. -- If present, the KDC's DH public key MUST not be -- used past the point of this expiration time. -- If this field is omitted then the serverDHNonce -- field MUST also be omitted. ... } == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, -- The KDC's DH public key. -- The DH public key value is encoded as a BIT -- STRING according to [RFC3279]. nonce [1] INTEGER (0..4294967295), -- Contains the nonce in the pkAuthenticator field -- in the request if the DH keys are NOT reused, -- 0 otherwise. dhKeyExpiration [2] KerberosTime OPTIONAL, -- Expiration time for KDC's key pair, -- present if and only if the DH keys are reused. -- If present, the KDC's DH public key MUST not be -- used past the point of this expiration time. -- If this field is omitted then the serverDHNonce -- field MUST also be omitted. ... } -- 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 (November 29, 2005) is 6723 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 1581 -- Looks like a reference, but probably isn't: '1' on line 1585 -- Looks like a reference, but probably isn't: '2' on line 1570 -- Looks like a reference, but probably isn't: '3' on line 1492 == Unused Reference: 'LENSTRA' is defined on line 1345, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft Microsoft Corporation 4 Expires: June 2, 2006 B. Tung 5 USC Information Sciences Institute 6 November 29, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-30 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes protocol extensions (hereafter called PKINIT) 43 to the Kerberos protocol specification. These extensions provide a 44 method for integrating public key cryptography into the initial 45 authentication exchange, by using asymmetric-key signature and/or 46 encryption algorithms in pre-authentication data fields. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 52 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5 54 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5 55 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 56 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 57 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 58 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 59 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12 60 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16 61 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22 62 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24 63 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 70 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29 71 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 72 Appendix C. Miscellaneous Information about Microsoft Windows 73 PKINIT Implementations . . . . . . . . . . . . . . . 36 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 75 Intellectual Property and Copyright Statements . . . . . . . . . . 39 77 1. Introduction 79 A client typically authenticates itself to a service in Kerberos 80 using three distinct though related exchanges. First, the client 81 requests a ticket-granting ticket (TGT) from the Kerberos 82 authentication server (AS). Then, it uses the TGT to request a 83 service ticket from the Kerberos ticket-granting server (TGS). 84 Usually, the AS and TGS are integrated in a single device known as a 85 Kerberos Key Distribution Center, or KDC. Finally, the client uses 86 the service ticket to authenticate itself to the service. 88 The advantage afforded by the TGT is that the client exposes his 89 long-term secrets only once. The TGT and its associated session key 90 can then be used for any subsequent service ticket requests. One 91 result of this is that all further authentication is independent of 92 the method by which the initial authentication was performed. 93 Consequently, initial authentication provides a convenient place to 94 integrate public-key cryptography into Kerberos authentication. 96 As defined in [RFC4120], Kerberos authentication exchanges use 97 symmetric-key cryptography, in part for performance. One 98 disadvantage of using symmetric-key cryptography is that the keys 99 must be shared, so that before a client can authenticate itself, he 100 must already be registered with the KDC. 102 Conversely, public-key cryptography (in conjunction with an 103 established Public Key Infrastructure) permits authentication without 104 prior registration with a KDC. Adding it to Kerberos allows the 105 widespread use of Kerberized applications by clients without 106 requiring them to register first with a KDC--a requirement that has 107 no inherent security benefit. 109 As noted above, a convenient and efficient place to introduce public- 110 key cryptography into Kerberos is in the initial authentication 111 exchange. This document describes the methods and data formats for 112 integrating public-key cryptography into Kerberos initial 113 authentication. 115 2. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 Both the AS and the TGS are referred to as the KDC. 123 In this document, the encryption key used to encrypt the enc-part 124 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS 125 reply key. 127 In this document, an empty sequence in an optional field can be 128 either included or omitted: both encodings are permitted and 129 considered equivalent. 131 In this document, the term "Modular Exponential Diffie-Hellman" is 132 used to refer to the Diffie-Hellman key exchange as described in 133 [RFC2631], in order to differentiate it from other equivalent 134 representations of the same key agreement algorithm. 136 3. Extensions 138 This section describes extensions to [RFC4120] for supporting the use 139 of public-key cryptography in the initial request for a ticket. 141 Briefly, this document defines the following extensions to [RFC4120]: 143 1. The client indicates the use of public-key authentication by 144 including a special preauthenticator in the initial request. This 145 preauthenticator contains the client's public-key data and a 146 signature. 148 2. The KDC tests the client's request against its authentication 149 policy and trusted Certification Authorities (CAs). 151 3. If the request passes the verification tests, the KDC replies as 152 usual, but the reply is encrypted using either: 154 a. a key generated through a Diffie-Hellman (DH) key exchange 155 [RFC2631] [IEEE1363] with the client, signed using the KDC's 156 signature key; or 158 b. a symmetric encryption key, signed using the KDC's signature 159 key and encrypted using the client's public key. 161 Any keying material required by the client to obtain the 162 encryption key for decrypting the KDC reply is returned in a pre- 163 authentication field accompanying the usual reply. 165 4. The client validates the KDC's signature, obtains the encryption 166 key, decrypts the reply, and then proceeds as usual. 168 Section 3.1 of this document enumerates the required algorithms and 169 necessary extension message types. Section 3.2 describes the 170 extension messages in greater detail. 172 3.1. Definitions, Requirements, and Constants 174 3.1.1. Required Algorithms 176 All PKINIT implementations MUST support the following algorithms: 178 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 179 sha1-96 [RFC3962]. 181 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 183 o AS reply key delivery method: Diffie-Hellman key exchange 184 [RFC2631]. 186 In addition, implementations of this specification MUST be capable of 187 processing the Extended Key Usage (EKU) extension and the id-pkinit- 188 san (as defined in Section 3.2.2) otherName of the Subject 189 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if 190 present. 192 3.1.2. Defined Message and Encryption Types 194 PKINIT makes use of the following new pre-authentication types: 196 PA_PK_AS_REQ 16 197 PA_PK_AS_REP 17 199 PKINIT also makes use of the following new authorization data type: 201 AD_INITIAL_VERIFIED_CAS 9 203 PKINIT introduces the following new error codes: 205 KDC_ERR_CLIENT_NOT_TRUSTED 62 206 KDC_ERR_INVALID_SIG 64 207 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 208 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 209 KDC_ERR_INVALID_CERTIFICATE 71 210 KDC_ERR_REVOKED_CERTIFICATE 72 211 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 212 KDC_ERR_CLIENT_NAME_MISMATCH 75 213 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 214 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77 215 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78 216 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79 218 PKINIT uses the following typed data types for errors: 220 TD_TRUSTED_CERTIFIERS 104 221 TD_INVALID_CERTIFICATES 105 222 TD_DH_PARAMETERS 109 224 The ASN.1 module for all structures defined in this document (plus 225 IMPORT statements for all imported structures) is given in 226 Appendix A. 228 All structures defined in or imported into this document MUST be 229 encoded using Distinguished Encoding Rules (DER) [X680] [X690] 230 (unless otherwise noted). All data structures carried in OCTET 231 STRINGs must be encoded according to the rules specified in 232 corresponding specifications. 234 Interoperability note: Some implementations may not be able to decode 235 wrapped CMS objects encoded with BER but not DER; specifically, they 236 may not be able to decode indefinite length encodings. To maximize 237 interoperability, implementers SHOULD encode CMS objects used in 238 PKINIT with DER. 240 3.1.3. Algorithm Identifiers 242 PKINIT does not define, but does make use of, the following algorithm 243 identifiers. 245 PKINIT uses the following algorithm identifier(s) for Modular 246 Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]: 248 dhpublicnumber (as described in [RFC3279]) 250 PKINIT uses the following signature algorithm identifiers as defined 251 in [RFC3279]: 253 sha-1WithRSAEncryption (RSA with SHA1) 254 md5WithRSAEncryption (RSA with MD5) 255 id-dsa-with-sha1 (DSA with SHA1) 257 PKINIT uses the following encryption algorithm identifiers as defined 258 in [RFC3447] for encrypting the temporary key with a public key: 260 rsaEncryption 261 id-RSAES-OAEP 263 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 264 for encrypting the AS reply key with the temporary key: 266 des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370]) 267 rc2-cbc (RC2, CBC mode, as defined in [RFC3370]) 268 id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565]) 270 PKINIT defines the following encryption types, for use in the etype 271 field of the AS-REQ [RFC4120] message to indicate acceptance of the 272 corresponding algorithms that can used by Cryptographic Message 273 Syntax (CMS) [RFC3852] messages in the reply: 275 id-dsa-with-sha1-CmsOID 9 276 -- Indicates that the client supports id-dsa-with-sha1. 277 md5WithRSAEncryption-CmsOID 10 278 -- Indicates that the client supports md5WithRSAEncryption. 279 sha-1WithRSAEncryption-CmsOID 11 280 -- Indicates that the client supports sha-1WithRSAEncryption. 281 rc2-cbc-EnvOID 12 282 -- Indicates that the client supports rc2-cbc. 283 rsaEncryption-EnvOID 13 284 -- Indicates that the client supports rsaEncryption. 285 id-RSAES-OAEP-EnvOID 14 286 -- Indicates that the client supports id-RSAES-OAEP. 287 des-ede3-cbc-EnvOID 15 288 -- Indicates that the client supports des-ede3-cbc. 290 3.2. PKINIT Pre-authentication Syntax and Use 292 This section defines the syntax and use of the various pre- 293 authentication fields employed by PKINIT. 295 3.2.1. Generation of Client Request 297 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 298 in addition, a pre-authentication data element, whose padata-type is 299 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 300 type PA-PK-AS-REQ, is included. 302 PA-PK-AS-REQ ::= SEQUENCE { 303 signedAuthPack [0] IMPLICIT OCTET STRING, 304 -- Contains a CMS type ContentInfo encoded 305 -- according to [RFC3852]. 306 -- The contentType field of the type ContentInfo 307 -- is id-signedData (1.2.840.113549.1.7.2), 308 -- and the content field is a SignedData. 309 -- The eContentType field for the type SignedData is 310 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 311 -- eContent field contains the DER encoding of the 312 -- type AuthPack. 313 -- AuthPack is defined below. 314 trustedCertifiers [1] SEQUENCE OF 315 ExternalPrincipalIdentifier OPTIONAL, 317 -- Contains a list of CAs, trusted by the client, 318 -- that can be used to certify the KDC. 319 -- Each ExternalPrincipalIdentifier identifies a CA 320 -- or a CA certificate (thereby its public key). 321 -- The information contained in the 322 -- trustedCertifiers SHOULD be used by the KDC as 323 -- hints to guide its selection of an appropriate 324 -- certificate chain to return to the client. 325 kdcPkId [2] IMPLICIT OCTET STRING 326 OPTIONAL, 327 -- Contains a CMS type SignerIdentifier encoded 328 -- according to [RFC3852]. 329 -- Identifies, if present, a particular KDC 330 -- public key that the client already has. 331 ... 332 } 334 DHNonce ::= OCTET STRING 336 ExternalPrincipalIdentifier ::= SEQUENCE { 337 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 338 -- Contains a PKIX type Name encoded according to 339 -- [RFC3280]. 340 -- Identifies the certificate subject by the 341 -- distinguished subject name. 342 -- REQUIRED when there is a distinguished subject 343 -- name present in the certificate. 344 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 345 -- Contains a CMS type IssuerAndSerialNumber encoded 346 -- according to [RFC3852]. 347 -- Identifies a certificate of the subject. 348 -- REQUIRED for TD-INVALID-CERTIFICATES and 349 -- TD-TRUSTED-CERTIFIERS. 350 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 351 -- Identifies the subject's public key by a key 352 -- identifier. When an X.509 certificate is 353 -- referenced, this key identifier matches the X.509 354 -- subjectKeyIdentifier extension value. When other 355 -- certificate formats are referenced, the documents 356 -- that specify the certificate format and their use 357 -- with the CMS must include details on matching the 358 -- key identifier to the appropriate certificate 359 -- field. 360 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 361 ... 362 } 364 AuthPack ::= SEQUENCE { 365 pkAuthenticator [0] PKAuthenticator, 366 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 367 -- Type SubjectPublicKeyInfo is defined in 368 -- [RFC3280]. 369 -- Specifies Diffie-Hellman domain parameters 370 -- and the client's public key value [IEEE1363]. 371 -- The DH public key value is encoded as a BIT 372 -- STRING according to [RFC3279]. 373 -- This field is present only if the client wishes 374 -- to use the Diffie-Hellman key agreement method. 375 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 376 OPTIONAL, 377 -- Type AlgorithmIdentifier is defined in 378 -- [RFC3280]. 379 -- List of CMS encryption types supported by the 380 -- client in order of (decreasing) preference. 381 clientDHNonce [3] DHNonce OPTIONAL, 382 -- Present only if the client indicates that it 383 -- wishes to reuse DH keys or to allow the KDC to 384 -- do so (see Section 3.2.3.1). 385 ... 386 } 388 PKAuthenticator ::= SEQUENCE { 389 cusec [0] INTEGER (0..999999), 390 ctime [1] KerberosTime, 391 -- cusec and ctime are used as in [RFC4120], for 392 -- replay prevention. 393 nonce [2] INTEGER (0..4294967295), 394 -- Chosen randomly; This nonce does not need to 395 -- match with the nonce in the KDC-REQ-BODY. 396 paChecksum [3] OCTET STRING, 397 -- Contains the SHA1 checksum, performed over 398 -- KDC-REQ-BODY. 399 ... 400 } 402 The ContentInfo [RFC3852] structure contained in the signedAuthPack 403 field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and 404 is filled out as follows: 406 1. The contentType field of the type ContentInfo is id-signedData 407 (as defined in [RFC3852]), and the content field is a SignedData 408 (as defined in [RFC3852]). 410 2. The eContentType field for the type SignedData is id-pkinit- 411 authData: { iso(1) org(3) dod(6) internet(1) security(5) 412 kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS 413 implementers: the signed attribute content-type MUST be present 414 in this SignedData instance and its value is id-pkinit-authData 415 according to [RFC3852]. 417 3. The eContent field for the type SignedData contains the DER 418 encoding of the type AuthPack. 420 4. The signerInfos field of the type SignedData contains a single 421 signerInfo, which contains the signature over the type AuthPack. 423 5. The AuthPack structure contains a PKAuthenticator, the client 424 public key information, the CMS encryption types supported by the 425 client and a DHNonce. The pkAuthenticator field certifies to the 426 KDC that the client has recent knowledge of the signing key that 427 authenticates the client. The clientPublicValue field specifies 428 Diffie-Hellman domain parameters and the client's public key 429 value. The DH public key value is encoded as a BIT STRING 430 according to [RFC3279]. The clientPublicValue field is present 431 only if the client wishes to use the Diffie-Hellman key agreement 432 method. The supportedCMSTypes field specifies the list of CMS 433 encryption types supported by the client in order of (decreasing) 434 preference. The clientDHNonce field is described later in this 435 section. 437 6. The ctime field in the PKAuthenticator structure contains the 438 current time on the client's host, and the cusec field contains 439 the microsecond part of the client's timestamp. The ctime and 440 cusec fields are used together to specify a reasonably accurate 441 timestamp [RFC4120]. The nonce field is chosen randomly. The 442 paChecksum field contains a SHA1 checksum that is performed over 443 the KDC-REQ-BODY [RFC4120]. 445 7. The certificates field of the type SignedData contains 446 certificates intended to facilitate certification path 447 construction, so that the KDC can verify the signature over the 448 type AuthPack. For path validation, these certificates SHOULD be 449 sufficient to construct at least one certification path from the 450 client certificate to one trust anchor acceptable by the KDC 451 [RFC4158]. The client MUST be capable of including such a set of 452 certificates if configured to do so. The certificates field MUST 453 NOT contain "root" CA certificates. 455 8. The client's Diffie-Hellman public value (clientPublicValue) is 456 included if and only if the client wishes to use the Diffie- 457 Hellman key agreement method. The Diffie-Hellman domain 458 parameters [IEEE1363] for the client's public key are specified 459 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 460 and the client's Diffie-Hellman public key value is mapped to a 461 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 462 using the Diffie-Hellman key agreement method, implementations 463 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 464 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 465 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 466 group 16 [RFC3526]. 468 The Diffie-Hellman field size should be chosen so as to provide 469 sufficient cryptographic security [RFC3766]. 471 When MODP Diffie-Hellman is used, the exponents should have at 472 least twice as many bits as the symmetric keys that will be 473 derived from them [ODL99]. 475 9. The client may wish to reuse DH keys or to allow the KDC to do so 476 (see Section 3.2.3.1). If so, then the client includes the 477 clientDHNonce field. This nonce string MUST be as long as the 478 longest key length of the symmetric key types that the client 479 supports. This nonce MUST be chosen randomly. 481 The ExternalPrincipalIdentifier structure is used in this document to 482 identify the subject's public key thereby the subject principal. 483 This structure is filled out as follows: 485 1. The subjectName field contains a PKIX type Name encoded according 486 to [RFC3280]. This field identifies the certificate subject by 487 the distinguished subject name. This field is REQUIRED when 488 there is a distinguished subject name present in the certificate 489 being used. 491 2. The issuerAndSerialNumber field contains a CMS type 492 IssuerAndSerialNumber encoded according to [RFC3852]. This field 493 identifies a certificate of the subject. This field is REQUIRED 494 for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both 495 structures are defined in Section 3.2.2). 497 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's 498 public key by a key identifier. When an X.509 certificate is 499 referenced, this key identifier matches the X.509 500 subjectKeyIdentifier extension value. When other certificate 501 formats are referenced, the documents that specify the 502 certificate format and their use with the CMS must include 503 details on matching the key identifier to the appropriate 504 certificate field. This field is RECOMMENDED for TD-TRUSTED- 505 CERTIFIERS (as defined in Section 3.2.2). 507 The trustedCertifiers field of the type PA-PK-AS-REQ contains a list 508 of CAs, trusted by the client, that can be used to certify the KDC. 510 Each ExternalPrincipalIdentifier identifies a CA or a CA certificate 511 (thereby its public key). 513 The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type 514 SignerIdentifier encoded according to [RFC3852]. This field 515 identifies, if present, a particular KDC public key that the client 516 already has. 518 3.2.2. Receipt of Client Request 520 Upon receiving the client's request, the KDC validates it. This 521 section describes the steps that the KDC MUST (unless otherwise 522 noted) take in validating the request. 524 The KDC verifies the client's signature in the signedAuthPack field 525 according to [RFC3852]. 527 If, while validating the client's X.509 certificate [RFC3280], the 528 KDC cannot build a certification path to validate the client's 529 certificate, it sends back a KRB-ERROR [RFC4120] message with the 530 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 531 this error message is a TYPED-DATA (as defined in [RFC4120]) that 532 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 533 whose data-value contains the DER encoding of the type TD-TRUSTED- 534 CERTIFIERS: 536 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 537 ExternalPrincipalIdentifier 538 -- Identifies a list of CAs trusted by the KDC. 539 -- Each ExternalPrincipalIdentifier identifies a CA 540 -- or a CA certificate (thereby its public key). 542 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 543 TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate 544 (thereby its public key) trusted by the KDC. 546 Upon receiving this error message, the client SHOULD retry only if it 547 has a different set of certificates (from those of the previous 548 requests) that form a certification path (or a partial path) from one 549 of the trust anchors acceptable by the KDC to its own certificate. 551 If, while processing the certification path, the KDC determines that 552 the signature on one of the certificates in the signedAuthPack field 553 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 554 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 555 message is a TYPED-DATA that contains an element whose data-type is 556 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 557 encoding of the type TD-INVALID-CERTIFICATES: 559 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 560 ExternalPrincipalIdentifier 561 -- Each ExternalPrincipalIdentifier identifies a 562 -- certificate (sent by the client) with an invalid 563 -- signature. 565 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 566 TD-INVALID-CERTIFICATES structure identifies a certificate (that was 567 sent by the client) with an invalid signature. 569 If more than one X.509 certificate signature is invalid, the KDC MAY 570 include one IssuerAndSerialNumber per invalid signature within the 571 TD-INVALID-CERTIFICATES. 573 The client's X.509 certificate is validated according to [RFC3280]. 575 Based on local policy, the KDC may also check whether any X.509 576 certificates in the certification path validating the client's 577 certificate have been revoked. If any of them have been revoked, the 578 KDC MUST return an error message with the code 579 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 580 revocation status but is unable to do so, it SHOULD return an error 581 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 582 certificate or certificates affected are identified exactly as for 583 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 585 Note that the TD_INVALID_CERTIFICATES error data is only used to 586 identify invalid certificates sent by the client in the request. 588 The client's public key is then used to verify the signature. If the 589 signature fails to verify, the KDC MUST return an error message with 590 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 591 this error message. 593 In addition to validating the client's signature, the KDC MUST also 594 check that the client's public key used to verify the client's 595 signature is bound to the client's principal name as specified in the 596 AS-REQ as follows: 598 1. If the KDC has its own binding between either the client's 599 signature-verification public key or the client's certificate and 600 the client's Kerberos principal name, it uses that binding. 602 2. Otherwise, if the client's X.509 certificate contains a Subject 603 Alternative Name (SAN) extension carrying a KRB5PrincipalName 604 (defined below) in the otherName field of the type GeneralName 605 [RFC3280], it binds the client's X.509 certificate to that name. 607 The type of the otherName field is AnotherName. The type-id field 608 of the type AnotherName is id-pkinit-san: 610 id-pkinit-san OBJECT IDENTIFIER ::= 611 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 612 x509SanAN (2) } 614 And the value field of the type AnotherName is a 615 KRB5PrincipalName. 617 KRB5PrincipalName ::= SEQUENCE { 618 realm [0] Realm, 619 principalName [1] PrincipalName 620 } 622 If the KDC does not have its own binding and there is no 623 KRB5PrincipalName name present in the client's X.509 certificate, or 624 if the Kerberos name in the request does not match the 625 KRB5PrincipalName in the client's X.509 certificate (including the 626 realm name), the KDC MUST return an error message with the code 627 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 628 this error message. 630 Even if the certification path is validated and the certificate is 631 mapped to the client's principal name, the KDC may decide not to 632 accept the client's certificate, depending on local policy. 634 The KDC MAY require the presence of an Extended Key Usage (EKU) 635 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field 636 of the client's X.509 certificate: 638 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= 639 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 640 pkinit(3) keyPurposeClientAuth(4) } 641 -- PKINIT client authentication. 642 -- Key usage bits that MUST be consistent: 643 -- digitalSignature. 645 The digitalSignature key usage bit MUST be asserted when the intended 646 purpose of the client certificate is restricted with the id-pkinit- 647 KPClientAuth EKU. 649 If this EKU KeyPurposeId is required but it is not present or if the 650 client certificate is restricted not to be used for PKINIT client 651 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 652 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 653 is no accompanying e-data for this error message. KDCs implementing 654 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- 655 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 656 are a large number of X.509 client certificates deployed for use with 657 PKINIT which have this EKU. 659 As a matter of local policy, the KDC MAY decide to reject requests on 660 the basis of the absence or presence of other specific EKU OID's. 662 If the digest algorithm used in generating the CA signature for the 663 public key in any certificate of the request is not acceptable by the 664 KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code 665 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be 666 encoded in TYPED-DATA although none is defined at this point. 668 If the client's public key is not accepted with reasons other than 669 what were specified above, the KDC returns a KRB-ERROR [RFC4120] 670 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no 671 accompanying e-data currently defined for this error message. 673 The KDC MUST check the timestamp to ensure that the request is not a 674 replay, and that the time skew falls within acceptable limits. The 675 recommendations for clock skew times in [RFC4120] apply here. If the 676 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 677 KRB_AP_ERR_SKEW, respectively. 679 If the clientPublicValue is filled in, indicating that the client 680 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 681 check to see if the key parameters satisfy its policy. If they do 682 not, it MUST return an error message with the code 683 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 684 TYPED-DATA that contains an element whose data-type is 685 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 686 the type TD-DH-PARAMETERS: 688 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 689 -- Each AlgorithmIdentifier specifies a set of 690 -- Diffie-Hellman domain parameters [IEEE1363]. 691 -- This list is in decreasing preference order. 693 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 694 that the KDC supports in decreasing preference order, from which the 695 client SHOULD pick one to retry the request. 697 The AlgorithmIdentifier structure is defined in [RFC3280] and is 698 filled in according to [RFC3279]. More specifically Section 2.3.3 of 699 [RFC3279] describes how to fill in the AlgorithmIdentifier structure 700 in the case where MODP Diffie-Hellman key exchange is used. 702 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 703 KDC does not possess the corresponding key, the KDC MUST ignore the 704 kdcPkId field as if the client did not include one. 706 If the digest algorithm used by the id-pkinit-authData is not 707 acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] 708 message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. 709 The accompanying e-data MUST be encoded in TYPED-DATA although none 710 is defined at this point. 712 3.2.3. Generation of KDC Reply 714 Assuming that the client's request has been properly validated, the 715 KDC proceeds as per [RFC4120], except as follows. 717 The KDC MUST set the initial flag and include an authorization data 718 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 719 ticket. The ad-data [RFC4120] field contains the DER encoding of the 720 type AD-INITIAL-VERIFIED-CAS: 722 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 723 ExternalPrincipalIdentifier 724 -- Identifies the certification path based on which 725 -- the client certificate was validated. 726 -- Each ExternalPrincipalIdentifier identifies a CA 727 -- or a CA certificate (thereby its public key). 729 The AD-INITIAL-VERIFIED-CAS structure identifies the certification 730 path based on which the client certificate was validated. Each 731 ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- 732 INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate 733 (thereby its public key). 735 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 736 containers if the list of CAs satisfies the AS' realm's local policy 737 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 738 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 739 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 740 resulting ticket. If the list of CAs satisfies the local KDC's 741 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 742 container, otherwise it MAY unwrap the authorization data out of the 743 AD-IF-RELEVANT container. 745 Application servers that understand this authorization data type 746 SHOULD apply local policy to determine whether a given ticket bearing 747 such a type *not* contained within an AD-IF-RELEVANT container is 748 acceptable. (This corresponds to the AP server checking the 749 transited field when the TRANSITED-POLICY-CHECKED flag has not been 750 set [RFC4120].) If such a data type is contained within an AD-IF- 751 RELEVANT container, AP servers MAY apply local policy to determine 752 whether the authorization data is acceptable. 754 A pre-authentication data element, whose padata-type is PA_PK_AS_REP 755 and whose padata-value contains the DER encoding of the type PA-PK- 756 AS-REP (defined below), is included in the AS-REP [RFC4120]. 758 PA-PK-AS-REP ::= CHOICE { 759 dhInfo [0] DHRepInfo, 760 -- Selected when Diffie-Hellman key exchange is 761 -- used. 762 encKeyPack [1] IMPLICIT OCTET STRING, 763 -- Selected when public key encryption is used. 764 -- Contains a CMS type ContentInfo encoded 765 -- according to [RFC3852]. 766 -- The contentType field of the type ContentInfo is 767 -- id-envelopedData (1.2.840.113549.1.7.3). 768 -- The content field is an EnvelopedData. 769 -- The contentType field for the type EnvelopedData 770 -- is id-signedData (1.2.840.113549.1.7.2). 771 -- The eContentType field for the inner type 772 -- SignedData (when unencrypted) is 773 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 774 -- eContent field contains the DER encoding of the 775 -- type ReplyKeyPack. 776 -- ReplyKeyPack is defined in Section 3.2.3.2. 777 ... 778 } 780 DHRepInfo ::= SEQUENCE { 781 dhSignedData [0] IMPLICIT OCTET STRING, 782 -- Contains a CMS type ContentInfo encoded according 783 -- to [RFC3852]. 784 -- The contentType field of the type ContentInfo is 785 -- id-signedData (1.2.840.113549.1.7.2), and the 786 -- content field is a SignedData. 787 -- The eContentType field for the type SignedData is 788 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 789 -- eContent field contains the DER encoding of the 790 -- type KDCDHKeyInfo. 791 -- KDCDHKeyInfo is defined below. 792 serverDHNonce [1] DHNonce OPTIONAL 793 -- Present if and only if dhKeyExpiration is 794 -- present in the KDCDHKeyInfo. 795 } 797 KDCDHKeyInfo ::= SEQUENCE { 798 subjectPublicKey [0] BIT STRING, 799 -- The KDC's DH public key. 800 -- The DH public key value is encoded as a BIT 801 -- STRING according to [RFC3279]. 802 nonce [1] INTEGER (0..4294967295), 803 -- Contains the nonce in the pkAuthenticator field 804 -- in the request if the DH keys are NOT reused, 805 -- 0 otherwise. 806 dhKeyExpiration [2] KerberosTime OPTIONAL, 807 -- Expiration time for KDC's key pair, 808 -- present if and only if the DH keys are reused. 809 -- If present, the KDC's DH public key MUST not be 810 -- used past the point of this expiration time. 811 -- If this field is omitted then the serverDHNonce 812 -- field MUST also be omitted. 813 ... 814 } 816 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 817 KDC encrypts the reply as usual, but not with the client's long-term 818 key. Instead, it encrypts it with either a shared key derived from a 819 Diffie-Hellman exchange, or a generated encryption key. The contents 820 of the PA-PK-AS-REP indicate which key delivery method is used. 822 In addition, the lifetime of the ticket returned by the KDC MUST NOT 823 exceed that of the client's public-private key pair. The ticket 824 lifetime, however, can be shorter than that of the client's public- 825 private key pair. For the implementations of this specification, the 826 lifetime of the client's public-private key pair is the validity 827 period in X.509 certificates [RFC3280], unless configured otherwise. 829 3.2.3.1. Using Diffie-Hellman Key Exchange 831 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 833 The ContentInfo [RFC3852] structure for the dhSignedData field is 834 filled in as follows: 836 1. The contentType field of the type ContentInfo is id-signedData 837 (as defined in [RFC3852]), and the content field is a SignedData 838 (as defined in [RFC3852]). 840 2. The eContentType field for the type SignedData is the OID value 841 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) 842 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS 843 implementers: the signed attribute content-type MUST be present 844 in this SignedData instance and its value is id-pkinit-DHKeyData 845 according to [RFC3852]. 847 3. The eContent field for the type SignedData contains the DER 848 encoding of the type KDCDHKeyInfo. 850 4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce 851 and optionally the expiration time of the KDC's DH key being 852 reused. The subjectPublicKey field of the type KDCDHKeyInfo 853 field identifies KDC's DH public key. This DH public key value 854 is encoded as a BIT STRING according to [RFC3279]. The nonce 855 field contains the nonce in the pkAuthenticator field in the 856 request if the DH keys are NOT reused. The value of this nonce 857 field is 0 if the DH keys are reused. The dhKeyExpiration field 858 is present if and only if the DH keys are reused. If the 859 dhKeyExpiration field is present, the KDC's public key in this 860 KDCDHKeyInfo structure MUST NOT be used past the point of this 861 expiration time. If this field is omitted then the serverDHNonce 862 field MUST also be omitted. 864 5. The signerInfos field of the type SignedData contains a single 865 signerInfo, which contains the signature over the type 866 KDCDHKeyInfo. 868 6. The certificates field of the type SignedData contains 869 certificates intended to facilitate certification path 870 construction, so that the client can verify the KDC's signature 871 over the type KDCDHKeyInfo. The information contained in the 872 trustedCertifiers in the request SHOULD be used by the KDC as 873 hints to guide its selection of an appropriate certificate chain 874 to return to the client. This field may be left empty if the KDC 875 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 876 used for signing. Otherwise, for path validation, these 877 certificates SHOULD be sufficient to construct at least one 878 certification path from the KDC certificate to one trust anchor 879 acceptable by the client [RFC4158]. The KDC MUST be capable of 880 including such a set of certificates if configured to do so. The 881 certificates field MUST NOT contain "root" CA certificates. 883 7. If the client included the clientDHNonce field, then the KDC may 884 choose to reuse its DH keys (see Section 3.2.3.1). If the server 885 reuses DH keys then it MUST include an expiration time in the 886 dhKeyExpiration field. Past the point of the expiration time, 887 the signature over the type DHRepInfo is considered expired/ 888 invalid. When the server reuses DH keys then it MUST include a 889 serverDHNonce at least as long as the length of keys for the 890 symmetric encryption system used to encrypt the AS reply. Note 891 that including the serverDHNonce changes how the client and 892 server calculate the key to use to encrypt the reply; see below 893 for details. The KDC SHOULD NOT reuse DH keys unless the 894 clientDHNonce field is present in the request. 896 The AS reply key is derived as follows: 898 1. Both the KDC and the client calculate the shared secret value as 899 follows: 901 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 902 shared secret value. DHSharedSecret is the value ZZ as 903 described in Section 2.1.1 of [RFC2631]. 905 DHSharedSecret is first padded with leading zeros such that the 906 size of DHSharedSecret in octets is the same as that of the 907 modulus, then represented as a string of octets in big-endian 908 order. 910 Implementation note: Both the client and the KDC can cache the 911 triple (ya, yb, DHSharedSecret), where ya is the client's public 912 key and yb is the KDC's public key. If both ya and yb are the 913 same in a later exchange, the cached DHSharedSecret can be used. 915 2. Let K be the key-generation seed length [RFC3961] of the AS reply 916 key whose enctype is selected according to [RFC4120]. 918 3. Define the function octetstring2key() as follows: 920 octetstring2key(x) == random-to-key(K-truncate( 921 SHA1(0x00 | x) | 922 SHA1(0x01 | x) | 923 SHA1(0x02 | x) | 924 ... 925 )) 927 where x is an octet string; | is the concatenation operator; 0x00, 928 0x01, 0x02, etc., are each represented as a single octet; random- 929 to-key() is an operation that generates a protocol key from a 930 bitstring of length K; and K-truncate truncates its input to the 931 first K bits. Both K and random-to-key() are as defined in the 932 kcrypto profile [RFC3961] for the enctype of the AS reply key. 934 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 935 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 936 strings. 938 5. The AS reply key k is: 940 k = octetstring2key(DHSharedSecret | n_c | n_k) 942 If the hash algorithm used in the key derivation function (currently 943 only octetstring2key() is defined) is not acceptable by the KDC, the 944 KDC MUST return a KRB-ERROR [RFC4120] message with the code 945 KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be 946 encoded in TYPED-DATA although none is defined at this point. 948 3.2.3.2. Using Public Key Encryption 950 In this case, the PA-PK-AS-REP contains an encKeyPack structure where 951 the AS reply key is encrypted. 953 The ContentInfo [RFC3852] structure for the encKeyPack field is 954 filled in as follows: 956 1. The contentType field of the type ContentInfo is id-envelopedData 957 (as defined in [RFC3852]), and the content field is an 958 EnvelopedData (as defined in [RFC3852]). 960 2. The contentType field for the type EnvelopedData is id- 961 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 962 pkcs (1) pkcs7 (7) signedData (2) }. 964 3. The eContentType field for the inner type SignedData (when 965 decrypted from the encryptedContent field for the type 966 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) 967 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. 968 Notes to CMS implementers: the signed attribute content-type MUST 969 be present in this SignedData instance and its value is id- 970 pkinit-rkeyData according to [RFC3852]. 972 4. The eContent field for the inner type SignedData contains the DER 973 encoding of the type ReplyKeyPack (as described below). 975 5. The signerInfos field of the inner type SignedData contains a 976 single signerInfo, which contains the signature for the type 977 ReplyKeyPack. 979 6. The certificates field of the inner type SignedData contains 980 certificates intended to facilitate certification path 981 construction, so that the client can verify the KDC's signature 982 for the type ReplyKeyPack. The information contained in the 983 trustedCertifiers in the request SHOULD be used by the KDC as 984 hints to guide its selection of an appropriate certificate chain 985 to return to the client. This field may be left empty if the KDC 986 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 987 used for signing. Otherwise, for path validation, these 988 certificates SHOULD be sufficient to construct at least one 989 certification path from the KDC certificate to one trust anchor 990 acceptable by the client [RFC4158]. The KDC MUST be capable of 991 including such a set of certificates if configured to do so. The 992 certificates field MUST NOT contain "root" CA certificates. 994 7. The recipientInfos field of the type EnvelopedData is a SET which 995 MUST contain exactly one member of type KeyTransRecipientInfo. 996 The encryptedKey of this member contains the temporary key which 997 is encrypted using the client's public key. 999 8. The unprotectedAttrs or originatorInfo fields of the type 1000 EnvelopedData MAY be present. 1002 If there is a supportedCMSTypes field in the AuthPack, the KDC must 1003 check to see if it supports any of the listed types. If it supports 1004 more than one of the types, the KDC SHOULD use the one listed first. 1005 If it does not support any of them, it MUST return an error message 1006 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 1008 Furthermore the KDC computes the checksum of the AS-REQ in the client 1009 request. This checksum is performed over the type AS-REQ and the 1010 protocol key [RFC3961] of the checksum operation is the replyKey and 1011 the key usage number is 6. If the replyKey's enctype is "newer" 1012 [RFC4120] [RFC4121], the checksum operation is the required checksum 1013 operation [RFC3961] of that enctype. 1015 ReplyKeyPack ::= SEQUENCE { 1016 replyKey [0] EncryptionKey, 1017 -- Contains the session key used to encrypt the 1018 -- enc-part field in the AS-REP, i.e. the 1019 -- AS reply key. 1020 asChecksum [1] Checksum, 1021 -- Contains the checksum of the AS-REQ 1022 -- corresponding to the containing AS-REP. 1023 -- The checksum is performed over the type AS-REQ. 1024 -- The protocol key [RFC3961] of the checksum is the 1025 -- replyKey and the key usage number is 6. 1026 -- If the replyKey's enctype is "newer" [RFC4120] 1027 -- [RFC4121], the checksum is the required 1028 -- checksum operation [RFC3961] for that enctype. 1029 -- The client MUST verify this checksum upon receipt 1030 -- of the AS-REP. 1031 ... 1032 } 1034 Implementations of this RSA encryption key delivery method are 1035 RECOMMENDED to support RSA keys at least 2048 bits in size. 1037 3.2.4. Receipt of KDC Reply 1039 Upon receipt of the KDC's reply, the client proceeds as follows. If 1040 the PA-PK-AS-REP contains the dhSignedData field, the client derives 1041 the AS reply key using the same procedure used by the KDC as defined 1042 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 1043 field, and the client decrypts and extracts the temporary key in the 1044 encryptedKey field of the member KeyTransRecipientInfo, and then uses 1045 that as the AS reply key. 1047 If the public key encryption method is used, the client MUST verify 1048 the asChecksum contained in the ReplyKeyPack. 1050 In either case, the client MUST verify the signature in the 1051 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 1052 be validated according to [RFC3280]. In addition, unless the client 1053 can otherwise verify that the public key used to verify the KDC's 1054 signature is bound to the KDC of the target realm, the KDC's X.509 1055 certificate MUST contain a Subject Alternative Name extension 1056 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as 1057 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 1058 matches the name of the TGS of the target realm (as defined in 1059 Section 7.3 of [RFC4120]). 1061 Unless the client knows by some other means that the KDC certificate 1062 is intended for a Kerberos KDC, the client MUST require that the KDC 1063 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: 1065 id-pkinit-KPKdc OBJECT IDENTIFIER ::= 1066 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1067 pkinit(3) keyPurposeKdc(5) } 1068 -- Signing KDC responses. 1069 -- Key usage bits that MUST be consistent: 1070 -- digitalSignature. 1072 The digitalSignature key usage bit MUST be asserted when the intended 1073 purpose of KDC certificate is restricted with the id-pkinit-KPKdc 1074 EKU. 1076 If the KDC certificate contains the Kerberos TGS name encoded as an 1077 id-pkinit-san SAN, this certificate is certified by the issuing CA as 1078 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. 1080 If all applicable checks are satisfied, the client then decrypts the 1081 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 1082 and then proceeds as described in [RFC4120]. 1084 Implementation note: CAs issuing KDC certificates SHOULD place all 1085 "short" and "fully-qualified" Kerberos realm names of the KDC (one 1086 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 1087 flexibility. 1089 3.3. Interoperability Requirements 1091 The client MUST be capable of sending a set of certificates 1092 sufficient to allow the KDC to construct a certification path for the 1093 client's certificate, if the correct set of certificates is provided 1094 through configuration or policy. 1096 If the client sends all the X.509 certificates on a certification 1097 path to a trust anchor acceptable by the KDC, and the KDC can not 1098 verify the client's public key otherwise, the KDC MUST be able to 1099 process path validation for the client's certificate based on the 1100 certificates in the request. 1102 The KDC MUST be capable of sending a set of certificates sufficient 1103 to allow the client to construct a certification path for the KDC's 1104 certificate, if the correct set of certificates is provided through 1105 configuration or policy. 1107 If the KDC sends all the X.509 certificates on a certification path 1108 to a trust anchor acceptable by the client, and the client can not 1109 verify the KDC's public key otherwise, the client MUST be able to 1110 process path validation for the KDC's certificate based on the 1111 certificates in the reply. 1113 3.4. KDC Indication of PKINIT Support 1115 If pre-authentication is required, but was not present in the 1116 request, per [RFC4120] an error message with the code 1117 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 1118 stored in the e-data field of the KRB-ERROR message to specify which 1119 pre-authentication mechanisms are acceptable. The KDC can then 1120 indicate the support of PKINIT by including an empty element whose 1121 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 1123 Otherwise if it is required by the KDC's local policy that the client 1124 must be pre-authenticated using the pre-authentication mechanism 1125 specified in this document, but no PKINIT pre-authentication was 1126 present in the request, an error message with the code 1127 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 1129 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 1130 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 1131 STRING), and clients MUST ignore this and any other value. Future 1132 extensions to this protocol may specify other data to send instead of 1133 an empty OCTET STRING. 1135 4. Security Considerations 1137 Kerberos error messages are not integrity protected, as a result, the 1138 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered 1139 with by an attacker so that the set of domain parameters selected 1140 could be either weaker or not mutually preferred. Local policy can 1141 configure sets of domain parameters acceptable locally, or disallow 1142 the negotiation of DH domain parameters. 1144 The symmetric reply key size and Diffie-Hellman field size or RSA 1145 modulus size should be chosen so as to provide sufficient 1146 cryptographic security [RFC3766]. 1148 When MODP Diffie-Hellman is used, the exponents should have at least 1149 twice as many bits as the symmetric keys that will be derived from 1150 them [ODL99]. 1152 PKINIT raises certain security considerations beyond those that can 1153 be regulated strictly in protocol definitions. We will address them 1154 in this section. 1156 PKINIT extends the cross-realm model to the public-key 1157 infrastructure. Users of PKINIT must understand security policies 1158 and procedures appropriate to the use of Public Key Infrastructures 1159 [RFC3280]. 1161 In order to trust a KDC certificate that is certified by a CA as a 1162 KDC certificate for a target realm (for example, by asserting the TGS 1163 name of that Kerberos realm as an id-pkinit-san SAN and/or 1164 restricting the certificate usage by using the id-pkinit-KPKdc EKU, 1165 as described in Section 3.2.4), the client MUST verify that the KDC 1166 certificate's issuing CA is authorized to issue KDC certificates for 1167 that target realm. Otherwise, the binding between the KDC 1168 certificate and the KDC of the target realm is not established. 1170 How to validate this authorization is a matter of local policy. A 1171 way to achieve this is the configuration of specific sets of 1172 intermediary CAs and trust anchors, one of which must be on the KDC 1173 certificate's certification path [RFC3280]; and for each CA or trust 1174 anchor the realms for which it is allowed to issue certificates. 1176 In addition, if any CA is trusted to issue KDC certificates can also 1177 issue other kinds of certificates, then local policy must be able to 1178 distinguish between them: for example, it could require that KDC 1179 certificates contain the id-pkinit-KPKdc EKU or that the realm be 1180 specified with the id-pkinit-san SAN. 1182 It is the responsibility of the PKI administrators for an 1183 organization to ensure that KDC certificates are only issued to KDCs, 1184 and that clients can ascertain this using their local policy. 1186 Standard Kerberos allows the possibility of interactions between 1187 cryptosystems of varying strengths; this document adds interactions 1188 with public-key cryptosystems to Kerberos. Some administrative 1189 policies may allow the use of relatively weak public keys. Using 1190 such keys to wrap data encrypted under stronger conventional 1191 cryptosystems may be inappropriate. 1193 PKINIT requires keys for symmetric cryptosystems to be generated. 1194 Some such systems contain "weak" keys. For recommendations regarding 1195 these weak keys, see [RFC4120]. 1197 PKINIT allows the use of the same RSA key pair for encryption and 1198 signing when doing RSA encryption based key delivery. This is not 1199 recommended usage of RSA keys [RFC3447], by using DH based key 1200 delivery this is avoided. 1202 Care should be taken in how certificates are chosen for the purposes 1203 of authentication using PKINIT. Some local policies may require that 1204 key escrow be used for certain certificate types. Deployers of 1205 PKINIT should be aware of the implications of using certificates that 1206 have escrowed keys for the purposes of authentication. Because 1207 signing only certificates are normally not escrowed, by using DH 1208 based key delivery this is avoided. 1210 PKINIT does not provide for a "return routability" test to prevent 1211 attackers from mounting a denial-of-service attack on the KDC by 1212 causing it to perform unnecessary and expensive public-key 1213 operations. Strictly speaking, this is also true of standard 1214 Kerberos, although the potential cost is not as great, because 1215 standard Kerberos does not make use of public-key cryptography. By 1216 using DH based key delivery and reusing DH keys, the necessary crypto 1217 processing cost per request can be minimized. 1219 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1220 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1221 be used if the KDC itself vouches for the user's certificate. 1223 When the Diffie-Hellman key exchange method is used, additional pre- 1224 authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as 1225 defined in this specification) is not bound to the AS_REQ by the 1226 mechanisms discussed in this specification (meaning it may be dropped 1227 or added by attackers without being detected by either the client or 1228 the KDC). Designers of additional pre-authentication data should 1229 take that into consideration if such additional pre-authentication 1230 data can be used in conjunction with the PA_PK_AS_REQ. The future 1231 work of the Kerberos working group is expected to update the hash 1232 algorithms specified in this document and provide a generic mechanism 1233 to bind additional pre-authentication data with the accompanying 1234 AS_REQ. 1236 5. Acknowledgements 1238 The following people have made significant contributions to this 1239 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist 1240 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey 1241 Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M 1242 Grundman and Jeffrey Altman. 1244 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and 1245 Chris Walstad discovered a binding issue between the AS-REQ and AS- 1246 REP in draft -26, the asChecksum field was added as the result. 1248 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1249 Jonathan Trostle who wrote earlier versions of this document. 1251 The authors are indebted to the Kerberos working group chair Jeffrey 1252 Hutzelman who kept track of various issues and was enormously helpful 1253 during the creation of this document. 1255 Some of the ideas on which this document is based arose during 1256 discussions over several years between members of the SAAG, the IETF 1257 CAT working group, and the PSRG, regarding integration of Kerberos 1258 and SPX. Some ideas have also been drawn from the DASS system. 1259 These changes are by no means endorsed by these groups. This is an 1260 attempt to revive some of the goals of those groups, and this 1261 document approaches those goals primarily from the Kerberos 1262 perspective. 1264 Lastly, comments from groups working on similar ideas in DCE have 1265 been invaluable. 1267 6. IANA Considerations 1269 This document has no actions for IANA. 1271 7. References 1272 7.1. Normative References 1274 [IEEE1363] 1275 IEEE, "Standard Specifications for Public Key 1276 Cryptography", IEEE 1363, 2000. 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, March 1997. 1281 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1282 RFC 2412, November 1998. 1284 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1285 RFC 2631, June 1999. 1287 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1288 Identifiers for the Internet X.509 Public Key 1289 Infrastructure Certificate and Certificate Revocation List 1290 (CRL) Profile", RFC 3279, April 2002. 1292 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1293 X.509 Public Key Infrastructure Certificate and 1294 Certificate Revocation List (CRL) Profile", RFC 3280, 1295 April 2002. 1297 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1298 Algorithms", RFC 3370, August 2002. 1300 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1301 Standards (PKCS) #1: RSA Cryptography Specifications 1302 Version 2.1", RFC 3447, February 2003. 1304 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1305 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1306 RFC 3526, May 2003. 1308 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1309 Encryption Algorithm in Cryptographic Message Syntax 1310 (CMS)", RFC 3565, July 2003. 1312 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1313 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1314 RFC 3766, April 2004. 1316 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1317 RFC 3852, July 2004. 1319 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1320 Kerberos 5", RFC 3961, February 2005. 1322 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1323 Encryption for Kerberos 5", RFC 3962, February 2005. 1325 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1326 Kerberos Network Authentication Service (V5)", RFC 4120, 1327 July 2005. 1329 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1330 Version 5 Generic Security Service Application Program 1331 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1332 July 2005. 1334 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1335 Information technology - Abstract Syntax Notation One 1336 (ASN.1): Specification of basic notation. 1338 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1339 Information technology - ASN.1 encoding Rules: Specification 1340 of Basic Encoding Rules (BER), Canonical Encoding Rules 1341 (CER) and Distinguished Encoding Rules (DER). 1343 7.2. Informative References 1345 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1346 Sizes", Journal of Cryptology 14 (2001) 255-293. 1348 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1349 future, Designs, Codes, and Cryptography (1999)". 1351 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 1352 Nicholas, "Internet X.509 Public Key Infrastructure: 1353 Certification Path Building", RFC 4158, September 2005. 1355 Appendix A. PKINIT ASN.1 Module 1357 KerberosV5-PK-INIT-SPEC { 1358 iso(1) identified-organization(3) dod(6) internet(1) 1359 security(5) kerberosV5(2) modules(4) pkinit(5) 1360 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1362 IMPORTS 1363 SubjectPublicKeyInfo, AlgorithmIdentifier 1364 FROM PKIX1Explicit88 { iso (1) 1365 identified-organization (3) dod (6) internet (1) 1366 security (5) mechanisms (5) pkix (7) id-mod (0) 1367 id-pkix1-explicit (18) } 1368 -- As defined in RFC 3280. 1370 KerberosTime, PrincipalName, Realm, EncryptionKey 1371 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1372 dod(6) internet(1) security(5) kerberosV5(2) 1373 modules(4) krb5spec2(2) } ; 1375 id-pkinit OBJECT IDENTIFIER ::= 1376 { iso (1) org (3) dod (6) internet (1) security (5) 1377 kerberosv5 (2) pkinit (3) } 1379 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 } 1380 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 } 1381 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 } 1382 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 } 1383 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 } 1385 id-pkinit-san OBJECT IDENTIFIER ::= 1386 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1387 x509SanAN (2) } 1389 pa-pk-as-req INTEGER ::= 16 1390 pa-pk-as-rep INTEGER ::= 17 1392 ad-initial-verified-cas INTEGER ::= 9 1394 td-trusted-certifiers INTEGER ::= 104 1395 td-invalid-certificates INTEGER ::= 105 1396 td-dh-parameters INTEGER ::= 109 1398 PA-PK-AS-REQ ::= SEQUENCE { 1399 signedAuthPack [0] IMPLICIT OCTET STRING, 1400 -- Contains a CMS type ContentInfo encoded 1401 -- according to [RFC3852]. 1402 -- The contentType field of the type ContentInfo 1403 -- is id-signedData (1.2.840.113549.1.7.2), 1404 -- and the content field is a SignedData. 1405 -- The eContentType field for the type SignedData is 1406 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 1407 -- eContent field contains the DER encoding of the 1408 -- type AuthPack. 1409 -- AuthPack is defined below. 1410 trustedCertifiers [1] SEQUENCE OF 1411 ExternalPrincipalIdentifier OPTIONAL, 1413 -- Contains a list of CAs, trusted by the client, 1414 -- that can be used to certify the KDC. 1415 -- Each ExternalPrincipalIdentifier identifies a CA 1416 -- or a CA certificate (thereby its public key). 1417 -- The information contained in the 1418 -- trustedCertifiers SHOULD be used by the KDC as 1419 -- hints to guide its selection of an appropriate 1420 -- certificate chain to return to the client. 1421 kdcPkId [2] IMPLICIT OCTET STRING 1422 OPTIONAL, 1423 -- Contains a CMS type SignerIdentifier encoded 1424 -- according to [RFC3852]. 1425 -- Identifies, if present, a particular KDC 1426 -- public key that the client already has. 1427 ... 1428 } 1430 DHNonce ::= OCTET STRING 1432 ExternalPrincipalIdentifier ::= SEQUENCE { 1433 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1434 -- Contains a PKIX type Name encoded according to 1435 -- [RFC3280]. 1436 -- Identifies the certificate subject by the 1437 -- distinguished subject name. 1438 -- REQUIRED when there is a distinguished subject 1439 -- name present in the certificate. 1440 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1441 -- Contains a CMS type IssuerAndSerialNumber encoded 1442 -- according to [RFC3852]. 1443 -- Identifies a certificate of the subject. 1444 -- REQUIRED for TD-INVALID-CERTIFICATES and 1445 -- TD-TRUSTED-CERTIFIERS. 1446 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1447 -- Identifies the subject's public key by a key 1448 -- identifier. When an X.509 certificate is 1449 -- referenced, this key identifier matches the X.509 1450 -- subjectKeyIdentifier extension value. When other 1451 -- certificate formats are referenced, the documents 1452 -- that specify the certificate format and their use 1453 -- with the CMS must include details on matching the 1454 -- key identifier to the appropriate certificate 1455 -- field. 1456 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1457 ... 1458 } 1460 AuthPack ::= SEQUENCE { 1461 pkAuthenticator [0] PKAuthenticator, 1462 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1463 -- Type SubjectPublicKeyInfo is defined in 1464 -- [RFC3280]. 1465 -- Specifies Diffie-Hellman domain parameters 1466 -- and the client's public key value [IEEE1363]. 1467 -- The DH public key value is encoded as a BIT 1468 -- STRING according to [RFC3279]. 1469 -- This field is present only if the client wishes 1470 -- to use the Diffie-Hellman key agreement method. 1471 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1472 OPTIONAL, 1473 -- Type AlgorithmIdentifier is defined in 1474 -- [RFC3280]. 1475 -- List of CMS encryption types supported by the 1476 -- client in order of (decreasing) preference. 1477 clientDHNonce [3] DHNonce OPTIONAL, 1478 -- Present only if the client indicates that it 1479 -- wishes to reuse DH keys or to allow the KDC to 1480 -- do so. 1481 ... 1482 } 1484 PKAuthenticator ::= SEQUENCE { 1485 cusec [0] INTEGER (0..999999), 1486 ctime [1] KerberosTime, 1487 -- cusec and ctime are used as in [RFC4120], for 1488 -- replay prevention. 1489 nonce [2] INTEGER (0..4294967295), 1490 -- Chosen randomly; This nonce does not need to 1491 -- match with the nonce in the KDC-REQ-BODY. 1492 paChecksum [3] OCTET STRING, 1493 -- Contains the SHA1 checksum, performed over 1494 -- KDC-REQ-BODY. 1495 ... 1496 } 1498 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1499 ExternalPrincipalIdentifier 1500 -- Identifies a list of CAs trusted by the KDC. 1501 -- Each ExternalPrincipalIdentifier identifies a CA 1502 -- or a CA certificate (thereby its public key). 1504 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1505 ExternalPrincipalIdentifier 1506 -- Each ExternalPrincipalIdentifier identifies a 1507 -- certificate (sent by the client) with an invalid 1508 -- signature. 1510 KRB5PrincipalName ::= SEQUENCE { 1511 realm [0] Realm, 1512 principalName [1] PrincipalName 1513 } 1515 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1516 ExternalPrincipalIdentifier 1517 -- Identifies the certification path based on which 1518 -- the client certificate was validated. 1519 -- Each ExternalPrincipalIdentifier identifies a CA 1520 -- or a CA certificate (thereby its public key). 1522 PA-PK-AS-REP ::= CHOICE { 1523 dhInfo [0] DHRepInfo, 1524 -- Selected when Diffie-Hellman key exchange is 1525 -- used. 1526 encKeyPack [1] IMPLICIT OCTET STRING, 1527 -- Selected when public key encryption is used. 1528 -- Contains a CMS type ContentInfo encoded 1529 -- according to [RFC3852]. 1530 -- The contentType field of the type ContentInfo is 1531 -- id-envelopedData (1.2.840.113549.1.7.3). 1532 -- The content field is an EnvelopedData. 1533 -- The contentType field for the type EnvelopedData 1534 -- is id-signedData (1.2.840.113549.1.7.2). 1535 -- The eContentType field for the inner type 1536 -- SignedData (when unencrypted) is 1537 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 1538 -- eContent field contains the DER encoding of the 1539 -- type ReplyKeyPack. 1540 -- ReplyKeyPack is defined below. 1541 ... 1542 } 1544 DHRepInfo ::= SEQUENCE { 1545 dhSignedData [0] IMPLICIT OCTET STRING, 1546 -- Contains a CMS type ContentInfo encoded according 1547 -- to [RFC3852]. 1548 -- The contentType field of the type ContentInfo is 1549 -- id-signedData (1.2.840.113549.1.7.2), and the 1550 -- content field is a SignedData. 1551 -- The eContentType field for the type SignedData is 1552 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 1553 -- eContent field contains the DER encoding of the 1554 -- type KDCDHKeyInfo. 1555 -- KDCDHKeyInfo is defined below. 1556 serverDHNonce [1] DHNonce OPTIONAL 1557 -- Present if and only if dhKeyExpiration is 1558 -- present. 1559 } 1561 KDCDHKeyInfo ::= SEQUENCE { 1562 subjectPublicKey [0] BIT STRING, 1563 -- The KDC's DH public key. 1564 -- The DH public key value is encoded as a BIT 1565 -- STRING according to [RFC3279]. 1566 nonce [1] INTEGER (0..4294967295), 1567 -- Contains the nonce in the pkAuthenticator field 1568 -- in the request if the DH keys are NOT reused, 1569 -- 0 otherwise. 1570 dhKeyExpiration [2] KerberosTime OPTIONAL, 1571 -- Expiration time for KDC's key pair, 1572 -- present if and only if the DH keys are reused. 1573 -- If present, the KDC's DH public key MUST not be 1574 -- used past the point of this expiration time. 1575 -- If this field is omitted then the serverDHNonce 1576 -- field MUST also be omitted. 1577 ... 1578 } 1580 ReplyKeyPack ::= SEQUENCE { 1581 replyKey [0] EncryptionKey, 1582 -- Contains the session key used to encrypt the 1583 -- enc-part field in the AS-REP, i.e. the 1584 -- AS reply key. 1585 asChecksum [1] Checksum, 1586 -- Contains the checksum of the AS-REQ 1587 -- corresponding to the containing AS-REP. 1588 -- The checksum is performed over the type AS-REQ. 1589 -- The protocol key [RFC3961] of the checksum is the 1590 -- replyKey and the key usage number is 6. 1591 -- If the replyKey's enctype is "newer" [RFC4120] 1592 -- [RFC4121], the checksum is the required 1593 -- checksum operation [RFC3961] for that enctype. 1594 -- The client MUST verify this checksum upon receipt 1595 -- of the AS-REP. 1596 ... 1597 } 1599 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1600 -- Each AlgorithmIdentifier specifies a set of 1601 -- Diffie-Hellman domain parameters [IEEE1363]. 1602 -- This list is in decreasing preference order. 1603 END 1605 Appendix B. Test Vectors 1607 Function octetstring2key() is defined in Section 3.2.3.1. This 1608 section describes a few sets of test vectors that would be useful for 1609 implementers of octetstring2key(). 1611 Set 1 1612 ===== 1613 Input octet string x is: 1615 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1616 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1617 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1618 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1619 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1621 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1622 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1623 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1624 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1625 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1626 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1627 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1628 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1629 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1630 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1632 Output of K-truncate() when the key size is 32 octets: 1634 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1635 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1637 Set 2: 1638 ===== 1639 Input octet string x is: 1641 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1642 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1643 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1644 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1645 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1646 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1647 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1648 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1650 Output of K-truncate() when the key size is 32 octets: 1652 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1653 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1655 Set 3: 1656 ====== 1657 Input octet string x is: 1659 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1660 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1661 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1662 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1663 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1664 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1665 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1666 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1668 Output of K-truncate() when the key size is 32 octets: 1670 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1671 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1673 Set 4: 1674 ===== 1675 Input octet string x is: 1677 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1678 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1679 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1680 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1681 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1683 Output of K-truncate() when the key size is 32 octets: 1685 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 1686 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 1688 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT 1689 Implementations 1691 Earlier revisions of the PKINIT I-D were implemented in various 1692 releases of Microsoft Windows and deployed in fairly large numbers. 1693 To enable the community to better interoperate with systems running 1694 those releases, the following information may be useful. 1696 KDC certificates issued by Windows 2000 Enterprise CAs contain a 1697 dNSName SAN with the DNS name of the host running the KDC, and the 1698 id-kp-serverAuth EKU [RFC3280]. 1700 KDC certificates issued by Windows 2003 Enterprise CAs contain a 1701 dNSName SAN with the DNS name of the host running the KDC, the id-kp- 1702 serverAuth EKU and the id-ms-kp-sc-logon EKU. 1704 It is anticipated that the next release of Windows is already too far 1705 along to allow it to support the issuing KDC certificates with id- 1706 pkinit-san SAN as specified in this RFC. Instead, they will have a 1707 dNSName SAN containing the domain name of the KDC and the intended 1708 purpose of these KDC certificates be restricted by the presence of 1709 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU. 1711 In addition to checking that the above are present in a KDC 1712 certificate, Windows clients verify that the issuer of the KDC 1713 certificate is one of a set of allowed issuers of such certificates, 1714 so those wishing to issue KDC certificates need to configure their 1715 Windows clients appropriately. 1717 Client certificates accepted by Windows 2000 and Windows 2003 Server 1718 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) 1719 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN 1720 contains a UTF8 encoded string whose value is that of the Directory 1721 Service attribute UserPrincipalName of the client account object, and 1722 the purpose of including the id-ms-san-sc-logon-upn SAN in the client 1723 certificate is to validate the client mapping (in other words, the 1724 client's public key is bound to the account that has this 1725 UserPrincipalName value). 1727 It should be noted that all Microsoft Kerberos realm names are domain 1728 style realm names and strictly in upper case. In addition, the 1729 UserPrincipalName attribute is globally unique in Windows 2000 and 1730 Windows 2003. 1732 Authors' Addresses 1734 Larry Zhu 1735 Microsoft Corporation 1736 One Microsoft Way 1737 Redmond, WA 98052 1738 US 1740 Email: lzhu@microsoft.com 1742 Brian Tung 1743 USC Information Sciences Institute 1744 4676 Admiralty Way Suite 1001 1745 Marina del Rey, CA 90292 1746 US 1748 Email: brian@isi.edu 1750 Intellectual Property Statement 1752 The IETF takes no position regarding the validity or scope of any 1753 Intellectual Property Rights or other rights that might be claimed to 1754 pertain to the implementation or use of the technology described in 1755 this document or the extent to which any license under such rights 1756 might or might not be available; nor does it represent that it has 1757 made any independent effort to identify any such rights. Information 1758 on the procedures with respect to rights in RFC documents can be 1759 found in BCP 78 and BCP 79. 1761 Copies of IPR disclosures made to the IETF Secretariat and any 1762 assurances of licenses to be made available, or the result of an 1763 attempt made to obtain a general license or permission for the use of 1764 such proprietary rights by implementers or users of this 1765 specification can be obtained from the IETF on-line IPR repository at 1766 http://www.ietf.org/ipr. 1768 The IETF invites any interested party to bring to its attention any 1769 copyrights, patents or patent applications, or other proprietary 1770 rights that may cover technology that may be required to implement 1771 this standard. Please address the information to the IETF at 1772 ietf-ipr@ietf.org. 1774 Disclaimer of Validity 1776 This document and the information contained herein are provided on an 1777 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1778 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1779 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1780 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1781 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1782 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1784 Copyright Statement 1786 Copyright (C) The Internet Society (2005). This document is subject 1787 to the rights, licenses and restrictions contained in BCP 78, and 1788 except as set forth therein, the authors retain all their rights. 1790 Acknowledgment 1792 Funding for the RFC Editor function is currently provided by the 1793 Internet Society.