idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-29.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 1617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1607. ** 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 -- 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 (October 19, 2005) is 6762 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 1417 -- Looks like a reference, but probably isn't: '1' on line 1420 -- Looks like a reference, but probably isn't: '2' on line 1408 -- Looks like a reference, but probably isn't: '3' on line 1329 == Unused Reference: 'LENSTRA' is defined on line 1188, 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 (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP B. Tung 3 Internet-Draft USC Information Sciences Institute 4 Expires: April 22, 2006 L. Zhu 5 Microsoft Corporation 6 October 19, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-29 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 April 22, 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 . . . . . . . . . 4 54 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 10 60 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14 61 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20 62 3.3. Interoperability Requirements . . . . . . . . . . . . . . 21 63 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 70 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26 71 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 32 72 Appendix C. Miscellaneous Information about Microsoft Windows 73 PKINIT Implementations . . . . . . . . . . . . . . . 33 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 75 Intellectual Property and Copyright Statements . . . . . . . . . . 36 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 3. Extensions 129 This section describes extensions to [RFC4120] for supporting the use 130 of public-key cryptography in the initial request for a ticket. 132 Briefly, this document defines the following extensions to [RFC4120]: 134 1. The client indicates the use of public-key authentication by 135 including a special preauthenticator in the initial request. This 136 preauthenticator contains the client's public-key data and a 137 signature. 139 2. The KDC tests the client's request against its authentication 140 policy and trusted Certification Authorities (CAs). 142 3. If the request passes the verification tests, the KDC replies as 143 usual, but the reply is encrypted using either: 145 a. a key generated through a Diffie-Hellman (DH) key exchange 146 [RFC2631] [IEEE1363] with the client, signed using the KDC's 147 signature key; or 149 b. a symmetric encryption key, signed using the KDC's signature 150 key and encrypted using the client's public key. 152 Any keying material required by the client to obtain the 153 encryption key for decrypting the KDC reply is returned in a pre- 154 authentication field accompanying the usual reply. 156 4. The client validates the KDC's signature, obtains the encryption 157 key, decrypts the reply, and then proceeds as usual. 159 Section 3.1 of this document enumerates the required algorithms and 160 necessary extension message types. Section 3.2 describes the 161 extension messages in greater detail. 163 3.1. Definitions, Requirements, and Constants 165 3.1.1. Required Algorithms 167 All PKINIT implementations MUST support the following algorithms: 169 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 170 sha1-96 [RFC3962]. 172 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 174 o AS reply key delivery method: Diffie-Hellman key exchange 175 [RFC2631]. 177 In addition, implementations of this specification MUST be capable of 178 processing the Extended Key Usage (EKU) extension and the id-pkinit- 179 san (as defined in Section 3.2.2) otherName of the Subject 180 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if 181 present. 183 3.1.2. Defined Message and Encryption Types 185 PKINIT makes use of the following new pre-authentication types: 187 PA_PK_AS_REQ 16 188 PA_PK_AS_REP 17 190 PKINIT also makes use of the following new authorization data type: 192 AD_INITIAL_VERIFIED_CAS 9 194 PKINIT introduces the following new error codes: 196 KDC_ERR_CLIENT_NOT_TRUSTED 62 197 KDC_ERR_INVALID_SIG 64 198 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 199 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 200 KDC_ERR_INVALID_CERTIFICATE 71 201 KDC_ERR_REVOKED_CERTIFICATE 72 202 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 203 KDC_ERR_CLIENT_NAME_MISMATCH 75 204 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 206 PKINIT uses the following typed data types for errors: 208 TD_TRUSTED_CERTIFIERS 104 209 TD_INVALID_CERTIFICATES 105 210 TD_DH_PARAMETERS 109 212 PKINIT defines the following encryption types, for use in the etype 213 field of the AS-REQ [RFC4120] message to indicate acceptance of the 214 corresponding algorithms that can used by Cryptographic Message 215 Syntax (CMS) [RFC3852] messages in the reply: 217 dsaWithSHA1-CmsOID 9 218 -- Indicates that the client supports dsaWithSHA1 219 md5WithRSAEncryption-CmsOID 10 220 -- Indicates that the client supports md5WithRSAEncryption 221 sha1WithRSAEncryption-CmsOID 11 222 -- Indicates that the client supports sha1WithRSAEncryption 223 rc2CBC-EnvOID 12 224 -- Indicates that the client supports rc2CBC 225 rsaEncryption-EnvOID 13 226 -- Indicates that the client supports 227 -- rsaEncryption (PKCS1 v2.1) 228 id-RSAES-OAEP-EnvOID 14 229 -- Indicates that the client supports 230 -- id-RSAES-OAEP (PKCS1 v2.1) 231 des-ede3-cbc-EnvOID 15 232 -- Indicates that the client supports des-ede3-cbc 234 The ASN.1 module for all structures defined in this document (plus 235 IMPORT statements for all imported structures) is given in 236 Appendix A. 238 All structures defined in or imported into this document MUST be 239 encoded using Distinguished Encoding Rules (DER) [X680] [X690] 240 (unless otherwise noted). All data structures carried in OCTET 241 STRINGs must be encoded according to the rules specified in 242 corresponding specifications. 244 Interoperability note: Some implementations may not be able to decode 245 wrapped CMS objects encoded with BER but not DER; specifically, they 246 may not be able to decode infinite length encodings. To maximize 247 interoperability, implementers SHOULD encode CMS objects used in 248 PKINIT with DER. 250 3.1.3. Algorithm Identifiers 252 PKINIT does not define, but does make use of, the following algorithm 253 identifiers. 255 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman 256 key agreement [RFC3279]: 258 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) 260 PKINIT uses the following signature algorithm identifiers [RFC3279]: 262 sha-1WithRSAEncryption (RSA with SHA1) 263 md5WithRSAEncryption (RSA with MD5) 264 id-dsa-with-sha1 (DSA with SHA1) 266 PKINIT uses the following encryption algorithm identifiers [RFC3447] 267 for encrypting the temporary key with a public key: 269 rsaEncryption (PKCS1 v2.1) 270 id-RSAES-OAEP (PKCS1 v2.1) 272 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 273 for encrypting the AS reply key with the temporary key: 275 des-ede3-cbc (three-key 3DES, CBC mode) 276 rc2-cbc (RC2, CBC mode) 277 id-aes256-CBC (AES-256, CBC mode) 279 3.2. PKINIT Pre-authentication Syntax and Use 281 This section defines the syntax and use of the various pre- 282 authentication fields employed by PKINIT. 284 3.2.1. Generation of Client Request 286 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 287 in addition, a pre-authentication data element, whose padata-type is 288 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 289 type PA-PK-AS-REQ, is included. 291 PA-PK-AS-REQ ::= SEQUENCE { 292 signedAuthPack [0] IMPLICIT OCTET STRING, 293 -- Contains a CMS type ContentInfo encoded 294 -- according to [RFC3852]. 295 -- The contentType field of the type ContentInfo 296 -- is id-signedData (1.2.840.113549.1.7.2), 297 -- and the content field is a SignedData. 298 -- The eContentType field for the type SignedData is 299 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 300 -- eContent field contains the DER encoding of the 301 -- type AuthPack. 302 -- AuthPack is defined below. 303 trustedCertifiers [1] SEQUENCE OF 304 ExternalPrincipalIdentifier OPTIONAL, 305 -- A list of CAs, trusted by the client, that can 306 -- be used to certify the KDC. 307 -- Each ExternalPrincipalIdentifier identifies a CA 308 -- or a CA certificate (thereby its public key). 309 -- The information contained in the 310 -- trustedCertifiers SHOULD be used by the KDC as 311 -- hints to guide its selection of an appropriate 312 -- certificate chain to return to the client. 313 kdcPkId [2] IMPLICIT OCTET STRING 314 OPTIONAL, 315 -- Contains a CMS type SignerIdentifier encoded 316 -- according to [RFC3852]. 317 -- Identifies, if present, a particular KDC 318 -- public key that the client already has. 319 ... 320 } 322 DHNonce ::= OCTET STRING 324 ExternalPrincipalIdentifier ::= SEQUENCE { 325 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 326 -- Contains a PKIX type Name encoded according to 327 -- [RFC3280]. 328 -- Identifies the certificate subject by the 329 -- distinguished subject name. 330 -- REQUIRED when there is a distinguished subject 331 -- name present in the certificate. 332 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 333 -- Contains a CMS type IssuerAndSerialNumber encoded 334 -- according to [RFC3852]. 335 -- Identifies a certificate of the subject. 336 -- REQUIRED for TD-INVALID-CERTIFICATES and 337 -- TD-TRUSTED-CERTIFIERS. 338 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 339 -- Identifies the subject's public key by a key 340 -- identifier. When an X.509 certificate is 341 -- referenced, this key identifier matches the X.509 342 -- subjectKeyIdentifier extension value. When other 343 -- certificate formats are referenced, the documents 344 -- that specify the certificate format and their use 345 -- with the CMS must include details on matching the 346 -- key identifier to the appropriate certificate 347 -- field. 348 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 349 ... 350 } 352 AuthPack ::= SEQUENCE { 353 pkAuthenticator [0] PKAuthenticator, 354 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 355 -- Type SubjectPublicKeyInfo is defined in 356 -- [RFC3280]. 357 -- Specifies Diffie-Hellman domain parameters 358 -- and the client's public key value [IEEE1363]. 359 -- The DH public key value is encoded as a BIT 360 -- STRING according to [RFC3279]. 361 -- This field is present only if the client wishes 362 -- to use the Diffie-Hellman key agreement method. 363 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 364 OPTIONAL, 365 -- Type AlgorithmIdentifier is defined in 366 -- [RFC3280]. 367 -- List of CMS encryption types supported by the 368 -- client in order of (decreasing) preference. 369 clientDHNonce [3] DHNonce OPTIONAL, 370 -- Present only if the client indicates that it 371 -- wishes to reuse DH keys or to allow the KDC to 372 -- do so (see Section 3.2.3.1). 373 ... 374 } 376 PKAuthenticator ::= SEQUENCE { 377 cusec [0] INTEGER (0..999999), 378 ctime [1] KerberosTime, 379 -- cusec and ctime are used as in [RFC4120], for 380 -- replay prevention. 381 nonce [2] INTEGER (0..4294967295), 382 -- Chosen randomly; This nonce does not need to 383 -- match with the nonce in the KDC-REQ-BODY. 384 paChecksum [3] OCTET STRING, 385 -- Contains the SHA1 checksum, performed over 386 -- KDC-REQ-BODY. 387 ... 388 } 390 The ContentInfo [RFC3852] structure for the signedAuthPack field is 391 filled out as follows: 393 1. The contentType field of the type ContentInfo is id-signedData 394 (as defined in [RFC3852]), and the content field is a SignedData 395 (as defined in [RFC3852]). 397 2. The eContentType field for the type SignedData is id-pkinit- 398 authData: { iso(1) org(3) dod(6) internet(1) security(5) 399 kerberosv5(2) pkinit(3) authData(1) }. 401 3. The eContent field for the type SignedData contains the DER 402 encoding of the type AuthPack. 404 4. The signerInfos field of the type SignedData contains a single 405 signerInfo, which contains the signature over the type AuthPack. 407 5. The certificates field of the type SignedData contains 408 certificates intended to facilitate certification path 409 construction, so that the KDC can verify the signature over the 410 type AuthPack. For path validation, these certificates SHOULD be 411 sufficient to construct at least one certification path from the 412 client certificate to one trust anchor acceptable by the KDC 413 [CAPATH]. The client MUST be capable of including such a set of 414 certificates if configured to do so. The certificates field MUST 415 NOT contain "root" CA certificates. 417 6. The client's Diffie-Hellman public value (clientPublicValue) is 418 included if and only if the client wishes to use the Diffie- 419 Hellman key agreement method. The Diffie-Hellman domain 420 parameters [IEEE1363] for the client's public key are specified 421 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 422 and the client's Diffie-Hellman public key value is mapped to a 423 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 424 using the Diffie-Hellman key agreement method, implementations 425 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 426 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 427 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 428 group 16 [RFC3526]. 430 The Diffie-Hellman field size should be chosen so as to provide 431 sufficient cryptographic security [RFC3766]. 433 When MODP Diffie-Hellman is used, the exponents should have at 434 least twice as many bits as the symmetric keys that will be 435 derived from them [ODL99]. 437 7. The client may wish to reuse DH keys or to allow the KDC to do so 438 (see Section 3.2.3.1). If so, then the client includes the 439 clientDHNonce field. This nonce string needs to be as long as 440 the longest key length of the symmetric key types that the client 441 supports. This nonce MUST be chosen randomly. 443 3.2.2. Receipt of Client Request 445 Upon receiving the client's request, the KDC validates it. This 446 section describes the steps that the KDC MUST (unless otherwise 447 noted) take in validating the request. 449 The KDC verifies the client's signature in the signedAuthPack field 450 according to [RFC3852]. 452 If, while validating the client's X.509 certificate [RFC3280], the 453 KDC cannot build a certification path to validate the client's 454 certificate, it sends back a KRB-ERROR [RFC4120] message with the 455 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 456 this error message is a TYPED-DATA (as defined in [RFC4120]) that 457 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 458 whose data-value contains the DER encoding of the type TD-TRUSTED- 459 CERTIFIERS: 461 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 462 ExternalPrincipalIdentifier 463 -- Identifies a list of CAs trusted by the KDC. 464 -- Each ExternalPrincipalIdentifier identifies a CA 465 -- or a CA certificate (thereby its public key). 467 Upon receiving this error message, the client SHOULD retry only if it 468 has a different set of certificates (from those of the previous 469 requests) that form a certification path (or a partial path) from one 470 of the trust anchors acceptable by the KDC to its own certificate. 472 If, while processing the certification path, the KDC determines that 473 the signature on one of the certificates in the signedAuthPack field 474 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 475 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 476 message is a TYPED-DATA that contains an element whose data-type is 477 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 478 encoding of the type TD-INVALID-CERTIFICATES: 480 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 481 ExternalPrincipalIdentifier 482 -- Each ExternalPrincipalIdentifier identifies a 483 -- certificate (sent by the client) with an invalid 484 -- signature. 486 If more than one X.509 certificate signature is invalid, the KDC MAY 487 include one IssuerAndSerialNumber per invalid signature within the 488 TD-INVALID-CERTIFICATES. 490 The client's X.509 certificate is validated according to [RFC3280]. 492 Based on local policy, the KDC may also check whether any X.509 493 certificates in the certification path validating the client's 494 certificate have been revoked. If any of them have been revoked, the 495 KDC MUST return an error message with the code 496 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 497 revocation status but is unable to do so, it SHOULD return an error 498 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 499 certificate or certificates affected are identified exactly as for 500 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 502 Note that the TD_INVALID_CERTIFICATES error data is only used to 503 identify invalid certificates sent by the client in the request. 505 The client's public key is then used to verify the signature. If the 506 signature fails to verify, the KDC MUST return an error message with 507 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 508 this error message. 510 In addition to validating the client's signature, the KDC MUST also 511 check that the client's public key used to verify the client's 512 signature is bound to the client's principal name as specified in the 513 AS-REQ as follows: 515 1. If the KDC has its own binding between either the client's 516 signature-verification public key or the client's certificate and 517 the client's Kerberos principal name, it uses that binding. 519 2. Otherwise, if the client's X.509 certificate contains a Subject 520 Alternative Name (SAN) extension carrying a KRB5PrincipalName 521 (defined below) in the otherName field of the type GeneralName 522 [RFC3280], it binds the client's X.509 certificate to that name. 524 The type of the otherName field is AnotherName. The type-id field 525 of the type AnotherName is id-pkinit-san: 527 id-pkinit-san OBJECT IDENTIFIER ::= 528 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 529 x509SanAN (2) } 531 And the value field of the type AnotherName is a 532 KRB5PrincipalName. 534 KRB5PrincipalName ::= SEQUENCE { 535 realm [0] Realm, 536 principalName [1] PrincipalName 537 } 539 If the KDC does not have its own binding and there is no 540 KRB5PrincipalName name present in the client's X.509 certificate, or 541 if the Kerberos name in the request does not match the 542 KRB5PrincipalName in the client's X.509 certificate (including the 543 realm name), the KDC MUST return an error message with the code 544 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 545 this error message. 547 Even if the certification path is validated and the certificate is 548 mapped to the client's principal name, the KDC may decide not to 549 accept the client's certificate, depending on local policy. 551 The KDC MAY require the presence of an Extended Key Usage (EKU) 552 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field 553 of the client's X.509 certificate: 555 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= 556 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 557 pkinit(3) keyPurposeClientAuth(4) } 558 -- PKINIT client authentication. 559 -- Key usage bits that MUST be consistent: 560 -- digitalSignature. 562 If this EKU KeyPurposeId is required but it is not present or if the 563 client certificate is restricted not to be used for PKINIT client 564 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 565 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 566 is no accompanying e-data for this error message. KDCs implementing 567 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- 568 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 569 are a large number of X.509 client certificates deployed for use with 570 PKINIT which have this EKU. 572 As a matter of local policy, the KDC MAY decide to reject requests on 573 the basis of the absence or presence of other specific EKU OID's. 575 If the client's public key is not accepted, the KDC returns an error 576 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. 578 The KDC MUST check the timestamp to ensure that the request is not a 579 replay, and that the time skew falls within acceptable limits. The 580 recommendations for clock skew times in [RFC4120] apply here. If the 581 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 582 KRB_AP_ERR_SKEW, respectively. 584 If the clientPublicValue is filled in, indicating that the client 585 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 586 check to see if the key parameters satisfy its policy. If they do 587 not, it MUST return an error message with the code 588 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 589 TYPED-DATA that contains an element whose data-type is 590 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 591 the type TD-DH-PARAMETERS: 593 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 594 -- Each AlgorithmIdentifier specifies a set of 595 -- Diffie-Hellman domain parameters [IEEE1363]. 596 -- This list is in decreasing preference order. 598 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 599 that the KDC supports in decreasing preference order, from which the 600 client SHOULD pick one to retry the request. 602 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 603 KDC does not possess the corresponding key, the KDC MUST ignore the 604 kdcPkId field as if the client did not include one. 606 If there is a supportedCMSTypes field in the AuthPack, the KDC must 607 check to see if it supports any of the listed types. If it supports 608 more than one of the types, the KDC SHOULD use the one listed first. 609 If it does not support any of them, it MUST return an error message 610 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 612 3.2.3. Generation of KDC Reply 614 Assuming that the client's request has been properly validated, the 615 KDC proceeds as per [RFC4120], except as follows. 617 The KDC MUST set the initial flag and include an authorization data 618 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 619 ticket. The ad-data [RFC4120] field contains the DER encoding of the 620 type AD-INITIAL-VERIFIED-CAS: 622 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 623 ExternalPrincipalIdentifier 624 -- Identifies the certification path based on which 625 -- the client certificate was validated. 626 -- Each ExternalPrincipalIdentifier identifies a CA 627 -- or a CA certificate (thereby its public key). 629 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 630 containers if the list of CAs satisfies the AS' realm's local policy 631 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 632 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 633 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 634 resulting ticket. If the list of CAs satisfies the local KDC's 635 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 636 container, otherwise it MAY unwrap the authorization data out of the 637 AD-IF-RELEVANT container. 639 Application servers that understand this authorization data type 640 SHOULD apply local policy to determine whether a given ticket bearing 641 such a type *not* contained within an AD-IF-RELEVANT container is 642 acceptable. (This corresponds to the AP server checking the 643 transited field when the TRANSITED-POLICY-CHECKED flag has not been 644 set [RFC4120].) If such a data type is contained within an AD-IF- 645 RELEVANT container, AP servers MAY apply local policy to determine 646 whether the authorization data is acceptable. 648 A pre-authentication data element, whose padata-type is PA_PK_AS_REP 649 and whose padata-value contains the DER encoding of the type PA-PK- 650 AS-REP (defined below), is included in the AS-REP [RFC4120]. 652 PA-PK-AS-REP ::= CHOICE { 653 dhInfo [0] DHRepInfo, 654 -- Selected when Diffie-Hellman key exchange is 655 -- used. 656 encKeyPack [1] IMPLICIT OCTET STRING, 657 -- Selected when public key encryption is used. 658 -- Contains a CMS type ContentInfo encoded 659 -- according to [RFC3852]. 660 -- The contentType field of the type ContentInfo is 661 -- id-envelopedData (1.2.840.113549.1.7.3). 662 -- The content field is an EnvelopedData. 663 -- The contentType field for the type EnvelopedData 664 -- is id-signedData (1.2.840.113549.1.7.2). 665 -- The eContentType field for the inner type 666 -- SignedData (when unencrypted) is 667 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 668 -- eContent field contains the DER encoding of the 669 -- type ReplyKeyPack. 670 -- ReplyKeyPack is defined in Section 3.2.3.2. 671 ... 672 } 674 DHRepInfo ::= SEQUENCE { 675 dhSignedData [0] IMPLICIT OCTET STRING, 676 -- Contains a CMS type ContentInfo encoded according 677 -- to [RFC3852]. 678 -- The contentType field of the type ContentInfo is 679 -- id-signedData (1.2.840.113549.1.7.2), and the 680 -- content field is a SignedData. 681 -- The eContentType field for the type SignedData is 682 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 683 -- eContent field contains the DER encoding of the 684 -- type KDCDHKeyInfo. 685 -- KDCDHKeyInfo is defined below. 686 serverDHNonce [1] DHNonce OPTIONAL 687 -- Present if and only if dhKeyExpiration is 688 -- present in the KDCDHKeyInfo. 689 } 691 KDCDHKeyInfo ::= SEQUENCE { 692 subjectPublicKey [0] BIT STRING, 693 -- KDC's DH public key. 694 -- The DH public key value is encoded as a BIT 695 -- STRING according to [RFC3279]. 696 nonce [1] INTEGER (0..4294967295), 697 -- Contains the nonce in the PKAuthenticator of the 698 -- request if DH keys are NOT reused, 699 -- 0 otherwise. 700 dhKeyExpiration [2] KerberosTime OPTIONAL, 701 -- Expiration time for KDC's key pair, 702 -- present if and only if DH keys are reused. If 703 -- this field is omitted then the serverDHNonce 704 -- field MUST also be omitted. See Section 3.2.3.1. 705 ... 706 } 708 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 709 KDC encrypts the reply as usual, but not with the client's long-term 710 key. Instead, it encrypts it with either a shared key derived from a 711 Diffie-Hellman exchange, or a generated encryption key. The contents 712 of the PA-PK-AS-REP indicate which key delivery method is used. 714 In addition, the lifetime of the ticket returned by the KDC MUST NOT 715 exceed that of the client's public-private key pair. The ticket 716 lifetime, however, can be shorter than that of the client's public- 717 private key pair. For the implementations of this specification, the 718 lifetime of the client's public-private key pair is the validity 719 period in X.509 certificates [RFC3280], unless configured otherwise. 721 3.2.3.1. Using Diffie-Hellman Key Exchange 723 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 725 The ContentInfo [RFC3852] structure for the dhSignedData field is 726 filled in as follows: 728 1. The contentType field of the type ContentInfo is id-signedData 729 (as defined in [RFC3852]), and the content field is a SignedData 730 (as defined in [RFC3852]). 732 2. The eContentType field for the type SignedData is the OID value 733 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) 734 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. 736 3. The eContent field for the type SignedData contains the DER 737 encoding of the type KDCDHKeyInfo. 739 4. The signerInfos field of the type SignedData contains a single 740 signerInfo, which contains the signature over the type 741 KDCDHKeyInfo. 743 5. The certificates field of the type SignedData contains 744 certificates intended to facilitate certification path 745 construction, so that the client can verify the KDC's signature 746 over the type KDCDHKeyInfo. The information contained in the 747 trustedCertifiers in the request SHOULD be used by the KDC as 748 hints to guide its selection of an appropriate certificate chain 749 to return to the client. This field may only. be left empty if 750 the KDC public key specified by the kdcPkId field in the PA-PK- 751 AS-REQ was used for signing. Otherwise, for path validation, 752 these certificates SHOULD be sufficient to construct at least one 753 certification path from the KDC certificate to one trust anchor 754 acceptable by the client [CAPATH]. The KDC MUST be capable of 755 including such a set of certificates if configured to do so. The 756 certificates field MUST NOT contain "root" CA certificates. 758 6. If the client included the clientDHNonce field, then the KDC may 759 choose to reuse its DH keys (see Section 3.2.3.1). If the server 760 reuses DH keys then it MUST include an expiration time in the 761 dhKeyExpiration field. Past the point of the expiration time, 762 the signature over the type DHRepInfo is considered expired/ 763 invalid. When the server reuses DH keys then it MUST include a 764 serverDHNonce at least as long as the length of keys for the 765 symmetric encryption system used to encrypt the AS reply. Note 766 that including the serverDHNonce changes how the client and 767 server calculate the key to use to encrypt the reply; see below 768 for details. The KDC SHOULD NOT reuse DH keys unless the 769 clientDHNonce field is present in the request. 771 The AS reply key is derived as follows: 773 1. Both the KDC and the client calculate the shared secret value as 774 follows: 776 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 777 shared secret value. DHSharedSecret is the value ZZ as 778 described in Section 2.1.1 of [RFC2631]. 780 DHSharedSecret is first padded with leading zeros such that the 781 size of DHSharedSecret in octets is the same as that of the 782 modulus, then represented as a string of octets in big-endian 783 order. 785 Implementation note: Both the client and the KDC can cache the 786 triple (ya, yb, DHSharedSecret), where ya is the client's public 787 key and yb is the KDC's public key. If both ya and yb are the 788 same in a later exchange, the cached DHSharedSecret can be used. 790 2. Let K be the key-generation seed length [RFC3961] of the AS reply 791 key whose enctype is selected according to [RFC4120]. 793 3. Define the function octetstring2key() as follows: 795 octetstring2key(x) == random-to-key(K-truncate( 796 SHA1(0x00 | x) | 797 SHA1(0x01 | x) | 798 SHA1(0x02 | x) | 799 ... 800 )) 802 where x is an octet string; | is the concatenation operator; 0x00, 803 0x01, 0x02, etc., are each represented as a single octet; random- 804 to-key() is an operation that generates a protocol key from a 805 bitstring of length K; and K-truncate truncates its input to the 806 first K bits. Both K and random-to-key() are as defined in the 807 kcrypto profile [RFC3961] for the enctype of the AS reply key. 809 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 810 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 811 strings. 813 5. The AS reply key k is: 815 k = octetstring2key(DHSharedSecret | n_c | n_k) 817 3.2.3.2. Using Public Key Encryption 819 In this case, the PA-PK-AS-REP contains a ContentInfo structure 820 wrapped in an OCTET STRING. The AS reply key is encrypted in the 821 encKeyPack field, which contains data of type ReplyKeyPack: 823 ReplyKeyPack ::= SEQUENCE { 824 replyKey [0] EncryptionKey, 825 -- Contains the session key used to encrypt the 826 -- enc-part field in the AS-REP. 827 asChecksum [1] Checksum, 828 -- Contains the checksum of the AS-REQ 829 -- corresponding to the containing AS-REP. 830 -- The checksum is performed over the type AS-REQ. 831 -- The protocol key [RFC3961] of the checksum is the 832 -- replyKey and the key usage number is 6. 833 -- If the replyKey's enctype is "newer" [RFC4120] 834 -- [RFC4121], the checksum is the required 835 -- checksum operation [RFC3961] for that enctype. 836 -- The client MUST verify this checksum upon receipt 837 -- of the AS-REP. 838 ... 839 } 841 The ContentInfo [RFC3852] structure for the encKeyPack field is 842 filled in as follows: 844 1. The contentType field of the type ContentInfo is id-envelopedData 845 (as defined in [RFC3852]), and the content field is an 846 EnvelopedData (as defined in [RFC3852]). 848 2. The contentType field for the type EnvelopedData is id- 849 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 850 pkcs (1) pkcs7 (7) signedData (2) }. 852 3. The eContentType field for the inner type SignedData (when 853 decrypted from the encryptedContent field for the type 854 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) 855 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. 857 4. The eContent field for the inner type SignedData contains the DER 858 encoding of the type ReplyKeyPack. 860 5. The signerInfos field of the inner type SignedData contains a 861 single signerInfo, which contains the signature over the type 862 ReplyKeyPack. 864 6. The certificates field of the inner type SignedData contains 865 certificates intended to facilitate certification path 866 construction, so that the client can verify the KDC's signature 867 over the type ReplyKeyPack. The information contained in the 868 trustedCertifiers in the request SHOULD be used by the KDC as 869 hints to guide its selection of an appropriate certificate chain 870 to return to the client. This field may only be left empty if 871 the KDC public key specified by the kdcPkId field in the PA-PK- 872 AS-REQ was used for signing. Otherwise, for path validation, 873 these certificates SHOULD be sufficient to construct at least one 874 certification path from the KDC certificate to one trust anchor 875 acceptable by the client [CAPATH]. The KDC MUST be capable of 876 including such a set of certificates if configured to do so. The 877 certificates field MUST NOT contain "root" CA certificates. 879 7. The recipientInfos field of the type EnvelopedData is a SET which 880 MUST contain exactly one member of type KeyTransRecipientInfo. 881 The encryptedKey of this member contains the temporary key which 882 is encrypted using the client's public key. 884 8. The unprotectedAttrs or originatorInfo fields of the type 885 EnvelopedData MAY be present. 887 Implementations of this RSA encryption key delivery method are 888 RECOMMENDED to support for RSA keys at least 2048 bits in size. 890 3.2.4. Receipt of KDC Reply 892 Upon receipt of the KDC's reply, the client proceeds as follows. If 893 the PA-PK-AS-REP contains the dhSignedData field, the client derives 894 the AS reply key using the same procedure used by the KDC as defined 895 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 896 field, and the client decrypts and extracts the temporary key in the 897 encryptedKey field of the member KeyTransRecipientInfo, and then uses 898 that as the AS reply key. 900 If the public key encryption method is used, the client MUST verify 901 the asChecksum contained in the ReplyKeyPack. 903 In either case, the client MUST verify the signature in the 904 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 905 be validated according to [RFC3280]. In addition, unless the client 906 can otherwise verify that the public key used to verify the KDC's 907 signature is bound to the KDC of the target realm, the KDC's X.509 908 certificate MUST contain a Subject Alternative Name extension 909 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as 910 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 911 matches the name of the TGS of the target realm (as defined in 912 Section 7.3 of [RFC4120]). 914 Unless the client knows by some other means that the KDC certificate 915 is intended for a Kerberos KDC, the client MUST require that the KDC 916 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: 918 id-pkinit-KPKdc OBJECT IDENTIFIER ::= 919 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 920 pkinit(3) keyPurposeKdc(5) } 921 -- Signing KDC responses. 922 -- Key usage bits that MUST be consistent: 923 -- digitalSignature. 925 If the KDC certificate contains the Kerberos TGS name encoded as an 926 id-pkinit-san SAN, this certificate is certified by the issuing CA as 927 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. 929 If all applicable checks are satisfied, the client then decrypts the 930 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 931 and then proceeds as described in [RFC4120]. 933 Implementation note: CAs issuing KDC certificates SHOULD place all 934 "short" and "fully-qualified" Kerberos realm names of the KDC (one 935 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 936 flexibility. 938 3.3. Interoperability Requirements 940 The client MUST be capable of sending a set of certificates 941 sufficient to allow the KDC to construct a certification path for the 942 client's certificate, if the correct set of certificates is provided 943 through configuration or policy. 945 If the client sends all the X.509 certificates on a certification 946 path to a trust anchor acceptable by the KDC, and the KDC can not 947 verify the client's public key otherwise, the KDC MUST be able to 948 process path validation for the client's certificate based on the 949 certificates in the request. 951 The KDC MUST be capable of sending a set of certificates sufficient 952 to allow the client to construct a certification path for the KDC's 953 certificate, if the correct set of certificates is provided through 954 configuration or policy. 956 If the KDC sends all the X.509 certificates on a certification path 957 to a trust anchor acceptable by the client, and the client can not 958 verify the KDC's public key otherwise, the client MUST be able to 959 process path validation for the KDC's certificate based on the 960 certificates in the reply. 962 3.4. KDC Indication of PKINIT Support 964 If pre-authentication is required, but was not present in the 965 request, per [RFC4120] an error message with the code 966 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 967 stored in the e-data field of the KRB-ERROR message to specify which 968 pre-authentication mechanisms are acceptable. The KDC can then 969 indicate the support of PKINIT by including an empty element whose 970 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 972 Otherwise if it is required by the KDC's local policy that the client 973 must be pre-authenticated using the pre-authentication mechanism 974 specified in this document, but no PKINIT pre-authentication was 975 present in the request, an error message with the code 976 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 978 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 979 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 980 STRING), and clients MUST ignore this and any other value. Future 981 extensions to this protocol may specify other data to send instead of 982 an empty OCTET STRING. 984 4. Security Considerations 986 Kerberos error messages are not integrity protected, as a result, the 987 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered 988 with by an attacker so that the set of domain parameters selected 989 could be either weaker or not mutually preferred. Local policy can 990 configure sets of domain parameters acceptable locally, or disallow 991 the negotiation of DH domain parameters. 993 The symmetric reply key size and Diffie-Hellman field size or RSA 994 modulus size should be chosen so as to provide sufficient 995 cryptographic security [RFC3766]. 997 When MODP Diffie-Hellman is used, the exponents should have at least 998 twice as many bits as the symmetric keys that will be derived from 999 them [ODL99]. 1001 PKINIT raises certain security considerations beyond those that can 1002 be regulated strictly in protocol definitions. We will address them 1003 in this section. 1005 PKINIT extends the cross-realm model to the public-key 1006 infrastructure. Users of PKINIT must understand security policies 1007 and procedures appropriate to the use of Public Key Infrastructures 1008 [RFC3280]. 1010 In order to trust a KDC certificate that is certified by a CA as a 1011 KDC certificate for a target realm (for example, by asserting the TGS 1012 name of that Kerberos realm as an id-pkinit-san SAN and/or 1013 restricting the certificate usage by using the id-pkinit-KPKdc EKU, 1014 as described in Section 3.2.4), the client MUST verify that the KDC 1015 certificate's issuing CA is authorized to issue KDC certificates for 1016 that target realm. Otherwise, the binding between the KDC 1017 certificate and the KDC of the target realm is not established. 1019 How to validate this authorization is a matter of local policy. A 1020 way to achieve this is the configuration of specific sets of 1021 intermediary CAs and trust anchors, one of which must be on the KDC 1022 certificate's certification path [RFC3280]; and for each CA or trust 1023 anchor the realms for which it is allowed to issue certificates. 1025 In addition, if any CA is trusted to issue KDC certificates can also 1026 issue other kinds of certificates, then local policy must be able to 1027 distinguish between them: for example, it could require that KDC 1028 certificates contain the id-pkinit-KPKdc EKU or that the realm be 1029 specified with the id-pkinit-san SAN. 1031 It is the responsibility of the PKI administrators for an 1032 organization to ensure that KDC certificates are only issued to KDCs, 1033 and that clients can ascertain this using their local policy. 1035 Standard Kerberos allows the possibility of interactions between 1036 cryptosystems of varying strengths; this document adds interactions 1037 with public-key cryptosystems to Kerberos. Some administrative 1038 policies may allow the use of relatively weak public keys. Using 1039 such keys to wrap data encrypted under stronger conventional 1040 cryptosystems may be inappropriate. 1042 PKINIT requires keys for symmetric cryptosystems to be generated. 1043 Some such systems contain "weak" keys. For recommendations regarding 1044 these weak keys, see [RFC4120]. 1046 PKINIT allows the use of the same RSA key pair for encryption and 1047 signing when doing RSA encryption based key delivery. This is not 1048 recommended usage of RSA keys [RFC3447], by using DH based key 1049 delivery this is avoided. 1051 Care should be taken in how certificates are chosen for the purposes 1052 of authentication using PKINIT. Some local policies may require that 1053 key escrow be used for certain certificate types. Deployers of 1054 PKINIT should be aware of the implications of using certificates that 1055 have escrowed keys for the purposes of authentication. Because 1056 signing only certificates are normally not escrowed, by using DH 1057 based key delivery this is avoided. 1059 PKINIT does not provide for a "return routability" test to prevent 1060 attackers from mounting a denial-of-service attack on the KDC by 1061 causing it to perform unnecessary and expensive public-key 1062 operations. Strictly speaking, this is also true of standard 1063 Kerberos, although the potential cost is not as great, because 1064 standard Kerberos does not make use of public-key cryptography. By 1065 using DH based key delivery and reusing DH keys, the necessary crypto 1066 processing cost per request can be minimized. 1068 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1069 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1070 be used if the KDC itself vouches for the user's certificate. 1072 5. Acknowledgements 1074 The following people have made significant contributions to this 1075 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist 1076 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 1077 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik 1078 Jaganathan, and Chaskiel M Grundman. 1080 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and 1081 Chris Walstad discovered a binding issue between the AS-REQ and AS- 1082 REP in draft -26, the asChecksum field was added as the result. 1084 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1085 Jonathan Trostle who wrote earlier versions of this document. 1087 The authors are indebted to the Kerberos working group chair Jeffrey 1088 Hutzelman who kept track of various issues and was enormously helpful 1089 during the creation of this document. 1091 Some of the ideas on which this document is based arose during 1092 discussions over several years between members of the SAAG, the IETF 1093 CAT working group, and the PSRG, regarding integration of Kerberos 1094 and SPX. Some ideas have also been drawn from the DASS system. 1095 These changes are by no means endorsed by these groups. This is an 1096 attempt to revive some of the goals of those groups, and this 1097 document approaches those goals primarily from the Kerberos 1098 perspective. 1100 Lastly, comments from groups working on similar ideas in DCE have 1101 been invaluable. 1103 6. IANA Considerations 1105 This document has no actions for IANA. 1107 7. References 1109 7.1. Normative References 1111 [IEEE1363] 1112 IEEE, "Standard Specifications for Public Key 1113 Cryptography", IEEE 1363, 2000. 1115 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1116 Requirement Levels", BCP 14, RFC 2119, March 1997. 1118 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1119 RFC 2412, November 1998. 1121 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1122 RFC 2631, June 1999. 1124 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1125 Identifiers for the Internet X.509 Public Key 1126 Infrastructure Certificate and Certificate Revocation List 1127 (CRL) Profile", RFC 3279, April 2002. 1129 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1130 X.509 Public Key Infrastructure Certificate and 1131 Certificate Revocation List (CRL) Profile", RFC 3280, 1132 April 2002. 1134 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1135 Algorithms", RFC 3370, August 2002. 1137 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1138 Standards (PKCS) #1: RSA Cryptography Specifications 1139 Version 2.1", RFC 3447, February 2003. 1141 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1142 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1143 RFC 3526, May 2003. 1145 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1146 Encryption Algorithm in Cryptographic Message Syntax 1147 (CMS)", RFC 3565, July 2003. 1149 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1150 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1151 RFC 3766, April 2004. 1153 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1154 RFC 3852, July 2004. 1156 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1157 Kerberos 5", RFC 3961, February 2005. 1159 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1160 Encryption for Kerberos 5", RFC 3962, February 2005. 1162 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1163 Kerberos Network Authentication Service (V5)", RFC 4120, 1164 July 2005. 1166 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1167 Version 5 Generic Security Service Application Program 1168 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1169 July 2005. 1171 [X.509-97] ITU-T Recommendation X.509: The Directory - Authentication 1172 Framework, 1997. 1174 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1175 Information technology - Abstract Syntax Notation One 1176 (ASN.1): Specification of basic notation. 1178 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1179 Information technology - ASN.1 encoding Rules: Specification 1180 of Basic Encoding Rules (BER), Canonical Encoding Rules 1181 (CER) and Distinguished Encoding Rules (DER). 1183 7.2. Informative References 1185 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1186 pkix-certpathbuild. Work in Progress. 1188 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1189 Sizes", Journal of Cryptology 14 (2001) 255-293. 1191 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1192 future, Designs, Codes, and Cryptography (1999)". 1194 Appendix A. PKINIT ASN.1 Module 1196 KerberosV5-PK-INIT-SPEC { 1197 iso(1) identified-organization(3) dod(6) internet(1) 1198 security(5) kerberosV5(2) modules(4) pkinit(5) 1199 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1201 IMPORTS 1202 SubjectPublicKeyInfo, AlgorithmIdentifier 1203 FROM PKIX1Explicit88 { iso (1) 1204 identified-organization (3) dod (6) internet (1) 1205 security (5) mechanisms (5) pkix (7) id-mod (0) 1206 id-pkix1-explicit (18) } 1207 -- As defined in RFC 3280. 1209 KerberosTime, PrincipalName, Realm, EncryptionKey 1210 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1211 dod(6) internet(1) security(5) kerberosV5(2) 1212 modules(4) krb5spec2(2) } ; 1214 id-pkinit OBJECT IDENTIFIER ::= 1215 { iso (1) org (3) dod (6) internet (1) security (5) 1216 kerberosv5 (2) pkinit (3) } 1218 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 } 1219 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 } 1220 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 } 1221 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 } 1222 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 } 1224 id-pkinit-san OBJECT IDENTIFIER ::= 1225 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1226 x509SanAN (2) } 1228 pa-pk-as-req INTEGER ::= 16 1229 pa-pk-as-rep INTEGER ::= 17 1231 ad-initial-verified-cas INTEGER ::= 9 1233 td-trusted-certifiers INTEGER ::= 104 1234 td-invalid-certificates INTEGER ::= 105 1235 td-dh-parameters INTEGER ::= 109 1237 PA-PK-AS-REQ ::= SEQUENCE { 1238 signedAuthPack [0] IMPLICIT OCTET STRING, 1239 -- Contains a CMS type ContentInfo encoded 1240 -- according to [RFC3852]. 1241 -- The contentType field of the type ContentInfo 1242 -- is id-signedData (1.2.840.113549.1.7.2), 1243 -- and the content field is a SignedData. 1244 -- The eContentType field for the type SignedData is 1245 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the 1246 -- eContent field contains the DER encoding of the 1247 -- type AuthPack. 1248 -- AuthPack is defined below. 1249 trustedCertifiers [1] SEQUENCE OF 1250 ExternalPrincipalIdentifier OPTIONAL, 1251 -- A list of CAs, trusted by the client, that can 1252 -- be used to certify the KDC. 1253 -- Each ExternalPrincipalIdentifier identifies a CA 1254 -- or a CA certificate (thereby its public key). 1255 -- The information contained in the 1256 -- trustedCertifiers SHOULD be used by the KDC as 1257 -- hints to guide its selection of an appropriate 1258 -- certificate chain to return to the client. 1259 kdcPkId [2] IMPLICIT OCTET STRING 1260 OPTIONAL, 1261 -- Contains a CMS type SignerIdentifier encoded 1262 -- according to [RFC3852]. 1263 -- Identifies, if present, a particular KDC 1264 -- public key that the client already has. 1265 ... 1266 } 1268 DHNonce ::= OCTET STRING 1270 ExternalPrincipalIdentifier ::= SEQUENCE { 1271 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1272 -- Contains a PKIX type Name encoded according to 1273 -- [RFC3280]. 1274 -- Identifies the certificate subject by the 1275 -- distinguished subject name. 1276 -- REQUIRED when there is a distinguished subject 1277 -- name present in the certificate. 1278 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1279 -- Contains a CMS type IssuerAndSerialNumber encoded 1280 -- according to [RFC3852]. 1281 -- Identifies a certificate of the subject. 1282 -- REQUIRED for TD-INVALID-CERTIFICATES and 1283 -- TD-TRUSTED-CERTIFIERS. 1284 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1285 -- Identifies the subject's public key by a key 1286 -- identifier. When an X.509 certificate is 1287 -- referenced, this key identifier matches the X.509 1288 -- subjectKeyIdentifier extension value. When other 1289 -- certificate formats are referenced, the documents 1290 -- that specify the certificate format and their use 1291 -- with the CMS must include details on matching the 1292 -- key identifier to the appropriate certificate 1293 -- field. 1294 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1295 ... 1296 } 1297 AuthPack ::= SEQUENCE { 1298 pkAuthenticator [0] PKAuthenticator, 1299 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1300 -- Type SubjectPublicKeyInfo is defined in 1301 -- [RFC3280]. 1302 -- Specifies Diffie-Hellman domain parameters 1303 -- and the client's public key value [IEEE1363]. 1304 -- The DH public key value is encoded as a BIT 1305 -- STRING according to [RFC3279]. 1306 -- This field is present only if the client wishes 1307 -- to use the Diffie-Hellman key agreement method. 1308 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1309 OPTIONAL, 1310 -- Type AlgorithmIdentifier is defined in 1311 -- [RFC3280]. 1312 -- List of CMS encryption types supported by the 1313 -- client in order of (decreasing) preference. 1314 clientDHNonce [3] DHNonce OPTIONAL, 1315 -- Present only if the client indicates that it 1316 -- wishes to reuse DH keys or to allow the KDC to 1317 -- do so. 1318 ... 1319 } 1321 PKAuthenticator ::= SEQUENCE { 1322 cusec [0] INTEGER (0..999999), 1323 ctime [1] KerberosTime, 1324 -- cusec and ctime are used as in [RFC4120], for 1325 -- replay prevention. 1326 nonce [2] INTEGER (0..4294967295), 1327 -- Chosen randomly; This nonce does not need to 1328 -- match with the nonce in the KDC-REQ-BODY. 1329 paChecksum [3] OCTET STRING, 1330 -- Contains the SHA1 checksum, performed over 1331 -- KDC-REQ-BODY. 1332 ... 1333 } 1335 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1336 ExternalPrincipalIdentifier 1337 -- Identifies a list of CAs trusted by the KDC. 1338 -- Each ExternalPrincipalIdentifier identifies a CA 1339 -- or a CA certificate (thereby its public key). 1341 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1342 ExternalPrincipalIdentifier 1343 -- Each ExternalPrincipalIdentifier identifies a 1344 -- certificate (sent by the client) with an invalid 1345 -- signature. 1347 KRB5PrincipalName ::= SEQUENCE { 1348 realm [0] Realm, 1349 principalName [1] PrincipalName 1350 } 1352 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1353 ExternalPrincipalIdentifier 1354 -- Identifies the certification path based on which 1355 -- the client certificate was validated. 1356 -- Each ExternalPrincipalIdentifier identifies a CA 1357 -- or a CA certificate (thereby its public key). 1359 PA-PK-AS-REP ::= CHOICE { 1360 dhInfo [0] DHRepInfo, 1361 -- Selected when Diffie-Hellman key exchange is 1362 -- used. 1363 encKeyPack [1] IMPLICIT OCTET STRING, 1364 -- Selected when public key encryption is used. 1365 -- Contains a CMS type ContentInfo encoded 1366 -- according to [RFC3852]. 1367 -- The contentType field of the type ContentInfo is 1368 -- id-envelopedData (1.2.840.113549.1.7.3). 1369 -- The content field is an EnvelopedData. 1370 -- The contentType field for the type EnvelopedData 1371 -- is id-signedData (1.2.840.113549.1.7.2). 1372 -- The eContentType field for the inner type 1373 -- SignedData (when unencrypted) is 1374 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the 1375 -- eContent field contains the DER encoding of the 1376 -- type ReplyKeyPack. 1377 -- ReplyKeyPack is defined below. 1378 ... 1379 } 1381 DHRepInfo ::= SEQUENCE { 1382 dhSignedData [0] IMPLICIT OCTET STRING, 1383 -- Contains a CMS type ContentInfo encoded according 1384 -- to [RFC3852]. 1385 -- The contentType field of the type ContentInfo is 1386 -- id-signedData (1.2.840.113549.1.7.2), and the 1387 -- content field is a SignedData. 1388 -- The eContentType field for the type SignedData is 1389 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the 1390 -- eContent field contains the DER encoding of the 1391 -- type KDCDHKeyInfo. 1392 -- KDCDHKeyInfo is defined below. 1394 serverDHNonce [1] DHNonce OPTIONAL 1395 -- Present if and only if dhKeyExpiration is 1396 -- present. 1397 } 1399 KDCDHKeyInfo ::= SEQUENCE { 1400 subjectPublicKey [0] BIT STRING, 1401 -- KDC's DH public key. 1402 -- The DH public key value is encoded as a BIT 1403 -- STRING according to [RFC3279]. 1404 nonce [1] INTEGER (0..4294967295), 1405 -- Contains the nonce in the PKAuthenticator of the 1406 -- request if DH keys are NOT reused, 1407 -- 0 otherwise. 1408 dhKeyExpiration [2] KerberosTime OPTIONAL, 1409 -- Expiration time for KDC's key pair, 1410 -- present if and only if DH keys are reused. If 1411 -- this field is omitted then the serverDHNonce 1412 -- field MUST also be omitted. 1413 ... 1414 } 1416 ReplyKeyPack ::= SEQUENCE { 1417 replyKey [0] EncryptionKey, 1418 -- Contains the session key used to encrypt the 1419 -- enc-part field in the AS-REP. 1420 asChecksum [1] Checksum, 1421 -- Contains the checksum of the AS-REQ 1422 -- corresponding to the containing AS-REP. 1423 -- The checksum is performed over the type AS-REQ. 1424 -- The protocol key [RFC3961] of the checksum is the 1425 -- replyKey and the key usage number is 6. 1426 -- If the replyKey's enctype is "newer" [RFC4120] 1427 -- [RFC4121], the checksum is the required 1428 -- checksum operation [RFC3961] for that enctype. 1429 -- The client MUST verify this checksum upon receipt 1430 -- of the AS-REP. 1431 ... 1432 } 1434 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1435 -- Each AlgorithmIdentifier specifies a set of 1436 -- Diffie-Hellman domain parameters [IEEE1363]. 1437 -- This list is in decreasing preference order. 1438 END 1440 Appendix B. Test Vectors 1442 Function octetstring2key() is defined in Section 3.2.3.1. This 1443 section describes a few sets of test vectors that would be useful for 1444 implementers of octetstring2key(). 1446 Set 1 1447 ===== 1448 Input octet string x is: 1450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1451 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1452 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1453 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1454 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1455 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1456 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1457 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1458 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1459 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1461 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1462 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1463 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1465 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1467 Output of K-truncate() when the key size is 32 octets: 1469 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1470 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1472 Set 2: 1473 ===== 1474 Input octet string x is: 1476 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1477 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1478 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1479 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1481 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1482 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1483 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1485 Output of K-truncate() when the key size is 32 octets: 1487 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1488 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1490 Set 3: 1491 ====== 1492 Input octet string x is: 1494 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1495 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1496 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1497 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1498 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1499 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1500 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1501 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1503 Output of K-truncate() when the key size is 32 octets: 1505 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1506 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1508 Set 4: 1509 ===== 1510 Input octet string x is: 1512 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1513 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1514 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1515 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1516 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1518 Output of K-truncate() when the key size is 32 octets: 1520 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 1521 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 1523 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT 1524 Implementations 1526 Earlier revisions of the PKINIT I-D were implemented in various 1527 releases of Microsoft Windows and deployed in fairly large numbers. 1528 To enable the community to better interoperate with systems running 1529 those releases, the following information may be useful. 1531 KDC certificates issued by Windows 2000 Enterprise CAs contain a 1532 dNSName SAN with the DNS name of the host running the KDC, and the 1533 id-kp-serverAuth EKU [RFC3280]. 1535 KDC certificates issued by Windows 2003 Enterprise CAs contain a 1536 dNSName SAN with the DNS name of the host running the KDC, the id-kp- 1537 serverAuth EKU and the id-ms-kp-sc-logon EKU. 1539 It is anticipated that the next release of Windows is already too far 1540 along to allow it to support the issuing KDC certificates with id- 1541 pkinit-san SAN as specified in this RFC. Instead, they will have a 1542 dNSName SAN containing the domain name of the KDC and the intended 1543 purpose of these KDC certificates be restricted by the presence of 1544 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU. 1546 In addition to checking that the above are present in a KDC 1547 certificate, Windows clients verify that the issuer of the KDC 1548 certificate is one of a set of allowed issuers of such certificates, 1549 so those wishing to issue KDC certificates need to configure their 1550 Windows clients appropriately. 1552 Client certificates accepted by Windows 2000 and Windows 2003 Server 1553 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) 1554 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN 1555 contains a UTF8 encoded string whose value is that of the Directory 1556 Service attribute UserPrincipalName of the client account object, and 1557 the purpose of including the id-ms-san-sc-logon-upn SAN in the client 1558 certificate is to validate the client mapping (in other words, the 1559 client's public key is bound to the account that has this 1560 UserPrincipalName value). 1562 It should be noted that all Microsoft Kerberos realm names are domain 1563 style realm names and strictly in upper case. In addition, the 1564 UserPrincipalName attribute is globally unique in Windows 2000 and 1565 Windows 2003. 1567 Authors' Addresses 1569 Brian Tung 1570 USC Information Sciences Institute 1571 4676 Admiralty Way Suite 1001 1572 Marina del Rey, CA 90292 1573 US 1575 Email: brian@isi.edu 1577 Larry Zhu 1578 Microsoft Corporation 1579 One Microsoft Way 1580 Redmond, WA 98052 1581 US 1583 Email: lzhu@microsoft.com 1585 Intellectual Property Statement 1587 The IETF takes no position regarding the validity or scope of any 1588 Intellectual Property Rights or other rights that might be claimed to 1589 pertain to the implementation or use of the technology described in 1590 this document or the extent to which any license under such rights 1591 might or might not be available; nor does it represent that it has 1592 made any independent effort to identify any such rights. Information 1593 on the procedures with respect to rights in RFC documents can be 1594 found in BCP 78 and BCP 79. 1596 Copies of IPR disclosures made to the IETF Secretariat and any 1597 assurances of licenses to be made available, or the result of an 1598 attempt made to obtain a general license or permission for the use of 1599 such proprietary rights by implementers or users of this 1600 specification can be obtained from the IETF on-line IPR repository at 1601 http://www.ietf.org/ipr. 1603 The IETF invites any interested party to bring to its attention any 1604 copyrights, patents or patent applications, or other proprietary 1605 rights that may cover technology that may be required to implement 1606 this standard. Please address the information to the IETF at 1607 ietf-ipr@ietf.org. 1609 Disclaimer of Validity 1611 This document and the information contained herein are provided on an 1612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1614 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1615 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1616 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1619 Copyright Statement 1621 Copyright (C) The Internet Society (2005). This document is subject 1622 to the rights, licenses and restrictions contained in BCP 78, and 1623 except as set forth therein, the authors retain all their rights. 1625 Acknowledgment 1627 Funding for the RFC Editor function is currently provided by the 1628 Internet Society.