idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-32.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 1863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1853. ** 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: 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 (January 11, 2006) is 6678 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 1662 -- Looks like a reference, but probably isn't: '1' on line 1666 -- Looks like a reference, but probably isn't: '2' on line 1651 -- Looks like a reference, but probably isn't: '3' on line 1570 == Unused Reference: 'LENSTRA' is defined on line 1423, 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: July 15, 2006 B. Tung 5 USC Information Sciences Institute 6 January 11, 2006 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-32 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 July 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . 5 52 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Definitions, Requirements, and Constants . . . . . . . . . 6 54 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 6 55 3.1.2. Defined Message and Encryption Types . . . . . . . . . 6 56 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 7 57 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 9 58 3.2.1. Generation of Client Request . . . . . . . . . . . . . 9 59 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 13 60 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 17 61 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24 62 3.3. Interoperability Requirements . . . . . . . . . . . . . . 25 63 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 31 70 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31 71 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 36 72 Appendix C. Miscellaneous Information about Microsoft Windows 73 PKINIT Implementations . . . . . . . . . . . . . . . 38 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 75 Intellectual Property and Copyright Statements . . . . . . . . . . 41 77 1. Introduction 79 The Kerberos V5 protocol [RFC4120] involves use of a trusted third 80 party known as the Key Distribution Center (KDC) to negotiate shared 81 session keys between clients and services and provide mutual 82 authentication between them. 84 The corner-stone of Kerberos V5 is the Ticket and the Authenticator. 85 A Ticket encapsulates a symmetric key (the ticket session key) in an 86 envelope (a public message) intended for a specific service. The 87 contents of the Ticket are encrypted with a symmetric key shared 88 between the service principal and the issuing KDC. The encrypted 89 part of the Ticket contains the client principal name, amongst other 90 items. An Authenticator is a record that can be shown to have been 91 recently generated using the ticket session key in the associated 92 Ticket. The ticket session key is known by the client who requested 93 the ticket. The contents of the Authenticator are encrypted with the 94 associated ticket session key. The encrypted part of an 95 Authenticator contains a timestamp and the client principal name, 96 amongst other items. 98 As shown in Figure 1 below, the Kerberos V5 protocol consists of the 99 following message exchanges between the client and the KDC, and the 100 client and the application service: 102 - The Authentication Service (AS) Exchange 104 The client obtains an "initial" ticket from the Kerberos 105 authentication server (AS), typically a Ticket Granting Ticket 106 (TGT). The AS-REQ message and the AS-REP message are the request 107 and the reply message respectively between the client and the AS. 109 - The Ticket Granting Service (TGS) Exchange 111 The client subsequently uses the TGT to authenticate and request a 112 service ticket for a particular service, from the Kerberos ticket- 113 granting server (TGS). The TGS-REQ message and the TGS-REP 114 message are the request and the reply message respectively between 115 the client and the TGS. 117 - The Client/Server Authentication Protocol (AP) Exchange 119 The client then makes a request with an AP-REQ message, consisting 120 of a service ticket and an authenticator that certifies the 121 client's possession of the ticket session key. The server may 122 optionally reply with an AP-REP message. AP exchanges typically 123 negotiate session specific symmetric keys. 125 Usually, the AS and TGS are integrated in a single device also known 126 as the KDC. 128 Figure 1: The Message Exchanges in the Kerberos V5 Protocol 130 +--------------+ 131 +--------->| KDC | 132 AS-REQ / +-------| | 133 / / +--------------+ 134 / / ^ | 135 / |AS-REP / | 136 | | / TGS-REQ + TGS-REP 137 | | / / 138 | | / / 139 | | / +---------+ 140 | | / / 141 | | / / 142 | | / / 143 | v / v 144 ++-------+------+ +-----------------+ 145 | Client +------------>| Application | 146 | | AP-REQ | Server | 147 | |<------------| | 148 +---------------+ AP-REP +-----------------+ 150 In the AS exchange, the KDC reply contains the ticket session key, 151 amongst other items, that is encrypted using a key (the AS reply key) 152 shared between the client and the KDC. The AS reply key is typically 153 derived from the client's password for human users. Therefore for 154 human users the attack resistance strength of the Kerberos protocol 155 is no stronger than the strength of their passwords. 157 The use of asymmetric cryptography in the form of X.509 certificates 158 [RFC3280] is popular for facilitating non-repudiation and perfect 159 secrecy. An established Public Key Infrastructure (PKI) provides key 160 management and key distribution mechanisms that can be used to 161 establish authentication and secure communication. Adding public-key 162 cryptography to Kerberos provides a nice congruence to public-key 163 protocols, obviates the human users' burden to manage strong 164 passwords, and allows Kerberized applications to take advantage of 165 existing key services and identity management. 167 The advantage afforded by the Kerberos TGT is that the client exposes 168 his long-term secrets only once. The TGT and its associated session 169 key can then be used for any subsequent service ticket requests. One 170 result of this is that all further authentication is independent of 171 the method by which the initial authentication was performed. 172 Consequently, initial authentication provides a convenient place to 173 integrate public-key cryptography into Kerberos authentication. In 174 addition, the use of symmetric cryptography after the initial 175 exchange is preferred for performance. 177 This document describes the methods and data formats using which the 178 client and the KDC can use public and private key pairs to mutually 179 authenticate in the AS exchange and negotiate the AS reply key, known 180 only by the client and the KDC, to encrypt the AS-REP sent by the 181 KDC. 183 2. Conventions Used in This Document 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 In this protocol, both the client and the KDC have a public-private 190 key pair in order to prove their identities to each other over the 191 open network. The term "signature key" is used to refer to the 192 private key of the key pair being used. 194 The encryption key used to encrypt the enc-part field of the KDC-REP 195 in the AS-REP [RFC4120] is referred to as the AS reply key. 197 An empty sequence in an optional field can be either included or 198 omitted: both encodings are permitted and considered equivalent. 200 The term "Modular Exponential Diffie-Hellman" is used to refer to the 201 Diffie-Hellman key exchange as described in [RFC2631], in order to 202 differentiate it from other equivalent representations of the same 203 key agreement algorithm. 205 3. Extensions 207 This section describes extensions to [RFC4120] for supporting the use 208 of public-key cryptography in the initial request for a ticket. 210 Briefly, this document defines the following extensions to [RFC4120]: 212 1. The client indicates the use of public-key authentication by 213 including a special preauthenticator in the initial request. This 214 preauthenticator contains the client's public-key data and a 215 signature. 217 2. The KDC tests the client's request against its authentication 218 policy and trusted Certification Authorities (CAs). 220 3. If the request passes the verification tests, the KDC replies as 221 usual, but the reply is encrypted using either: 223 a. a key generated through a Diffie-Hellman (DH) key exchange 224 [RFC2631] [IEEE1363] with the client, signed using the KDC's 225 signature key; or 227 b. a symmetric encryption key, signed using the KDC's signature 228 key and encrypted using the client's public key. 230 Any keying material required by the client to obtain the 231 encryption key for decrypting the KDC reply is returned in a pre- 232 authentication field accompanying the usual reply. 234 4. The client validates the KDC's signature, obtains the encryption 235 key, decrypts the reply, and then proceeds as usual. 237 Section 3.1 of this document enumerates the required algorithms and 238 necessary extension message types. Section 3.2 describes the 239 extension messages in greater detail. 241 3.1. Definitions, Requirements, and Constants 243 3.1.1. Required Algorithms 245 All PKINIT implementations MUST support the following algorithms: 247 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 248 sha1-96 [RFC3962]. 250 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 252 o AS reply key delivery method: Diffie-Hellman key exchange 253 [RFC2631]. 255 In addition, implementations of this specification MUST be capable of 256 processing the Extended Key Usage (EKU) extension and the id-pkinit- 257 san (as defined in Section 3.2.2) otherName of the Subject 258 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if 259 present. 261 3.1.2. Defined Message and Encryption Types 263 PKINIT makes use of the following new pre-authentication types: 265 PA_PK_AS_REQ 16 266 PA_PK_AS_REP 17 268 PKINIT also makes use of the following new authorization data type: 270 AD_INITIAL_VERIFIED_CAS 9 272 PKINIT introduces the following new error codes: 274 KDC_ERR_CLIENT_NOT_TRUSTED 62 275 KDC_ERR_INVALID_SIG 64 276 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 277 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 278 KDC_ERR_INVALID_CERTIFICATE 71 279 KDC_ERR_REVOKED_CERTIFICATE 72 280 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 281 KDC_ERR_CLIENT_NAME_MISMATCH 75 282 KDC_ERR_INCONSISTENT_KEY_PURPOSE 77 283 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78 284 KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79 285 KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80 287 PKINIT uses the following typed data types for errors: 289 TD_TRUSTED_CERTIFIERS 104 290 TD_INVALID_CERTIFICATES 105 291 TD_DH_PARAMETERS 109 293 The ASN.1 module for all structures defined in this document (plus 294 IMPORT statements for all imported structures) is given in 295 Appendix A. 297 All structures defined in or imported into this document MUST be 298 encoded using Distinguished Encoding Rules (DER) [X680] [X690] 299 (unless otherwise noted). All data structures carried in OCTET 300 STRINGs must be encoded according to the rules specified in 301 corresponding specifications. 303 Interoperability note: Some implementations may not be able to decode 304 wrapped CMS objects encoded with BER; specifically, they may not be 305 able to decode indefinite length encodings. To maximize 306 interoperability, implementers SHOULD encode CMS objects used in 307 PKINIT with DER. 309 3.1.3. Algorithm Identifiers 311 PKINIT does not define, but does make use of, the following algorithm 312 identifiers. 314 PKINIT uses the following algorithm identifier(s) for Modular 315 Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]: 317 dhpublicnumber (as described in [RFC3279]) 319 PKINIT uses the following signature algorithm identifiers as defined 320 in [RFC3279]: 322 sha-1WithRSAEncryption (RSA with SHA1) 323 md5WithRSAEncryption (RSA with MD5) 324 id-dsa-with-sha1 (DSA with SHA1) 326 PKINIT uses the following encryption algorithm identifiers as defined 327 in [RFC3447] for encrypting the temporary key with a public key: 329 rsaEncryption 330 id-RSAES-OAEP 332 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 333 for encrypting the AS reply key with the temporary key: 335 des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370]) 336 rc2-cbc (RC2, CBC mode, as defined in [RFC3370]) 337 id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565]) 339 PKINIT defines the following encryption types, for use in the etype 340 field of the AS-REQ [RFC4120] message to indicate acceptance of the 341 corresponding algorithms that can used by Cryptographic Message 342 Syntax (CMS) [RFC3852] messages in the reply: 344 id-dsa-with-sha1-CmsOID 9 345 -- Indicates that the client supports id-dsa-with-sha1. 346 md5WithRSAEncryption-CmsOID 10 347 -- Indicates that the client supports md5WithRSAEncryption. 348 sha-1WithRSAEncryption-CmsOID 11 349 -- Indicates that the client supports sha-1WithRSAEncryption. 350 rc2-cbc-EnvOID 12 351 -- Indicates that the client supports rc2-cbc. 352 rsaEncryption-EnvOID 13 353 -- Indicates that the client supports rsaEncryption. 354 id-RSAES-OAEP-EnvOID 14 355 -- Indicates that the client supports id-RSAES-OAEP. 356 des-ede3-cbc-EnvOID 15 357 -- Indicates that the client supports des-ede3-cbc. 359 3.2. PKINIT Pre-authentication Syntax and Use 361 This section defines the syntax and use of the various pre- 362 authentication fields employed by PKINIT. 364 3.2.1. Generation of Client Request 366 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 367 in addition, a pre-authentication data element, whose padata-type is 368 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 369 type PA-PK-AS-REQ, is included. 371 PA-PK-AS-REQ ::= SEQUENCE { 372 signedAuthPack [0] IMPLICIT OCTET STRING, 373 -- Contains a CMS type ContentInfo encoded 374 -- according to [RFC3852]. 375 -- The contentType field of the type ContentInfo 376 -- is id-signedData (1.2.840.113549.1.7.2), 377 -- and the content field is a SignedData. 378 -- The eContentType field for the type SignedData is 379 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 380 -- eContent field contains the DER encoding of the 381 -- type AuthPack. 382 -- AuthPack is defined below. 383 trustedCertifiers [1] SEQUENCE OF 384 ExternalPrincipalIdentifier OPTIONAL, 385 -- Contains a list of CAs, trusted by the client, 386 -- that can be used to certify the KDC. 387 -- Each ExternalPrincipalIdentifier identifies a CA 388 -- or a CA certificate (thereby its public key). 389 -- The information contained in the 390 -- trustedCertifiers SHOULD be used by the KDC as 391 -- hints to guide its selection of an appropriate 392 -- certificate chain to return to the client. 393 kdcPkId [2] IMPLICIT OCTET STRING 394 OPTIONAL, 395 -- Contains a CMS type SignerIdentifier encoded 396 -- according to [RFC3852]. 397 -- Identifies, if present, a particular KDC 398 -- public key that the client already has. 399 ... 400 } 402 DHNonce ::= OCTET STRING 404 ExternalPrincipalIdentifier ::= SEQUENCE { 405 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 406 -- Contains a PKIX type Name encoded according to 407 -- [RFC3280]. 408 -- Identifies the certificate subject by the 409 -- distinguished subject name. 410 -- REQUIRED when there is a distinguished subject 411 -- name present in the certificate. 412 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 413 -- Contains a CMS type IssuerAndSerialNumber encoded 414 -- according to [RFC3852]. 415 -- Identifies a certificate of the subject. 416 -- REQUIRED for TD-INVALID-CERTIFICATES and 417 -- TD-TRUSTED-CERTIFIERS. 418 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 419 -- Identifies the subject's public key by a key 420 -- identifier. When an X.509 certificate is 421 -- referenced, this key identifier matches the X.509 422 -- subjectKeyIdentifier extension value. When other 423 -- certificate formats are referenced, the documents 424 -- that specify the certificate format and their use 425 -- with the CMS must include details on matching the 426 -- key identifier to the appropriate certificate 427 -- field. 428 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 429 ... 430 } 432 AuthPack ::= SEQUENCE { 433 pkAuthenticator [0] PKAuthenticator, 434 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 435 -- Type SubjectPublicKeyInfo is defined in 436 -- [RFC3280]. 437 -- Specifies Diffie-Hellman domain parameters 438 -- and the client's public key value [IEEE1363]. 439 -- The DH public key value is encoded as a BIT 440 -- STRING according to [RFC3279]. 441 -- This field is present only if the client wishes 442 -- to use the Diffie-Hellman key agreement method. 443 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 444 OPTIONAL, 445 -- Type AlgorithmIdentifier is defined in 446 -- [RFC3280]. 447 -- List of CMS encryption types supported by the 448 -- client in order of (decreasing) preference. 449 clientDHNonce [3] DHNonce OPTIONAL, 450 -- Present only if the client indicates that it 451 -- wishes to reuse DH keys or to allow the KDC to 452 -- do so (see Section 3.2.3.1). 453 ... 454 } 455 PKAuthenticator ::= SEQUENCE { 456 cusec [0] INTEGER (0..999999), 457 ctime [1] KerberosTime, 458 -- cusec and ctime are used as in [RFC4120], for 459 -- replay prevention. 460 nonce [2] INTEGER (0..4294967295), 461 -- Chosen randomly; This nonce does not need to 462 -- match with the nonce in the KDC-REQ-BODY. 463 paChecksum [3] OCTET STRING OPTIONAL, 464 -- MUST be present. 465 -- Contains the SHA1 checksum, performed over 466 -- KDC-REQ-BODY. 467 ... 468 } 470 The ContentInfo [RFC3852] structure contained in the signedAuthPack 471 field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and 472 is filled out as follows: 474 1. The contentType field of the type ContentInfo is id-signedData 475 (as defined in [RFC3852]), and the content field is a SignedData 476 (as defined in [RFC3852]). 478 2. The eContentType field for the type SignedData is id-pkinit- 479 authData: { iso(1) org(3) dod(6) internet(1) security(5) 480 kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS 481 implementers: the signed attribute content-type MUST be present 482 in this SignedData instance and its value is id-pkinit-authData 483 according to [RFC3852]. 485 3. The eContent field for the type SignedData contains the DER 486 encoding of the type AuthPack. 488 4. The signerInfos field of the type SignedData contains a single 489 signerInfo, which contains the signature over the type AuthPack. 491 5. The AuthPack structure contains a PKAuthenticator, the client 492 public key information, the CMS encryption types supported by the 493 client and a DHNonce. The pkAuthenticator field certifies to the 494 KDC that the client has recent knowledge of the signing key that 495 authenticates the client. The clientPublicValue field specifies 496 Diffie-Hellman domain parameters and the client's public key 497 value. The DH public key value is encoded as a BIT STRING 498 according to [RFC3279]. The clientPublicValue field is present 499 only if the client wishes to use the Diffie-Hellman key agreement 500 method. The supportedCMSTypes field specifies the list of CMS 501 encryption types supported by the client in order of (decreasing) 502 preference. The clientDHNonce field is described later in this 503 section. 505 6. The ctime field in the PKAuthenticator structure contains the 506 current time on the client's host, and the cusec field contains 507 the microsecond part of the client's timestamp. The ctime and 508 cusec fields are used together to specify a reasonably accurate 509 timestamp [RFC4120]. The nonce field is chosen randomly. The 510 paChecksum field MUST be present and it contains a SHA1 checksum 511 that is performed over the KDC-REQ-BODY [RFC4120]. In order to 512 ease future migration from the use of SHA1, the paChecksum field 513 is made optional syntactically: when the request is extended to 514 negotiate hash algorithms, the new client wishing not to use SHA1 515 will send the request in the extended message syntax without the 516 paChecksum field. The KDC conforming to this specification MUST 517 return a KRB-ERROR [RFC4120] message with the code 518 KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That 519 will allow a new client to retry with SHA1 if allowed by the 520 local policy. 522 7. The certificates field of the type SignedData contains 523 certificates intended to facilitate certification path 524 construction, so that the KDC can verify the signature over the 525 type AuthPack. For path validation, these certificates SHOULD be 526 sufficient to construct at least one certification path from the 527 client certificate to one trust anchor acceptable by the KDC 528 [RFC4158]. The client MUST be capable of including such a set of 529 certificates if configured to do so. The certificates field MUST 530 NOT contain "root" CA certificates. 532 8. The client's Diffie-Hellman public value (clientPublicValue) is 533 included if and only if the client wishes to use the Diffie- 534 Hellman key agreement method. The Diffie-Hellman domain 535 parameters [IEEE1363] for the client's public key are specified 536 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 537 and the client's Diffie-Hellman public key value is mapped to a 538 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 539 using the Diffie-Hellman key agreement method, implementations 540 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 541 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 542 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 543 group 16 [RFC3526]. 545 The Diffie-Hellman field size should be chosen so as to provide 546 sufficient cryptographic security [RFC3766]. 548 When MODP Diffie-Hellman is used, the exponents should have at 549 least twice as many bits as the symmetric keys that will be 550 derived from them [ODL99]. 552 9. The client may wish to reuse DH keys or to allow the KDC to do so 553 (see Section 3.2.3.1). If so, then the client includes the 554 clientDHNonce field. This nonce string MUST be as long as the 555 longest key length of the symmetric key types that the client 556 supports. This nonce MUST be chosen randomly. 558 The ExternalPrincipalIdentifier structure is used in this document to 559 identify the subject's public key thereby the subject principal. 560 This structure is filled out as follows: 562 1. The subjectName field contains a PKIX type Name encoded according 563 to [RFC3280]. This field identifies the certificate subject by 564 the distinguished subject name. This field is REQUIRED when 565 there is a distinguished subject name present in the certificate 566 being used. 568 2. The issuerAndSerialNumber field contains a CMS type 569 IssuerAndSerialNumber encoded according to [RFC3852]. This field 570 identifies a certificate of the subject. This field is REQUIRED 571 for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both 572 structures are defined in Section 3.2.2). 574 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's 575 public key by a key identifier. When an X.509 certificate is 576 referenced, this key identifier matches the X.509 577 subjectKeyIdentifier extension value. When other certificate 578 formats are referenced, the documents that specify the 579 certificate format and their use with the CMS must include 580 details on matching the key identifier to the appropriate 581 certificate field. This field is RECOMMENDED for TD-TRUSTED- 582 CERTIFIERS (as defined in Section 3.2.2). 584 The trustedCertifiers field of the type PA-PK-AS-REQ contains a list 585 of CAs, trusted by the client, that can be used to certify the KDC. 586 Each ExternalPrincipalIdentifier identifies a CA or a CA certificate 587 (thereby its public key). 589 The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type 590 SignerIdentifier encoded according to [RFC3852]. This field 591 identifies, if present, a particular KDC public key that the client 592 already has. 594 3.2.2. Receipt of Client Request 596 Upon receiving the client's request, the KDC validates it. This 597 section describes the steps that the KDC MUST (unless otherwise 598 noted) take in validating the request. 600 The KDC verifies the client's signature in the signedAuthPack field 601 according to [RFC3852]. 603 If, while validating the client's X.509 certificate [RFC3280], the 604 KDC cannot build a certification path to validate the client's 605 certificate, it sends back a KRB-ERROR [RFC4120] message with the 606 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 607 this error message is a TYPED-DATA (as defined in [RFC4120]) that 608 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 609 whose data-value contains the DER encoding of the type TD-TRUSTED- 610 CERTIFIERS: 612 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 613 ExternalPrincipalIdentifier 614 -- Identifies a list of CAs trusted by the KDC. 615 -- Each ExternalPrincipalIdentifier identifies a CA 616 -- or a CA certificate (thereby its public key). 618 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 619 TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate 620 (thereby its public key) trusted by the KDC. 622 Upon receiving this error message, the client SHOULD retry only if it 623 has a different set of certificates (from those of the previous 624 requests) that form a certification path (or a partial path) from one 625 of the trust anchors acceptable by the KDC to its own certificate. 627 If, while processing the certification path, the KDC determines that 628 the signature on one of the certificates in the signedAuthPack field 629 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 630 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 631 message is a TYPED-DATA that contains an element whose data-type is 632 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 633 encoding of the type TD-INVALID-CERTIFICATES: 635 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 636 ExternalPrincipalIdentifier 637 -- Each ExternalPrincipalIdentifier identifies a 638 -- certificate (sent by the client) with an invalid 639 -- signature. 641 Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the 642 TD-INVALID-CERTIFICATES structure identifies a certificate (that was 643 sent by the client) with an invalid signature. 645 If more than one X.509 certificate signature is invalid, the KDC MAY 646 include one IssuerAndSerialNumber per invalid signature within the 647 TD-INVALID-CERTIFICATES. 649 The client's X.509 certificate is validated according to [RFC3280]. 651 Based on local policy, the KDC may also check whether any X.509 652 certificates in the certification path validating the client's 653 certificate have been revoked. If any of them have been revoked, the 654 KDC MUST return an error message with the code 655 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 656 revocation status but is unable to do so, it SHOULD return an error 657 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 658 certificate or certificates affected are identified exactly as for 659 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 661 Note that the TD_INVALID_CERTIFICATES error data is only used to 662 identify invalid certificates sent by the client in the request. 664 The client's public key is then used to verify the signature. If the 665 signature fails to verify, the KDC MUST return an error message with 666 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 667 this error message. 669 In addition to validating the client's signature, the KDC MUST also 670 check that the client's public key used to verify the client's 671 signature is bound to the client's principal name as specified in the 672 AS-REQ as follows: 674 1. If the KDC has its own binding between either the client's 675 signature-verification public key or the client's certificate and 676 the client's Kerberos principal name, it uses that binding. 678 2. Otherwise, if the client's X.509 certificate contains a Subject 679 Alternative Name (SAN) extension carrying a KRB5PrincipalName 680 (defined below) in the otherName field of the type GeneralName 681 [RFC3280], it binds the client's X.509 certificate to that name. 683 The type of the otherName field is AnotherName. The type-id field 684 of the type AnotherName is id-pkinit-san: 686 id-pkinit-san OBJECT IDENTIFIER ::= 687 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 688 x509SanAN (2) } 690 And the value field of the type AnotherName is a 691 KRB5PrincipalName. 693 KRB5PrincipalName ::= SEQUENCE { 694 realm [0] Realm, 695 principalName [1] PrincipalName 696 } 698 If the KDC does not have its own binding and there is no 699 KRB5PrincipalName name present in the client's X.509 certificate, or 700 if the Kerberos name in the request does not match the 701 KRB5PrincipalName in the client's X.509 certificate (including the 702 realm name), the KDC MUST return an error message with the code 703 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 704 this error message. 706 Even if the certification path is validated and the certificate is 707 mapped to the client's principal name, the KDC may decide not to 708 accept the client's certificate, depending on local policy. 710 The KDC MAY require the presence of an Extended Key Usage (EKU) 711 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field 712 of the client's X.509 certificate: 714 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= 715 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 716 pkinit(3) keyPurposeClientAuth(4) } 717 -- PKINIT client authentication. 718 -- Key usage bits that MUST be consistent: 719 -- digitalSignature. 721 The digitalSignature key usage bit [RFC3280] MUST be asserted when 722 the intended purpose of the client's X.509 certificate is restricted 723 with the id-pkinit-KPClientAuth EKU. 725 If this EKU KeyPurposeId is required but it is not present or if the 726 client certificate is restricted not to be used for PKINIT client 727 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 728 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 729 is no accompanying e-data for this error message. KDCs implementing 730 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- 731 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 732 are a large number of X.509 client certificates deployed for use with 733 PKINIT which have this EKU. 735 As a matter of local policy, the KDC MAY decide to reject requests on 736 the basis of the absence or presence of other specific EKU OID's. 738 If the digest algorithm used in generating the CA signature for the 739 public key in any certificate of the request is not acceptable by the 740 KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code 741 KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be 742 encoded in TYPED-DATA although none is defined at this point. 744 If the client's public key is not accepted with reasons other than 745 what were specified above, the KDC returns a KRB-ERROR [RFC4120] 746 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no 747 accompanying e-data currently defined for this error message. 749 The KDC MUST check the timestamp to ensure that the request is not a 750 replay, and that the time skew falls within acceptable limits. The 751 recommendations for clock skew times in [RFC4120] apply here. If the 752 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 753 KRB_AP_ERR_SKEW, respectively. 755 If the clientPublicValue is filled in, indicating that the client 756 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 757 check to see if the key parameters satisfy its policy. If they do 758 not, it MUST return an error message with the code 759 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 760 TYPED-DATA that contains an element whose data-type is 761 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 762 the type TD-DH-PARAMETERS: 764 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 765 -- Each AlgorithmIdentifier specifies a set of 766 -- Diffie-Hellman domain parameters [IEEE1363]. 767 -- This list is in decreasing preference order. 769 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 770 that the KDC supports in decreasing preference order, from which the 771 client SHOULD pick one to retry the request. 773 The AlgorithmIdentifier structure is defined in [RFC3280] and is 774 filled in according to [RFC3279]. More specifically Section 2.3.3 of 775 [RFC3279] describes how to fill in the AlgorithmIdentifier structure 776 in the case where MODP Diffie-Hellman key exchange is used. 778 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 779 KDC does not possess the corresponding key, the KDC MUST ignore the 780 kdcPkId field as if the client did not include one. 782 If the digest algorithm used by the id-pkinit-authData is not 783 acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] 784 message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. 785 The accompanying e-data MUST be encoded in TYPED-DATA although none 786 is defined at this point. 788 3.2.3. Generation of KDC Reply 790 If the paChecksum filed in the request is not present, the KDC 791 conforming to this specification MUST return a KRB-ERROR [RFC4120] 792 message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The 793 accompanying e-data MUST be encoded in TYPED-DATA (no error data is 794 defined by this specification). 796 Assuming that the client's request has been properly validated, the 797 KDC proceeds as per [RFC4120], except as follows. 799 The KDC MUST set the initial flag and include an authorization data 800 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 801 ticket. The ad-data [RFC4120] field contains the DER encoding of the 802 type AD-INITIAL-VERIFIED-CAS: 804 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 805 ExternalPrincipalIdentifier 806 -- Identifies the certification path based on which 807 -- the client certificate was validated. 808 -- Each ExternalPrincipalIdentifier identifies a CA 809 -- or a CA certificate (thereby its public key). 811 The AD-INITIAL-VERIFIED-CAS structure identifies the certification 812 path based on which the client certificate was validated. Each 813 ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- 814 INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate 815 (thereby its public key). 817 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 818 containers if the list of CAs satisfies the AS' realm's local policy 819 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 820 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 821 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 822 resulting ticket. If the list of CAs satisfies the local KDC's 823 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 824 container, otherwise it MAY unwrap the authorization data out of the 825 AD-IF-RELEVANT container. 827 Application servers that understand this authorization data type 828 SHOULD apply local policy to determine whether a given ticket bearing 829 such a type *not* contained within an AD-IF-RELEVANT container is 830 acceptable. (This corresponds to the AP server checking the 831 transited field when the TRANSITED-POLICY-CHECKED flag has not been 832 set [RFC4120].) If such a data type is contained within an AD-IF- 833 RELEVANT container, AP servers MAY apply local policy to determine 834 whether the authorization data is acceptable. 836 A pre-authentication data element, whose padata-type is PA_PK_AS_REP 837 and whose padata-value contains the DER encoding of the type PA-PK- 838 AS-REP (defined below), is included in the AS-REP [RFC4120]. 840 PA-PK-AS-REP ::= CHOICE { 841 dhInfo [0] DHRepInfo, 842 -- Selected when Diffie-Hellman key exchange is 843 -- used. 844 encKeyPack [1] IMPLICIT OCTET STRING, 845 -- Selected when public key encryption is used. 846 -- Contains a CMS type ContentInfo encoded 847 -- according to [RFC3852]. 848 -- The contentType field of the type ContentInfo is 849 -- id-envelopedData (1.2.840.113549.1.7.3). 850 -- The content field is an EnvelopedData. 851 -- The contentType field for the type EnvelopedData 852 -- is id-signedData (1.2.840.113549.1.7.2). 853 -- The eContentType field for the inner type 854 -- SignedData (when unencrypted) is 855 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 856 -- eContent field contains the DER encoding of the 857 -- type ReplyKeyPack. 858 -- ReplyKeyPack is defined in Section 3.2.3.2. 859 ... 860 } 862 DHRepInfo ::= SEQUENCE { 863 dhSignedData [0] IMPLICIT OCTET STRING, 864 -- Contains a CMS type ContentInfo encoded according 865 -- to [RFC3852]. 866 -- The contentType field of the type ContentInfo is 867 -- id-signedData (1.2.840.113549.1.7.2), and the 868 -- content field is a SignedData. 869 -- The eContentType field for the type SignedData is 870 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 871 -- eContent field contains the DER encoding of the 872 -- type KDCDHKeyInfo. 873 -- KDCDHKeyInfo is defined below. 874 serverDHNonce [1] DHNonce OPTIONAL, 875 -- Present if and only if dhKeyExpiration is 876 -- present in the KDCDHKeyInfo. 877 ... 878 } 880 KDCDHKeyInfo ::= SEQUENCE { 881 subjectPublicKey [0] BIT STRING, 882 -- The KDC's DH public key. 883 -- The DH public key value is encoded as a BIT 884 -- STRING according to [RFC3279]. 885 nonce [1] INTEGER (0..4294967295), 886 -- Contains the nonce in the pkAuthenticator field 887 -- in the request if the DH keys are NOT reused, 888 -- 0 otherwise. 889 dhKeyExpiration [2] KerberosTime OPTIONAL, 890 -- Expiration time for KDC's key pair, 891 -- present if and only if the DH keys are reused. 892 -- If present, the KDC's DH public key MUST not be 893 -- used past the point of this expiration time. 894 -- If this field is omitted then the serverDHNonce 895 -- field MUST also be omitted. 896 ... 897 } 899 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 900 KDC encrypts the reply as usual, but not with the client's long-term 901 key. Instead, it encrypts it with either a shared key derived from a 902 Diffie-Hellman exchange, or a generated encryption key. The contents 903 of the PA-PK-AS-REP indicate which key delivery method is used. 905 In addition, the lifetime of the ticket returned by the KDC MUST NOT 906 exceed that of the client's public-private key pair. The ticket 907 lifetime, however, can be shorter than that of the client's public- 908 private key pair. For the implementations of this specification, the 909 lifetime of the client's public-private key pair is the validity 910 period in X.509 certificates [RFC3280], unless configured otherwise. 912 3.2.3.1. Using Diffie-Hellman Key Exchange 914 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 916 The ContentInfo [RFC3852] structure for the dhSignedData field is 917 filled in as follows: 919 1. The contentType field of the type ContentInfo is id-signedData 920 (as defined in [RFC3852]), and the content field is a SignedData 921 (as defined in [RFC3852]). 923 2. The eContentType field for the type SignedData is the OID value 924 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) 925 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS 926 implementers: the signed attribute content-type MUST be present 927 in this SignedData instance and its value is id-pkinit-DHKeyData 928 according to [RFC3852]. 930 3. The eContent field for the type SignedData contains the DER 931 encoding of the type KDCDHKeyInfo. 933 4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce 934 and optionally the expiration time of the KDC's DH key being 935 reused. The subjectPublicKey field of the type KDCDHKeyInfo 936 field identifies KDC's DH public key. This DH public key value 937 is encoded as a BIT STRING according to [RFC3279]. The nonce 938 field contains the nonce in the pkAuthenticator field in the 939 request if the DH keys are NOT reused. The value of this nonce 940 field is 0 if the DH keys are reused. The dhKeyExpiration field 941 is present if and only if the DH keys are reused. If the 942 dhKeyExpiration field is present, the KDC's public key in this 943 KDCDHKeyInfo structure MUST NOT be used past the point of this 944 expiration time. If this field is omitted then the serverDHNonce 945 field MUST also be omitted. 947 5. The signerInfos field of the type SignedData contains a single 948 signerInfo, which contains the signature over the type 949 KDCDHKeyInfo. 951 6. The certificates field of the type SignedData contains 952 certificates intended to facilitate certification path 953 construction, so that the client can verify the KDC's signature 954 over the type KDCDHKeyInfo. The information contained in the 955 trustedCertifiers in the request SHOULD be used by the KDC as 956 hints to guide its selection of an appropriate certificate chain 957 to return to the client. This field may be left empty if the KDC 958 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 959 used for signing. Otherwise, for path validation, these 960 certificates SHOULD be sufficient to construct at least one 961 certification path from the KDC certificate to one trust anchor 962 acceptable by the client [RFC4158]. The KDC MUST be capable of 963 including such a set of certificates if configured to do so. The 964 certificates field MUST NOT contain "root" CA certificates. 966 7. If the client included the clientDHNonce field, then the KDC may 967 choose to reuse its DH keys. If the server reuses DH keys then 968 it MUST include an expiration time in the dhKeyExpiration field. 969 Past the point of the expiration time, the signature over the 970 type DHRepInfo is considered expired/invalid. When the server 971 reuses DH keys then it MUST include a serverDHNonce at least as 972 long as the length of keys for the symmetric encryption system 973 used to encrypt the AS reply. Note that including the 974 serverDHNonce changes how the client and server calculate the key 975 to use to encrypt the reply; see below for details. The KDC 976 SHOULD NOT reuse DH keys unless the clientDHNonce field is 977 present in the request. 979 The AS reply key is derived as follows: 981 1. Both the KDC and the client calculate the shared secret value as 982 follows: 984 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 985 shared secret value. DHSharedSecret is the value ZZ as 986 described in Section 2.1.1 of [RFC2631]. 988 DHSharedSecret is first padded with leading zeros such that the 989 size of DHSharedSecret in octets is the same as that of the 990 modulus, then represented as a string of octets in big-endian 991 order. 993 Implementation note: Both the client and the KDC can cache the 994 triple (ya, yb, DHSharedSecret), where ya is the client's public 995 key and yb is the KDC's public key. If both ya and yb are the 996 same in a later exchange, the cached DHSharedSecret can be used. 998 2. Let K be the key-generation seed length [RFC3961] of the AS reply 999 key whose enctype is selected according to [RFC4120]. 1001 3. Define the function octetstring2key() as follows: 1003 octetstring2key(x) == random-to-key(K-truncate( 1004 SHA1(0x00 | x) | 1005 SHA1(0x01 | x) | 1006 SHA1(0x02 | x) | 1007 ... 1008 )) 1010 where x is an octet string; | is the concatenation operator; 0x00, 1011 0x01, 0x02, etc., are each represented as a single octet; random- 1012 to-key() is an operation that generates a protocol key from a 1013 bitstring of length K; and K-truncate truncates its input to the 1014 first K bits. Both K and random-to-key() are as defined in the 1015 kcrypto profile [RFC3961] for the enctype of the AS reply key. 1017 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 1018 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 1019 strings. 1021 5. The AS reply key k is: 1023 k = octetstring2key(DHSharedSecret | n_c | n_k) 1025 3.2.3.2. Using Public Key Encryption 1027 In this case, the PA-PK-AS-REP contains the encKeyPack field where 1028 the AS reply key is encrypted. 1030 The ContentInfo [RFC3852] structure for the encKeyPack field is 1031 filled in as follows: 1033 1. The contentType field of the type ContentInfo is id-envelopedData 1034 (as defined in [RFC3852]), and the content field is an 1035 EnvelopedData (as defined in [RFC3852]). 1037 2. The contentType field for the type EnvelopedData is id- 1038 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 1039 pkcs (1) pkcs7 (7) signedData (2) }. 1041 3. The eContentType field for the inner type SignedData (when 1042 decrypted from the encryptedContent field for the type 1043 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) 1044 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. 1045 Notes to CMS implementers: the signed attribute content-type MUST 1046 be present in this SignedData instance and its value is id- 1047 pkinit-rkeyData according to [RFC3852]. 1049 4. The eContent field for the inner type SignedData contains the DER 1050 encoding of the type ReplyKeyPack (as described below). 1052 5. The signerInfos field of the inner type SignedData contains a 1053 single signerInfo, which contains the signature for the type 1054 ReplyKeyPack. 1056 6. The certificates field of the inner type SignedData contains 1057 certificates intended to facilitate certification path 1058 construction, so that the client can verify the KDC's signature 1059 for the type ReplyKeyPack. The information contained in the 1060 trustedCertifiers in the request SHOULD be used by the KDC as 1061 hints to guide its selection of an appropriate certificate chain 1062 to return to the client. This field may be left empty if the KDC 1063 public key specified by the kdcPkId field in the PA-PK-AS-REQ was 1064 used for signing. Otherwise, for path validation, these 1065 certificates SHOULD be sufficient to construct at least one 1066 certification path from the KDC certificate to one trust anchor 1067 acceptable by the client [RFC4158]. The KDC MUST be capable of 1068 including such a set of certificates if configured to do so. The 1069 certificates field MUST NOT contain "root" CA certificates. 1071 7. The recipientInfos field of the type EnvelopedData is a SET which 1072 MUST contain exactly one member of type KeyTransRecipientInfo. 1073 The encryptedKey of this member contains the temporary key which 1074 is encrypted using the client's public key. 1076 8. The unprotectedAttrs or originatorInfo fields of the type 1077 EnvelopedData MAY be present. 1079 If there is a supportedCMSTypes field in the AuthPack, the KDC must 1080 check to see if it supports any of the listed types. If it supports 1081 more than one of the types, the KDC SHOULD use the one listed first. 1082 If it does not support any of them, it MUST return an error message 1083 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 1085 Furthermore the KDC computes the checksum of the AS-REQ in the client 1086 request. This checksum is performed over the type AS-REQ and the 1087 protocol key [RFC3961] of the checksum operation is the replyKey and 1088 the key usage number is 6. If the replyKey's enctype is "newer" 1089 [RFC4120] [RFC4121], the checksum operation is the required checksum 1090 operation [RFC3961] of that enctype. 1092 ReplyKeyPack ::= SEQUENCE { 1093 replyKey [0] EncryptionKey, 1094 -- Contains the session key used to encrypt the 1095 -- enc-part field in the AS-REP, i.e. the 1096 -- AS reply key. 1097 asChecksum [1] Checksum, 1098 -- Contains the checksum of the AS-REQ 1099 -- corresponding to the containing AS-REP. 1100 -- The checksum is performed over the type AS-REQ. 1101 -- The protocol key [RFC3961] of the checksum is the 1102 -- replyKey and the key usage number is 6. 1103 -- If the replyKey's enctype is "newer" [RFC4120] 1104 -- [RFC4121], the checksum is the required 1105 -- checksum operation [RFC3961] for that enctype. 1106 -- The client MUST verify this checksum upon receipt 1107 -- of the AS-REP. 1108 ... 1109 } 1111 Implementations of this RSA encryption key delivery method are 1112 RECOMMENDED to support RSA keys at least 2048 bits in size. 1114 3.2.4. Receipt of KDC Reply 1116 Upon receipt of the KDC's reply, the client proceeds as follows. If 1117 the PA-PK-AS-REP contains the dhSignedData field, the client derives 1118 the AS reply key using the same procedure used by the KDC as defined 1119 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 1120 field, and the client decrypts and extracts the temporary key in the 1121 encryptedKey field of the member KeyTransRecipientInfo, and then uses 1122 that as the AS reply key. 1124 If the public key encryption method is used, the client MUST verify 1125 the asChecksum contained in the ReplyKeyPack. 1127 In either case, the client MUST verify the signature in the 1128 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 1129 be validated according to [RFC3280]. In addition, unless the client 1130 can otherwise verify that the public key used to verify the KDC's 1131 signature is bound to the KDC of the target realm, the KDC's X.509 1132 certificate MUST contain a Subject Alternative Name extension 1133 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as 1134 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 1135 matches the name of the TGS of the target realm (as defined in 1136 Section 7.3 of [RFC4120]). 1138 Unless the client knows by some other means that the KDC certificate 1139 is intended for a Kerberos KDC, the client MUST require that the KDC 1140 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: 1142 id-pkinit-KPKdc OBJECT IDENTIFIER ::= 1143 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1144 pkinit(3) keyPurposeKdc(5) } 1145 -- Signing KDC responses. 1146 -- Key usage bits that MUST be consistent: 1147 -- digitalSignature. 1149 The digitalSignature key usage bit [RFC3280] MUST be asserted when 1150 the intended purpose of the KDC's X.509 certificate is restricted 1151 with the id-pkinit-KPKdc EKU. 1153 If the KDC certificate contains the Kerberos TGS name encoded as an 1154 id-pkinit-san SAN, this certificate is certified by the issuing CA as 1155 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. 1157 If all applicable checks are satisfied, the client then decrypts the 1158 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 1159 and then proceeds as described in [RFC4120]. 1161 Implementation note: CAs issuing KDC certificates SHOULD place all 1162 "short" and "fully-qualified" Kerberos realm names of the KDC (one 1163 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 1164 flexibility. 1166 3.3. Interoperability Requirements 1168 The client MUST be capable of sending a set of certificates 1169 sufficient to allow the KDC to construct a certification path for the 1170 client's certificate, if the correct set of certificates is provided 1171 through configuration or policy. 1173 If the client sends all the X.509 certificates on a certification 1174 path to a trust anchor acceptable by the KDC, and the KDC can not 1175 verify the client's public key otherwise, the KDC MUST be able to 1176 process path validation for the client's certificate based on the 1177 certificates in the request. 1179 The KDC MUST be capable of sending a set of certificates sufficient 1180 to allow the client to construct a certification path for the KDC's 1181 certificate, if the correct set of certificates is provided through 1182 configuration or policy. 1184 If the KDC sends all the X.509 certificates on a certification path 1185 to a trust anchor acceptable by the client, and the client can not 1186 verify the KDC's public key otherwise, the client MUST be able to 1187 process path validation for the KDC's certificate based on the 1188 certificates in the reply. 1190 3.4. KDC Indication of PKINIT Support 1192 If pre-authentication is required, but was not present in the 1193 request, per [RFC4120] an error message with the code 1194 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 1195 stored in the e-data field of the KRB-ERROR message to specify which 1196 pre-authentication mechanisms are acceptable. The KDC can then 1197 indicate the support of PKINIT by including an empty element whose 1198 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 1200 Otherwise if it is required by the KDC's local policy that the client 1201 must be pre-authenticated using the pre-authentication mechanism 1202 specified in this document, but no PKINIT pre-authentication was 1203 present in the request, an error message with the code 1204 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 1206 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 1207 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 1208 STRING), and clients MUST ignore this and any other value. Future 1209 extensions to this protocol may specify other data to send instead of 1210 an empty OCTET STRING. 1212 4. Security Considerations 1214 Kerberos error messages are not integrity protected, as a result, the 1215 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered 1216 with by an attacker so that the set of domain parameters selected 1217 could be either weaker or not mutually preferred. Local policy can 1218 configure sets of domain parameters acceptable locally, or disallow 1219 the negotiation of DH domain parameters. 1221 The symmetric reply key size and Diffie-Hellman field size or RSA 1222 modulus size should be chosen so as to provide sufficient 1223 cryptographic security [RFC3766]. 1225 When MODP Diffie-Hellman is used, the exponents should have at least 1226 twice as many bits as the symmetric keys that will be derived from 1227 them [ODL99]. 1229 PKINIT raises certain security considerations beyond those that can 1230 be regulated strictly in protocol definitions. We will address them 1231 in this section. 1233 PKINIT extends the cross-realm model to the public-key 1234 infrastructure. Users of PKINIT must understand security policies 1235 and procedures appropriate to the use of Public Key Infrastructures 1236 [RFC3280]. 1238 In order to trust a KDC certificate that is certified by a CA as a 1239 KDC certificate for a target realm (for example, by asserting the TGS 1240 name of that Kerberos realm as an id-pkinit-san SAN and/or 1241 restricting the certificate usage by using the id-pkinit-KPKdc EKU, 1242 as described in Section 3.2.4), the client MUST verify that the KDC 1243 certificate's issuing CA is authorized to issue KDC certificates for 1244 that target realm. Otherwise, the binding between the KDC 1245 certificate and the KDC of the target realm is not established. 1247 How to validate this authorization is a matter of local policy. A 1248 way to achieve this is the configuration of specific sets of 1249 intermediary CAs and trust anchors, one of which must be on the KDC 1250 certificate's certification path [RFC3280]; and for each CA or trust 1251 anchor the realms for which it is allowed to issue certificates. 1253 In addition, if any CA is trusted to issue KDC certificates can also 1254 issue other kinds of certificates, then local policy must be able to 1255 distinguish between them: for example, it could require that KDC 1256 certificates contain the id-pkinit-KPKdc EKU or that the realm be 1257 specified with the id-pkinit-san SAN. 1259 It is the responsibility of the PKI administrators for an 1260 organization to ensure that KDC certificates are only issued to KDCs, 1261 and that clients can ascertain this using their local policy. 1263 Standard Kerberos allows the possibility of interactions between 1264 cryptosystems of varying strengths; this document adds interactions 1265 with public-key cryptosystems to Kerberos. Some administrative 1266 policies may allow the use of relatively weak public keys. Using 1267 such keys to wrap data encrypted under stronger conventional 1268 cryptosystems may be inappropriate. 1270 PKINIT requires keys for symmetric cryptosystems to be generated. 1271 Some such systems contain "weak" keys. For recommendations regarding 1272 these weak keys, see [RFC4120]. 1274 PKINIT allows the use of the same RSA key pair for encryption and 1275 signing when doing RSA encryption based key delivery. This is not 1276 recommended usage of RSA keys [RFC3447], by using DH based key 1277 delivery this is avoided. 1279 Care should be taken in how certificates are chosen for the purposes 1280 of authentication using PKINIT. Some local policies may require that 1281 key escrow be used for certain certificate types. Deployers of 1282 PKINIT should be aware of the implications of using certificates that 1283 have escrowed keys for the purposes of authentication. Because 1284 signing only certificates are normally not escrowed, by using DH 1285 based key delivery this is avoided. 1287 PKINIT does not provide for a "return routability" test to prevent 1288 attackers from mounting a denial-of-service attack on the KDC by 1289 causing it to perform unnecessary and expensive public-key 1290 operations. Strictly speaking, this is also true of standard 1291 Kerberos, although the potential cost is not as great, because 1292 standard Kerberos does not make use of public-key cryptography. By 1293 using DH based key delivery and reusing DH keys, the necessary crypto 1294 processing cost per request can be minimized. 1296 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1297 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1298 be used if the KDC itself vouches for the user's certificate. 1300 When the Diffie-Hellman key exchange method is used, additional pre- 1301 authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as 1302 defined in this specification) is not bound to the AS_REQ by the 1303 mechanisms discussed in this specification (meaning it may be dropped 1304 or added by attackers without being detected by either the client or 1305 the KDC). Designers of additional pre-authentication data should 1306 take that into consideration if such additional pre-authentication 1307 data can be used in conjunction with the PA_PK_AS_REQ. The future 1308 work of the Kerberos working group is expected to update the hash 1309 algorithms specified in this document and provide a generic mechanism 1310 to bind additional pre-authentication data with the accompanying 1311 AS_REQ. 1313 5. Acknowledgements 1315 The following people have made significant contributions to this 1316 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist 1317 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey 1318 Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M 1319 Grundman and Jeffrey Altman. 1321 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and 1322 Chris Walstad discovered a binding issue between the AS-REQ and AS- 1323 REP in draft -26, the asChecksum field was added as the result. 1325 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1326 Jonathan Trostle who wrote earlier versions of this document. 1328 The authors are indebted to the Kerberos working group chair Jeffrey 1329 Hutzelman who kept track of various issues and was enormously helpful 1330 during the creation of this document. 1332 Some of the ideas on which this document is based arose during 1333 discussions over several years between members of the SAAG, the IETF 1334 CAT working group, and the PSRG, regarding integration of Kerberos 1335 and SPX. Some ideas have also been drawn from the DASS system. 1336 These changes are by no means endorsed by these groups. This is an 1337 attempt to revive some of the goals of those groups, and this 1338 document approaches those goals primarily from the Kerberos 1339 perspective. 1341 Lastly, comments from groups working on similar ideas in DCE have 1342 been invaluable. 1344 6. IANA Considerations 1346 This document has no actions for IANA. 1348 7. References 1350 7.1. Normative References 1352 [IEEE1363] 1353 IEEE, "Standard Specifications for Public Key 1354 Cryptography", IEEE 1363, 2000. 1356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, March 1997. 1359 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1360 RFC 2412, November 1998. 1362 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1363 RFC 2631, June 1999. 1365 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1366 Identifiers for the Internet X.509 Public Key 1367 Infrastructure Certificate and Certificate Revocation List 1368 (CRL) Profile", RFC 3279, April 2002. 1370 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1371 X.509 Public Key Infrastructure Certificate and 1372 Certificate Revocation List (CRL) Profile", RFC 3280, 1373 April 2002. 1375 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1376 Algorithms", RFC 3370, August 2002. 1378 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1379 Standards (PKCS) #1: RSA Cryptography Specifications 1380 Version 2.1", RFC 3447, February 2003. 1382 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1383 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1384 RFC 3526, May 2003. 1386 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1387 Encryption Algorithm in Cryptographic Message Syntax 1388 (CMS)", RFC 3565, July 2003. 1390 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1391 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1392 RFC 3766, April 2004. 1394 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1395 RFC 3852, July 2004. 1397 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1398 Kerberos 5", RFC 3961, February 2005. 1400 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1401 Encryption for Kerberos 5", RFC 3962, February 2005. 1403 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1404 Kerberos Network Authentication Service (V5)", RFC 4120, 1405 July 2005. 1407 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1408 Version 5 Generic Security Service Application Program 1409 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1410 July 2005. 1412 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1413 Information technology - Abstract Syntax Notation One 1414 (ASN.1): Specification of basic notation. 1416 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1417 Information technology - ASN.1 encoding Rules: Specification 1418 of Basic Encoding Rules (BER), Canonical Encoding Rules 1419 (CER) and Distinguished Encoding Rules (DER). 1421 7.2. Informative References 1423 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1424 Sizes", Journal of Cryptology 14 (2001) 255-293. 1426 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1427 future, Designs, Codes, and Cryptography (1999)". 1429 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 1430 Nicholas, "Internet X.509 Public Key Infrastructure: 1431 Certification Path Building", RFC 4158, September 2005. 1433 Appendix A. PKINIT ASN.1 Module 1435 KerberosV5-PK-INIT-SPEC { 1436 iso(1) identified-organization(3) dod(6) internet(1) 1437 security(5) kerberosV5(2) modules(4) pkinit(5) 1438 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1440 IMPORTS 1441 SubjectPublicKeyInfo, AlgorithmIdentifier 1442 FROM PKIX1Explicit88 { iso (1) 1443 identified-organization (3) dod (6) internet (1) 1444 security (5) mechanisms (5) pkix (7) id-mod (0) 1445 id-pkix1-explicit (18) } 1446 -- As defined in RFC 3280. 1448 KerberosTime, PrincipalName, Realm, EncryptionKey 1449 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1450 dod(6) internet(1) security(5) kerberosV5(2) 1451 modules(4) krb5spec2(2) } ; 1453 id-pkinit OBJECT IDENTIFIER ::= 1454 { iso (1) org (3) dod (6) internet (1) security (5) 1455 kerberosv5 (2) pkinit (3) } 1457 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 } 1458 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 } 1459 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 } 1460 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 } 1461 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 } 1463 id-pkinit-san OBJECT IDENTIFIER ::= 1464 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1465 x509SanAN (2) } 1467 pa-pk-as-req INTEGER ::= 16 1468 pa-pk-as-rep INTEGER ::= 17 1470 ad-initial-verified-cas INTEGER ::= 9 1472 td-trusted-certifiers INTEGER ::= 104 1473 td-invalid-certificates INTEGER ::= 105 1474 td-dh-parameters INTEGER ::= 109 1476 PA-PK-AS-REQ ::= SEQUENCE { 1477 signedAuthPack [0] IMPLICIT OCTET STRING, 1478 -- Contains a CMS type ContentInfo encoded 1479 -- according to [RFC3852]. 1480 -- The contentType field of the type ContentInfo 1481 -- is id-signedData (1.2.840.113549.1.7.2), 1482 -- and the content field is a SignedData. 1483 -- The eContentType field for the type SignedData is 1484 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 1485 -- eContent field contains the DER encoding of the 1486 -- type AuthPack. 1487 -- AuthPack is defined below. 1488 trustedCertifiers [1] SEQUENCE OF 1489 ExternalPrincipalIdentifier OPTIONAL, 1490 -- Contains a list of CAs, trusted by the client, 1491 -- that can be used to certify the KDC. 1492 -- Each ExternalPrincipalIdentifier identifies a CA 1493 -- or a CA certificate (thereby its public key). 1494 -- The information contained in the 1495 -- trustedCertifiers SHOULD be used by the KDC as 1496 -- hints to guide its selection of an appropriate 1497 -- certificate chain to return to the client. 1498 kdcPkId [2] IMPLICIT OCTET STRING 1499 OPTIONAL, 1500 -- Contains a CMS type SignerIdentifier encoded 1501 -- according to [RFC3852]. 1502 -- Identifies, if present, a particular KDC 1503 -- public key that the client already has. 1504 ... 1506 } 1508 DHNonce ::= OCTET STRING 1510 ExternalPrincipalIdentifier ::= SEQUENCE { 1511 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1512 -- Contains a PKIX type Name encoded according to 1513 -- [RFC3280]. 1514 -- Identifies the certificate subject by the 1515 -- distinguished subject name. 1516 -- REQUIRED when there is a distinguished subject 1517 -- name present in the certificate. 1518 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1519 -- Contains a CMS type IssuerAndSerialNumber encoded 1520 -- according to [RFC3852]. 1521 -- Identifies a certificate of the subject. 1522 -- REQUIRED for TD-INVALID-CERTIFICATES and 1523 -- TD-TRUSTED-CERTIFIERS. 1524 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1525 -- Identifies the subject's public key by a key 1526 -- identifier. When an X.509 certificate is 1527 -- referenced, this key identifier matches the X.509 1528 -- subjectKeyIdentifier extension value. When other 1529 -- certificate formats are referenced, the documents 1530 -- that specify the certificate format and their use 1531 -- with the CMS must include details on matching the 1532 -- key identifier to the appropriate certificate 1533 -- field. 1534 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1535 ... 1536 } 1538 AuthPack ::= SEQUENCE { 1539 pkAuthenticator [0] PKAuthenticator, 1540 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1541 -- Type SubjectPublicKeyInfo is defined in 1542 -- [RFC3280]. 1543 -- Specifies Diffie-Hellman domain parameters 1544 -- and the client's public key value [IEEE1363]. 1545 -- The DH public key value is encoded as a BIT 1546 -- STRING according to [RFC3279]. 1547 -- This field is present only if the client wishes 1548 -- to use the Diffie-Hellman key agreement method. 1549 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1550 OPTIONAL, 1551 -- Type AlgorithmIdentifier is defined in 1552 -- [RFC3280]. 1553 -- List of CMS encryption types supported by the 1554 -- client in order of (decreasing) preference. 1555 clientDHNonce [3] DHNonce OPTIONAL, 1556 -- Present only if the client indicates that it 1557 -- wishes to reuse DH keys or to allow the KDC to 1558 -- do so. 1559 ... 1560 } 1562 PKAuthenticator ::= SEQUENCE { 1563 cusec [0] INTEGER (0..999999), 1564 ctime [1] KerberosTime, 1565 -- cusec and ctime are used as in [RFC4120], for 1566 -- replay prevention. 1567 nonce [2] INTEGER (0..4294967295), 1568 -- Chosen randomly; This nonce does not need to 1569 -- match with the nonce in the KDC-REQ-BODY. 1570 paChecksum [3] OCTET STRING OPTIONAL, 1571 -- MUST be present. 1572 -- Contains the SHA1 checksum, performed over 1573 -- KDC-REQ-BODY. 1574 ... 1575 } 1577 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1578 ExternalPrincipalIdentifier 1579 -- Identifies a list of CAs trusted by the KDC. 1580 -- Each ExternalPrincipalIdentifier identifies a CA 1581 -- or a CA certificate (thereby its public key). 1583 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1584 ExternalPrincipalIdentifier 1585 -- Each ExternalPrincipalIdentifier identifies a 1586 -- certificate (sent by the client) with an invalid 1587 -- signature. 1589 KRB5PrincipalName ::= SEQUENCE { 1590 realm [0] Realm, 1591 principalName [1] PrincipalName 1592 } 1594 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1595 ExternalPrincipalIdentifier 1596 -- Identifies the certification path based on which 1597 -- the client certificate was validated. 1598 -- Each ExternalPrincipalIdentifier identifies a CA 1599 -- or a CA certificate (thereby its public key). 1601 PA-PK-AS-REP ::= CHOICE { 1602 dhInfo [0] DHRepInfo, 1603 -- Selected when Diffie-Hellman key exchange is 1604 -- used. 1605 encKeyPack [1] IMPLICIT OCTET STRING, 1606 -- Selected when public key encryption is used. 1607 -- Contains a CMS type ContentInfo encoded 1608 -- according to [RFC3852]. 1609 -- The contentType field of the type ContentInfo is 1610 -- id-envelopedData (1.2.840.113549.1.7.3). 1611 -- The content field is an EnvelopedData. 1612 -- The contentType field for the type EnvelopedData 1613 -- is id-signedData (1.2.840.113549.1.7.2). 1614 -- The eContentType field for the inner type 1615 -- SignedData (when unencrypted) is 1616 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 1617 -- eContent field contains the DER encoding of the 1618 -- type ReplyKeyPack. 1619 -- ReplyKeyPack is defined below. 1620 ... 1621 } 1623 DHRepInfo ::= SEQUENCE { 1624 dhSignedData [0] IMPLICIT OCTET STRING, 1625 -- Contains a CMS type ContentInfo encoded according 1626 -- to [RFC3852]. 1627 -- The contentType field of the type ContentInfo is 1628 -- id-signedData (1.2.840.113549.1.7.2), and the 1629 -- content field is a SignedData. 1630 -- The eContentType field for the type SignedData is 1631 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 1632 -- eContent field contains the DER encoding of the 1633 -- type KDCDHKeyInfo. 1634 -- KDCDHKeyInfo is defined below. 1635 serverDHNonce [1] DHNonce OPTIONAL, 1636 -- Present if and only if dhKeyExpiration is 1637 -- present. 1638 ... 1639 } 1641 KDCDHKeyInfo ::= SEQUENCE { 1642 subjectPublicKey [0] BIT STRING, 1643 -- The KDC's DH public key. 1644 -- The DH public key value is encoded as a BIT 1645 -- STRING according to [RFC3279]. 1646 nonce [1] INTEGER (0..4294967295), 1647 -- Contains the nonce in the pkAuthenticator field 1648 -- in the request if the DH keys are NOT reused, 1649 -- 0 otherwise. 1651 dhKeyExpiration [2] KerberosTime OPTIONAL, 1652 -- Expiration time for KDC's key pair, 1653 -- present if and only if the DH keys are reused. 1654 -- If present, the KDC's DH public key MUST not be 1655 -- used past the point of this expiration time. 1656 -- If this field is omitted then the serverDHNonce 1657 -- field MUST also be omitted. 1658 ... 1659 } 1661 ReplyKeyPack ::= SEQUENCE { 1662 replyKey [0] EncryptionKey, 1663 -- Contains the session key used to encrypt the 1664 -- enc-part field in the AS-REP, i.e. the 1665 -- AS reply key. 1666 asChecksum [1] Checksum, 1667 -- Contains the checksum of the AS-REQ 1668 -- corresponding to the containing AS-REP. 1669 -- The checksum is performed over the type AS-REQ. 1670 -- The protocol key [RFC3961] of the checksum is the 1671 -- replyKey and the key usage number is 6. 1672 -- If the replyKey's enctype is "newer" [RFC4120] 1673 -- [RFC4121], the checksum is the required 1674 -- checksum operation [RFC3961] for that enctype. 1675 -- The client MUST verify this checksum upon receipt 1676 -- of the AS-REP. 1677 ... 1678 } 1680 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1681 -- Each AlgorithmIdentifier specifies a set of 1682 -- Diffie-Hellman domain parameters [IEEE1363]. 1683 -- This list is in decreasing preference order. 1684 END 1686 Appendix B. Test Vectors 1688 Function octetstring2key() is defined in Section 3.2.3.1. This 1689 section describes a few sets of test vectors that would be useful for 1690 implementers of octetstring2key(). 1692 Set 1 1693 ===== 1694 Input octet string x is: 1696 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1697 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1698 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1699 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1701 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1702 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1703 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1704 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1705 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1706 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1707 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1708 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1709 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1710 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1711 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1713 Output of K-truncate() when the key size is 32 octets: 1715 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1716 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1718 Set 2: 1719 ===== 1720 Input octet string x is: 1722 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1723 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1724 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1725 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1726 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1727 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1728 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1729 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1731 Output of K-truncate() when the key size is 32 octets: 1733 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1734 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1736 Set 3: 1737 ====== 1738 Input octet string x is: 1740 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1741 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1742 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1743 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1744 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1745 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1746 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1747 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1749 Output of K-truncate() when the key size is 32 octets: 1751 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1752 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1754 Set 4: 1755 ===== 1756 Input octet string x is: 1758 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1759 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1760 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1761 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1762 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1764 Output of K-truncate() when the key size is 32 octets: 1766 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 1767 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 1769 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT 1770 Implementations 1772 Earlier revisions of the PKINIT I-D were implemented in various 1773 releases of Microsoft Windows and deployed in fairly large numbers. 1774 To enable the community to better interoperate with systems running 1775 those releases, the following information may be useful. 1777 KDC certificates issued by Windows 2000 Enterprise CAs contain a 1778 dNSName SAN with the DNS name of the host running the KDC, and the 1779 id-kp-serverAuth EKU [RFC3280]. 1781 KDC certificates issued by Windows 2003 Enterprise CAs contain a 1782 dNSName SAN with the DNS name of the host running the KDC, the id-kp- 1783 serverAuth EKU and the id-ms-kp-sc-logon EKU. 1785 It is anticipated that the next release of Windows is already too far 1786 along to allow it to support the issuing KDC certificates with id- 1787 pkinit-san SAN as specified in this RFC. Instead, they will have a 1788 dNSName SAN containing the domain name of the KDC and the intended 1789 purpose of these KDC certificates be restricted by the presence of 1790 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU. 1792 In addition to checking that the above are present in a KDC 1793 certificate, Windows clients verify that the issuer of the KDC 1794 certificate is one of a set of allowed issuers of such certificates, 1795 so those wishing to issue KDC certificates need to configure their 1796 Windows clients appropriately. 1798 Client certificates accepted by Windows 2000 and Windows 2003 Server 1799 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) 1800 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN 1801 contains a UTF8 encoded string whose value is that of the Directory 1802 Service attribute UserPrincipalName of the client account object, and 1803 the purpose of including the id-ms-san-sc-logon-upn SAN in the client 1804 certificate is to validate the client mapping (in other words, the 1805 client's public key is bound to the account that has this 1806 UserPrincipalName value). 1808 It should be noted that all Microsoft Kerberos realm names are domain 1809 style realm names and strictly in upper case. In addition, the 1810 UserPrincipalName attribute is globally unique in Windows 2000 and 1811 Windows 2003. 1813 Authors' Addresses 1815 Larry Zhu 1816 Microsoft Corporation 1817 One Microsoft Way 1818 Redmond, WA 98052 1819 US 1821 Email: lzhu@microsoft.com 1823 Brian Tung 1824 USC Information Sciences Institute 1825 4676 Admiralty Way Suite 1001 1826 Marina del Rey, CA 90292 1827 US 1829 Email: brian@isi.edu 1831 Intellectual Property Statement 1833 The IETF takes no position regarding the validity or scope of any 1834 Intellectual Property Rights or other rights that might be claimed to 1835 pertain to the implementation or use of the technology described in 1836 this document or the extent to which any license under such rights 1837 might or might not be available; nor does it represent that it has 1838 made any independent effort to identify any such rights. Information 1839 on the procedures with respect to rights in RFC documents can be 1840 found in BCP 78 and BCP 79. 1842 Copies of IPR disclosures made to the IETF Secretariat and any 1843 assurances of licenses to be made available, or the result of an 1844 attempt made to obtain a general license or permission for the use of 1845 such proprietary rights by implementers or users of this 1846 specification can be obtained from the IETF on-line IPR repository at 1847 http://www.ietf.org/ipr. 1849 The IETF invites any interested party to bring to its attention any 1850 copyrights, patents or patent applications, or other proprietary 1851 rights that may cover technology that may be required to implement 1852 this standard. Please address the information to the IETF at 1853 ietf-ipr@ietf.org. 1855 Disclaimer of Validity 1857 This document and the information contained herein are provided on an 1858 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1859 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1860 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1861 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1862 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1863 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1865 Copyright Statement 1867 Copyright (C) The Internet Society (2006). This document is subject 1868 to the rights, licenses and restrictions contained in BCP 78, and 1869 except as set forth therein, the authors retain all their rights. 1871 Acknowledgment 1873 Funding for the RFC Editor function is currently provided by the 1874 Internet Society.