idnits 2.17.00 (12 Aug 2021) /tmp/idnits24917/draft-ietf-cat-kerberos-pk-init-27.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 1425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1415. ** 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 date (July 19, 2005) is 6149 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 1370 -- Looks like a reference, but probably isn't: '1' on line 1373 -- Looks like a reference, but probably isn't: '2' on line 1361 -- Looks like a reference, but probably isn't: '3' on line 1282 == Unused Reference: 'LENSTRA' is defined on line 1117, 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. 'X690' == Outdated reference: draft-ietf-pkix-certpathbuild has been published as RFC 4158 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 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: January 20, 2006 L. Zhu 5 Microsoft Corporation 6 July 19, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-27 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 January 20, 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 . . . . . . . . . . . . . . . . . 19 62 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 63 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 21 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 68 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23 69 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 71 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 72 Intellectual Property and Copyright Statements . . . . . . . . 31 74 1. Introduction 76 A client typically authenticates itself to a service in Kerberos 77 using three distinct though related exchanges. First, the client 78 requests a ticket-granting ticket (TGT) from the Kerberos 79 authentication server (AS). Then, it uses the TGT to request a 80 service ticket from the Kerberos ticket-granting server (TGS). 81 Usually, the AS and TGS are integrated in a single device known as a 82 Kerberos Key Distribution Center, or KDC. Finally, the client uses 83 the service ticket to authenticate itself to the service. 85 The advantage afforded by the TGT is that the client exposes his 86 long-term secrets only once. The TGT and its associated session key 87 can then be used for any subsequent service ticket requests. One 88 result of this is that all further authentication is independent of 89 the method by which the initial authentication was performed. 90 Consequently, initial authentication provides a convenient place to 91 integrate public-key cryptography into Kerberos authentication. 93 As defined in [RFC4120], Kerberos authentication exchanges use 94 symmetric-key cryptography, in part for performance. One 95 disadvantage of using symmetric-key cryptography is that the keys 96 must be shared, so that before a client can authenticate itself, he 97 must already be registered with the KDC. 99 Conversely, public-key cryptography (in conjunction with an 100 established Public Key Infrastructure) permits authentication without 101 prior registration with a KDC. Adding it to Kerberos allows the 102 widespread use of Kerberized applications by clients without 103 requiring them to register first with a KDC--a requirement that has 104 no inherent security benefit. 106 As noted above, a convenient and efficient place to introduce public- 107 key cryptography into Kerberos is in the initial authentication 108 exchange. This document describes the methods and data formats for 109 integrating public-key cryptography into Kerberos initial 110 authentication. 112 2. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Both the AS and the TGS are referred to as the KDC. 120 In this document, the encryption key used to encrypt the enc-part 121 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS 122 reply key. 124 3. Extensions 126 This section describes extensions to [RFC4120] for supporting the use 127 of public-key cryptography in the initial request for a ticket. 129 Briefly, this document defines the following extensions to [RFC4120]: 131 1. The client indicates the use of public-key authentication by 132 including a special preauthenticator in the initial request. This 133 preauthenticator contains the client's public-key data and a 134 signature. 136 2. The KDC tests the client's request against its authentication 137 policy and trusted Certification Authorities (CAs). 139 3. If the request passes the verification tests, the KDC replies as 140 usual, but the reply is encrypted using either: 142 a. a key generated through a Diffie-Hellman (DH) key exchange 143 [RFC2631] [IEEE1363] with the client, signed using the KDC's 144 signature key; or 146 b. a symmetric encryption key, signed using the KDC's signature 147 key and encrypted using the client's public key. 149 Any keying material required by the client to obtain the 150 encryption key for decrypting the KDC reply is returned in a pre- 151 authentication field accompanying the usual reply. 153 4. The client validates the KDC's signature, obtains the encryption 154 key, decrypts the reply, and then proceeds as usual. 156 Section 3.1 of this document enumerates the required algorithms and 157 necessary extension message types. Section 3.2 describes the 158 extension messages in greater detail. 160 3.1 Definitions, Requirements, and Constants 162 3.1.1 Required Algorithms 164 All PKINIT implementations MUST support the following algorithms: 166 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 167 sha1-96 [RFC3962]. 169 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 171 o AS reply key delivery method: Diffie-Hellman key exchange 172 [RFC2631]. 174 3.1.2 Defined Message and Encryption Types 176 PKINIT makes use of the following new pre-authentication types: 178 PA_PK_AS_REQ 16 179 PA_PK_AS_REP 17 181 PKINIT also makes use of the following new authorization data type: 183 AD_INITIAL_VERIFIED_CAS 9 185 PKINIT introduces the following new error codes: 187 KDC_ERR_CLIENT_NOT_TRUSTED 62 188 KDC_ERR_INVALID_SIG 64 189 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 190 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 191 KDC_ERR_INVALID_CERTIFICATE 71 192 KDC_ERR_REVOKED_CERTIFICATE 72 193 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 194 KDC_ERR_CLIENT_NAME_MISMATCH 75 195 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 197 PKINIT uses the following typed data types for errors: 199 TD_TRUSTED_CERTIFIERS 104 200 TD_INVALID_CERTIFICATES 105 201 TD_DH_PARAMETERS 109 203 PKINIT defines the following encryption types, for use in the AS-REQ 204 message to indicate acceptance of the corresponding algorithms that 205 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in 206 the reply: 208 dsaWithSHA1-CmsOID 9 209 md5WithRSAEncryption-CmsOID 10 210 sha1WithRSAEncryption-CmsOID 11 211 rc2CBC-EnvOID 12 212 rsaEncryption-EnvOID (PKCS1 v1.5) 13 213 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 214 des-ede3-cbc-EnvOID 15 216 The ASN.1 module for all structures defined in this document (plus 217 IMPORT statements for all imported structures) is given in 218 Appendix A. 220 All structures defined in or imported into this document MUST be 221 encoded using Distinguished Encoding Rules (DER) [X690] (unless 222 otherwise noted). All data structures carried in OCTET STRINGs must 223 be encoded according to the rules specified in corresponding 224 specifications. 226 Interoperability note: Some implementations may not be able to decode 227 wrapped CMS objects encoded with BER but not DER; specifically, they 228 may not be able to decode infinite length encodings. To maximize 229 interoperability, implementers SHOULD encode CMS objects used in 230 PKINIT with DER. 232 3.1.3 Algorithm Identifiers 234 PKINIT does not define, but does make use of, the following algorithm 235 identifiers. 237 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman 238 key agreement [RFC3279]: 240 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) 242 PKINIT uses the following signature algorithm identifiers [RFC3279]: 244 sha-1WithRSAEncryption (RSA with SHA1) 245 md5WithRSAEncryption (RSA with MD5) 246 id-dsa-with-sha1 (DSA with SHA1) 248 PKINIT uses the following encryption algorithm identifiers [RFC3447] 249 for encrypting the temporary key with a public key: 251 rsaEncryption (PKCS1 v1.5) 252 id-RSAES-OAEP (PKCS1 v2.0) 254 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 255 for encrypting the AS reply key with the temporary key: 257 des-ede3-cbc (three-key 3DES, CBC mode) 258 rc2-cbc (RC2, CBC mode) 259 id-aes256-CBC (AES-256, CBC mode) 261 3.2 PKINIT Pre-authentication Syntax and Use 263 This section defines the syntax and use of the various pre- 264 authentication fields employed by PKINIT. 266 3.2.1 Generation of Client Request 268 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 269 in addition, a pre-authentication data element, whose padata-type is 270 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 271 type PA-PK-AS-REQ, is included. 273 PA-PK-AS-REQ ::= SEQUENCE { 274 signedAuthPack [0] IMPLICIT OCTET STRING, 275 -- Contains a CMS type ContentInfo encoded 276 -- according to [RFC3852]. 277 -- The contentType field of the type ContentInfo 278 -- is id-signedData (1.2.840.113549.1.7.2), 279 -- and the content field is a SignedData. 280 -- The eContentType field for the type SignedData is 281 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 282 -- eContent field contains the DER encoding of the 283 -- type AuthPack. 284 -- AuthPack is defined below. 285 trustedCertifiers [1] SEQUENCE OF 286 ExternalPrincipalIdentifier OPTIONAL, 287 -- A list of CAs, trusted by the client, that can 288 -- be used to certify the KDC. 289 -- Each ExternalPrincipalIdentifier identifies a CA 290 -- or a CA certificate (thereby its public key). 291 -- The information contained in the 292 -- trustedCertifiers SHOULD be used by the KDC as 293 -- hints to guide its selection of an appropriate 294 -- certificate chain to return to the client. 295 kdcPkId [2] IMPLICIT OCTET STRING 296 OPTIONAL, 297 -- Contains a CMS type SignerIdentifier encoded 298 -- according to [RFC3852]. 299 -- Identifies, if present, a particular KDC 300 -- public key that the client already has. 301 ... 302 } 304 DHNonce ::= OCTET STRING 306 ExternalPrincipalIdentifier ::= SEQUENCE { 307 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 308 -- Contains a PKIX type Name encoded according to 309 -- [RFC3280]. 310 -- Identifies the certificate subject by the 311 -- distinguished subject name. 312 -- REQUIRED when there is a distinguished subject 313 -- name present in the certificate. 314 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 315 -- Contains a CMS type IssuerAndSerialNumber encoded 316 -- according to [RFC3852]. 317 -- Identifies a certificate of the subject. 318 -- REQUIRED for TD-INVALID-CERTIFICATES and 319 -- TD-TRUSTED-CERTIFIERS. 320 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 321 -- Identifies the subject's public key by a key 322 -- identifier. When an X.509 certificate is 323 -- referenced, this key identifier matches the X.509 324 -- subjectKeyIdentifier extension value. When other 325 -- certificate formats are referenced, the documents 326 -- that specify the certificate format and their use 327 -- with the CMS must include details on matching the 328 -- key identifier to the appropriate certificate 329 -- field. 330 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 331 ... 332 } 334 AuthPack ::= SEQUENCE { 335 pkAuthenticator [0] PKAuthenticator, 336 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 337 -- Type SubjectPublicKeyInfo is defined in 338 -- [RFC3280]. 339 -- Specifies Diffie-Hellman domain parameters 340 -- and the client's public key value [IEEE1363]. 341 -- The DH public key value is encoded as a BIT 342 -- STRING, as specified in Section 2.3.3 of 343 -- [RFC3279]. 344 -- This field is present only if the client wishes 345 -- to use the Diffie-Hellman key agreement method. 346 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 347 OPTIONAL, 348 -- Type AlgorithmIdentifier is defined in 349 -- [RFC3280]. 350 -- List of CMS encryption types supported by the 351 -- client in order of (decreasing) preference. 352 clientDHNonce [3] DHNonce OPTIONAL, 353 -- Present only if the client indicates that it 354 -- wishes to reuse DH keys or to allow the KDC to 355 -- do so (see Section 3.2.3.1). 356 ... 358 } 360 PKAuthenticator ::= SEQUENCE { 361 cusec [0] INTEGER (0..999999), 362 ctime [1] KerberosTime, 363 -- cusec and ctime are used as in [RFC4120], for 364 -- replay prevention. 365 nonce [2] INTEGER (0..4294967295), 366 -- Chosen randomly; This nonce does not need to 367 -- match with the nonce in the KDC-REQ-BODY. 368 paChecksum [3] OCTET STRING, 369 -- Contains the SHA1 checksum, performed over 370 -- KDC-REQ-BODY. 371 ... 372 } 374 The ContentInfo [RFC3852] structure for the signedAuthPack field is 375 filled out as follows: 377 1. The contentType field of the type ContentInfo is id-signedData 378 (as defined in [RFC3852]), and the content field is a SignedData 379 (as defined in [RFC3852]). 381 2. The eContentType field for the type SignedData is id-pkauthdata: 382 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 383 pkinit(3) pkauthdata(1) }. 385 3. The eContent field for the type SignedData contains the DER 386 encoding of the type AuthPack. 388 4. The signerInfos field of the type SignedData contains a single 389 signerInfo, which contains the signature over the type AuthPack. 391 5. The certificates field of the type SignedData contains 392 certificates intended to facilitate certification path 393 construction, so that the KDC can verify the signature over the 394 type AuthPack. For path validation, these certificates SHOULD be 395 sufficient to construct at least one certification path from the 396 client certificate to one trust anchor acceptable by the KDC 397 [CAPATH]. The client MUST be capable of including such a set of 398 certificates if configured to do so. The certificates field MUST 399 NOT contain "root" CA certificates. 401 6. The client's Diffie-Hellman public value (clientPublicValue) is 402 included if and only if the client wishes to use the Diffie- 403 Hellman key agreement method. The Diffie-Hellman domain 404 parameters [IEEE1363] for the client's public key are specified 405 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 406 and the client's Diffie-Hellman public key value is mapped to a 407 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 408 using the Diffie-Hellman key agreement method, implementations 409 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 410 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 411 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 412 group 16 [RFC3526]. 414 The Diffie-Hellman field size should be chosen so as to provide 415 sufficient cryptographic security [RFC3766]. 417 When MODP Diffie-Hellman is used, the exponents should have at 418 least twice as many bits as the symmetric keys that will be 419 derived from them [ODL99]. 421 7. The client may wish to reuse DH keys or to allow the KDC to do so 422 (see Section 3.2.3.1). If so, then the client includes the 423 clientDHNonce field. This nonce string needs to be as long as 424 the longest key length of the symmetric key types that the client 425 supports. This nonce MUST be chosen randomly. 427 3.2.2 Receipt of Client Request 429 Upon receiving the client's request, the KDC validates it. This 430 section describes the steps that the KDC MUST (unless otherwise 431 noted) take in validating the request. 433 The KDC verifies the client's signature in the signedAuthPack field 434 according to [RFC3852]. 436 If, while validating the client's X.509 certificate [RFC3280], the 437 KDC cannot build a certification path to validate the client's 438 certificate, it sends back a KRB-ERROR [RFC4120] message with the 439 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 440 this error message is a TYPED-DATA (as defined in [RFC4120]) that 441 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 442 whose data-value contains the DER encoding of the type TD-TRUSTED- 443 CERTIFIERS: 445 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 446 ExternalPrincipalIdentifier 447 -- Identifies a list of CAs trusted by the KDC. 448 -- Each ExternalPrincipalIdentifier identifies a CA 449 -- or a CA certificate (thereby its public key). 451 Upon receiving this error message, the client SHOULD retry only if it 452 has a different set of certificates (from those of the previous 453 requests) that form a certification path (or a partial path) from one 454 of the trust anchors acceptable by the KDC to its own certificate. 456 If, while processing the certification path, the KDC determines that 457 the signature on one of the certificates in the signedAuthPack field 458 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 459 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 460 message is a TYPED-DATA that contains an element whose data-type is 461 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 462 encoding of the type TD-INVALID-CERTIFICATES: 464 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 465 ExternalPrincipalIdentifier 466 -- Each ExternalPrincipalIdentifier identifies a 467 -- certificate (sent by the client) with an invalid 468 -- signature. 470 If more than one X.509 certificate signature is invalid, the KDC MAY 471 include one IssuerAndSerialNumber per invalid signature within the 472 TD-INVALID-CERTIFICATES. 474 The client's X.509 certificate is validated according to [RFC3280]. 476 Based on local policy, the KDC may also check whether any X.509 477 certificates in the certification path validating the client's 478 certificate have been revoked. If any of them have been revoked, the 479 KDC MUST return an error message with the code 480 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 481 revocation status but is unable to do so, it SHOULD return an error 482 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 483 certificate or certificates affected are identified exactly as for 484 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 486 Note that the TD_INVALID_CERTIFICATES error data is only used to 487 identify invalid certificates sent by the client in the request. 489 The client's public key is then used to verify the signature. If the 490 signature fails to verify, the KDC MUST return an error message with 491 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 492 this error message. 494 In addition to validating the client's signature, the KDC MUST also 495 check that the client's public key used to verify the client's 496 signature is bound to the client's principal name as specified in the 497 AS-REQ as follows: 499 1. If the KDC has its own binding between either the client's 500 signature-verification public key or the client's certificate and 501 the client's Kerberos principal name, it uses that binding. 503 2. Otherwise, if the client's X.509 certificate contains a Subject 504 Alternative Name (SAN) extension carrying a KRB5PrincipalName 505 (defined below) in the otherName field of the type GeneralName 506 [RFC3280], it binds the client's X.509 certificate to that name. 508 The type of the otherName field is AnotherName. The type-id field 509 of the type AnotherName is id-pksan: 511 id-pksan OBJECT IDENTIFIER ::= 512 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 513 x509-sanan (2) } 515 And the value field of the type AnotherName is a 516 KRB5PrincipalName. 518 KRB5PrincipalName ::= SEQUENCE { 519 realm [0] Realm, 520 principalName [1] PrincipalName 521 } 523 If the KDC does not have its own binding and there is no 524 KRB5PrincipalName name present in the client's X.509 certificate, or 525 if the Kerberos name in the request does not match the 526 KRB5PrincipalName in the client's X.509 certificate (including the 527 realm name), the KDC MUST return an error message with the code 528 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 529 this error message. 531 Even if the certification path is validated and the certificate is 532 mapped to the client's principal name, the KDC may decide not to 533 accept the client's certificate, depending on local policy. 535 The KDC MAY require the presence of an Extended Key Usage (EKU) 536 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the 537 client's X.509 certificate: 539 id-pkekuoid OBJECT IDENTIFIER ::= 540 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 541 pkinit(3) pkekuoid(4) } 542 -- PKINIT client authentication. 543 -- Key usage bits that MUST be consistent: 544 -- digitalSignature. 546 If this EKU KeyPurposeId is required but it is not present or if the 547 client certificate is restricted not to be used for PKINIT client 548 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 549 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 550 is no accompanying e-data for this error message. KDCs implementing 551 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc- 552 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 553 are a large number of X.509 client certificates deployed for use with 554 PKINIT which have this EKU. 556 As a matter of local policy, the KDC MAY decide to reject requests on 557 the basis of the absence or presence of other specific EKU OID's. 559 If the client's public key is not accepted, the KDC returns an error 560 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. 562 The KDC MUST check the timestamp to ensure that the request is not a 563 replay, and that the time skew falls within acceptable limits. The 564 recommendations for clock skew times in [RFC4120] apply here. If the 565 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 566 KRB_AP_ERR_SKEW, respectively. 568 If the clientPublicValue is filled in, indicating that the client 569 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 570 check to see if the key parameters satisfy its policy. If they do 571 not, it MUST return an error message with the code 572 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 573 TYPED-DATA that contains an element whose data-type is 574 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 575 the type TD-DH-PARAMETERS: 577 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 578 -- Each AlgorithmIdentifier specifies a set of 579 -- Diffie-Hellman domain parameters [IEEE1363]. 580 -- This list is in decreasing preference order. 582 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 583 that the KDC supports in decreasing preference order, from which the 584 client SHOULD pick one to retry the request. 586 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 587 KDC does not possess the corresponding key, the KDC MUST ignore the 588 kdcPkId field as if the client did not include one. 590 If there is a supportedCMSTypes field in the AuthPack, the KDC must 591 check to see if it supports any of the listed types. If it supports 592 more than one of the types, the KDC SHOULD use the one listed first. 593 If it does not support any of them, it MUST return an error message 594 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 596 3.2.3 Generation of KDC Reply 598 Assuming that the client's request has been properly validated, the 599 KDC proceeds as per [RFC4120], except as follows. 601 The KDC MUST set the initial flag and include an authorization data 602 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 603 ticket. The ad-data [RFC4120] field contains the DER encoding of the 604 type AD-INITIAL-VERIFIED-CAS: 606 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 607 ExternalPrincipalIdentifier 608 -- Identifies the certification path based on which 609 -- the client certificate was validated. 610 -- Each ExternalPrincipalIdentifier identifies a CA 611 -- or a CA certificate (thereby its public key). 613 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 614 containers if the list of CAs satisfies the AS' realm's local policy 615 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 616 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 617 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 618 resulting ticket. If the list of CAs satisfies the local KDC's 619 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 620 container, otherwise it MAY unwrap the authorization data out of the 621 AD-IF-RELEVANT container. 623 Application servers that understand this authorization data type 624 SHOULD apply local policy to determine whether a given ticket bearing 625 such a type *not* contained within an AD-IF-RELEVANT container is 626 acceptable. (This corresponds to the AP server checking the 627 transited field when the TRANSITED-POLICY-CHECKED flag has not been 628 set [RFC4120].) If such a data type is contained within an AD-IF- 629 RELEVANT container, AP servers MAY apply local policy to determine 630 whether the authorization data is acceptable. 632 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 633 KDC encrypts the reply as usual, but not with the client's long-term 634 key. Instead, it encrypts it with either a shared key derived from a 635 Diffie-Hellman exchange, or a generated encryption key. The contents 636 of the PA-PK-AS-REP indicate which key delivery method is used: 638 PA-PK-AS-REP ::= CHOICE { 639 dhInfo [0] DHRepInfo, 640 -- Selected when Diffie-Hellman key exchange is 641 -- used. 642 encKeyPack [1] IMPLICIT OCTET STRING, 643 -- Selected when public key encryption is used. 645 -- Contains a CMS type ContentInfo encoded 646 -- according to [RFC3852]. 647 -- The contentType field of the type ContentInfo is 648 -- id-envelopedData (1.2.840.113549.1.7.3). 649 -- The content field is an EnvelopedData. 650 -- The contentType field for the type EnvelopedData 651 -- is id-signedData (1.2.840.113549.1.7.2). 652 -- The eContentType field for the inner type 653 -- SignedData (when unencrypted) is id-pkrkeydata 654 -- (1.2.840.113549.1.7.3) and the eContent field 655 -- contains the DER encoding of the type 656 -- ReplyKeyPack. 657 -- ReplyKeyPack is defined in Section 3.2.3.2. 658 ... 659 } 661 DHRepInfo ::= SEQUENCE { 662 dhSignedData [0] IMPLICIT OCTET STRING, 663 -- Contains a CMS type ContentInfo encoded according 664 -- to [RFC3852]. 665 -- The contentType field of the type ContentInfo is 666 -- id-signedData (1.2.840.113549.1.7.2), and the 667 -- content field is a SignedData. 668 -- The eContentType field for the type SignedData is 669 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 670 -- eContent field contains the DER encoding of the 671 -- type KDCDHKeyInfo. 672 -- KDCDHKeyInfo is defined below. 673 serverDHNonce [1] DHNonce OPTIONAL 674 -- Present if and only if dhKeyExpiration is 675 -- present in the KDCDHKeyInfo. 676 } 678 KDCDHKeyInfo ::= SEQUENCE { 679 subjectPublicKey [0] BIT STRING, 680 -- KDC's DH public key. 681 -- The DH public key value is encoded as a BIT 682 -- STRING, as specified in Section 2.3.3 of 683 -- [RFC3279]. 684 nonce [1] INTEGER (0..4294967295), 685 -- Contains the nonce in the PKAuthenticator of the 686 -- request if DH keys are NOT reused, 687 -- 0 otherwise. 688 dhKeyExpiration [2] KerberosTime OPTIONAL, 689 -- Expiration time for KDC's key pair, 690 -- present if and only if DH keys are reused. If 691 -- this field is omitted then the serverDHNonce 692 -- field MUST also be omitted. See Section 3.2.3.1. 694 ... 695 } 697 3.2.3.1 Using Diffie-Hellman Key Exchange 699 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 701 The ContentInfo [RFC3852] structure for the dhSignedData field is 702 filled in as follows: 704 1. The contentType field of the type ContentInfo is id-signedData 705 (as defined in [RFC3852]), and the content field is a SignedData 706 (as defined in [RFC3852]). 708 2. The eContentType field for the type SignedData is the OID value 709 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 710 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 712 3. The eContent field for the type SignedData contains the DER 713 encoding of the type KDCDHKeyInfo. 715 4. The signerInfos field of the type SignedData contains a single 716 signerInfo, which contains the signature over the type 717 KDCDHKeyInfo. 719 5. The certificates field of the type SignedData contains 720 certificates intended to facilitate certification path 721 construction, so that the client can verify the KDC's signature 722 over the type KDCDHKeyInfo. The information contained in the 723 trustedCertifiers in the request SHOULD be used by the KDC as 724 hints to guide its selection of an appropriate certificate chain 725 to return to the client. This field may only. be left empty if 726 the KDC public key specified by the kdcPkId field in the PA-PK- 727 AS-REQ was used for signing. Otherwise, for path validation, 728 these certificates SHOULD be sufficient to construct at least one 729 certification path from the KDC certificate to one trust anchor 730 acceptable by the client [CAPATH]. The KDC MUST be capable of 731 including such a set of certificates if configured to do so. The 732 certificates field MUST NOT contain "root" CA certificates. 734 6. If the client included the clientDHNonce field, then the KDC may 735 choose to reuse its DH keys (see Section 3.2.3.1). If the server 736 reuses DH keys then it MUST include an expiration time in the 737 dhKeyExpiration field. Past the point of the expiration time, 738 the signature over the type DHRepInfo is considered expired/ 739 invalid. When the server reuses DH keys then it MUST include a 740 serverDHNonce at least as long as the length of keys for the 741 symmetric encryption system used to encrypt the AS reply. Note 742 that including the serverDHNonce changes how the client and 743 server calculate the key to use to encrypt the reply; see below 744 for details. The KDC SHOULD NOT reuse DH keys unless the 745 clientDHNonce field is present in the request. 747 The AS reply key is derived as follows: 749 1. Both the KDC and the client calculate the shared secret value as 750 follows: 752 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 753 shared secret value. DHSharedSecret is the value ZZ as 754 described in Section 2.1.1 of [RFC2631]. 756 DHSharedSecret is first padded with leading zeros such that the 757 size of DHSharedSecret in octets is the same as that of the 758 modulus, then represented as a string of octets in big-endian 759 order. 761 Implementation note: Both the client and the KDC can cache the 762 triple (ya, yb, DHSharedSecret), where ya is the client's public 763 key and yb is the KDC's public key. If both ya and yb are the 764 same in a later exchange, the cached DHSharedSecret can be used. 766 2. Let K be the key-generation seed length [RFC3961] of the AS reply 767 key whose enctype is selected according to [RFC4120]. 769 3. Define the function octetstring2key() as follows: 771 octetstring2key(x) == random-to-key(K-truncate( 772 SHA1(0x00 | x) | 773 SHA1(0x01 | x) | 774 SHA1(0x02 | x) | 775 ... 776 )) 778 where x is an octet string; | is the concatenation operator; 0x00, 779 0x01, 0x02, etc., are each represented as a single octet; random- 780 to-key() is an operation that generates a protocol key from a 781 bitstring of length K; and K-truncate truncates its input to the 782 first K bits. Both K and random-to-key() are as defined in the 783 kcrypto profile [RFC3961] for the enctype of the AS reply key. 785 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 786 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 787 strings. 789 5. The AS reply key k is: 791 k = octetstring2key(DHSharedSecret | n_c | n_k) 793 3.2.3.2 Using Public Key Encryption 795 In this case, the PA-PK-AS-REP contains a ContentInfo structure 796 wrapped in an OCTET STRING. The AS reply key is encrypted in the 797 encKeyPack field, which contains data of type ReplyKeyPack: 799 ReplyKeyPack ::= SEQUENCE { 800 replyKey [0] EncryptionKey, 801 -- Contains the session key used to encrypt the 802 -- enc-part field in the AS-REP. 803 asChecksum [1] Checksum, 804 -- Contains the checksum of the AS-REQ 805 -- corresponding to the containing AS-REP. 806 -- The checksum is performed over the type AS-REQ. 807 -- The protocol key [RFC3961] of the checksum is the 808 -- replyKey and the key usage number is 6. 809 -- If the replyKey's enctype is "newer" [RFC4120] 810 -- [RFC4121], the checksum is the required 811 -- checksum operation [RFC3961] for that enctype. 812 -- The client MUST verify this checksum upon receipt 813 -- of the AS-REP. 814 ... 815 } 817 The ContentInfo [RFC3852] structure for the encKeyPack field is 818 filled in as follows: 820 1. The contentType field of the type ContentInfo is id-envelopedData 821 (as defined in [RFC3852]), and the content field is an 822 EnvelopedData (as defined in [RFC3852]). 824 2. The contentType field for the type EnvelopedData is id- 825 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 826 pkcs (1) pkcs7 (7) signedData (2) }. 828 3. The eContentType field for the inner type SignedData (when 829 decrypted from the encryptedContent field for the type 830 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 831 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 833 4. The eContent field for the inner type SignedData contains the DER 834 encoding of the type ReplyKeyPack. 836 5. The signerInfos field of the inner type SignedData contains a 837 single signerInfo, which contains the signature over the type 838 ReplyKeyPack. 840 6. The certificates field of the inner type SignedData contains 841 certificates intended to facilitate certification path 842 construction, so that the client can verify the KDC's signature 843 over the type ReplyKeyPack. The information contained in the 844 trustedCertifiers in the request SHOULD be used by the KDC as 845 hints to guide its selection of an appropriate certificate chain 846 to return to the client. This field may only be left empty if 847 the KDC public key specified by the kdcPkId field in the PA-PK- 848 AS-REQ was used for signing. Otherwise, for path validation, 849 these certificates SHOULD be sufficient to construct at least one 850 certification path from the KDC certificate to one trust anchor 851 acceptable by the client [CAPATH]. The KDC MUST be capable of 852 including such a set of certificates if configured to do so. The 853 certificates field MUST NOT contain "root" CA certificates. 855 7. The recipientInfos field of the type EnvelopedData is a SET which 856 MUST contain exactly one member of type KeyTransRecipientInfo. 857 The encryptedKey of this member contains the temporary key which 858 is encrypted using the client's public key. 860 8. The unprotectedAttrs or originatorInfo fields of the type 861 EnvelopedData MAY be present. 863 Implementations of this RSA encryption key delivery method are 864 RECOMMENDED to support for RSA keys at least 2048 bits in size. 866 3.2.4 Receipt of KDC Reply 868 Upon receipt of the KDC's reply, the client proceeds as follows. If 869 the PA-PK-AS-REP contains the dhSignedData field, the client derives 870 the AS reply key using the same procedure used by the KDC as defined 871 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 872 field, and the client decrypts and extracts the temporary key in the 873 encryptedKey field of the member KeyTransRecipientInfo, and then uses 874 that as the AS reply key. 876 In either case, the client MUST verify the signature in the 877 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 878 be validated according to [RFC3280]. In addition, unless the client 879 can otherwise verify that the public key used to verify the KDC's 880 signature is bound to the KDC of the target realm, the KDC's X.509 881 certificate MUST contain a Subject Alternative Name extension 882 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as 883 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 884 matches the name of the TGS of the target realm (as defined in 885 Section 7.3 of [RFC4120]). 887 Based on local policy, the client MAY require that the KDC 888 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: 890 id-pkkdcekuoid OBJECT IDENTIFIER ::= 891 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 892 pkinit(3) pkkdcekuoid(5) } 893 -- Signing KDC responses. 894 -- Key usage bits that MUST be consistent: 895 -- digitalSignature. 897 If all applicable checks are satisfied, the client then decrypts the 898 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 899 and then proceeds as described in [RFC4120]. 901 Implementation note: CAs issuing KDC certificates SHOULD place all 902 "short" and "fully-qualified" Kerberos realm names of the KDC (one 903 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 904 flexibility. 906 3.3 Interoperability Requirements 908 The client MUST be capable of sending a set of certificates 909 sufficient to allow the KDC to construct a certification path for the 910 client's certificate, if the correct set of certificates is provided 911 through configuration or policy. 913 If the client sends all the X.509 certificates on a certification 914 path to a trust anchor acceptable by the KDC, and the KDC can not 915 verify the client's public key otherwise, the KDC MUST be able to 916 process path validation for the client's certificate based on the 917 certificates in the request. 919 The KDC MUST be capable of sending a set of certificates sufficient 920 to allow the client to construct a certification path for the KDC's 921 certificate, if the correct set of certificates is provided through 922 configuration or policy. 924 If the KDC sends all the X.509 certificates on a certification path 925 to a trust anchor acceptable by the client, and the client can not 926 verify the KDC's public key otherwise, the client MUST be able to 927 process path validation for the KDC's certificate based on the 928 certificates in the reply. 930 3.4 KDC Indication of PKINIT Support 932 If pre-authentication is required, but was not present in the 933 request, per [RFC4120] an error message with the code 934 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 935 stored in the e-data field of the KRB-ERROR message to specify which 936 pre-authentication mechanisms are acceptable. The KDC can then 937 indicate the support of PKINIT by including an empty element whose 938 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 940 Otherwise if it is required by the KDC's local policy that the client 941 must be pre-authenticated using the pre-authentication mechanism 942 specified in this document, but no PKINIT pre-authentication was 943 present in the request, an error message with the code 944 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 946 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 947 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 948 STRING), and clients MUST ignore this and any other value. Future 949 extensions to this protocol may specify other data to send instead of 950 an empty OCTET STRING. 952 4. Security Considerations 954 The symmetric reply key size and Diffie-Hellman field size or RSA 955 modulus size should be chosen so as to provide sufficient 956 cryptographic security [RFC3766]. 958 When MODP Diffie-Hellman is used, the exponents should have at least 959 twice as many bits as the symmetric keys that will be derived from 960 them [ODL99]. 962 PKINIT raises certain security considerations beyond those that can 963 be regulated strictly in protocol definitions. We will address them 964 in this section. 966 PKINIT extends the cross-realm model to the public-key 967 infrastructure. Users of PKINIT must understand security policies 968 and procedures appropriate to the use of Public Key Infrastructures 969 [RFC3280]. 971 Standard Kerberos allows the possibility of interactions between 972 cryptosystems of varying strengths; this document adds interactions 973 with public-key cryptosystems to Kerberos. Some administrative 974 policies may allow the use of relatively weak public keys. Using 975 such keys to wrap data encrypted under stronger conventional 976 cryptosystems may be inappropriate. 978 PKINIT requires keys for symmetric cryptosystems to be generated. 979 Some such systems contain "weak" keys. For recommendations regarding 980 these weak keys, see [RFC4120]. 982 PKINIT allows the use of the same RSA key pair for encryption and 983 signing when doing RSA encryption based key delivery. This is not 984 recommended usage of RSA keys [RFC3447], by using DH based key 985 delivery this is avoided. 987 Care should be taken in how certificates are chosen for the purposes 988 of authentication using PKINIT. Some local policies may require that 989 key escrow be used for certain certificate types. Deployers of 990 PKINIT should be aware of the implications of using certificates that 991 have escrowed keys for the purposes of authentication. Because 992 signing only certificates are normally not escrowed, by using DH 993 based key delivery this is avoided. 995 PKINIT does not provide for a "return routability" test to prevent 996 attackers from mounting a denial-of-service attack on the KDC by 997 causing it to perform unnecessary and expensive public-key 998 operations. Strictly speaking, this is also true of standard 999 Kerberos, although the potential cost is not as great, because 1000 standard Kerberos does not make use of public-key cryptography. By 1001 using DH based key delivery and reusing DH keys, the necessary crypto 1002 processing cost per request can be minimized. 1004 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1005 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1006 be used if the KDC itself vouches for the user's certificate. 1008 5. Acknowledgements 1010 The following people have made significant contributions to this 1011 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist 1012 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 1013 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik 1014 Jaganathan, Chaskiel M Grundman and Stefan Santesson. 1016 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1017 Jonathan Trostle who wrote earlier versions of this document. 1019 The authors are indebted to the Kerberos working group chair Jeffrey 1020 Hutzelman who kept track of various issues and was enormously helpful 1021 during the creation of this document. 1023 Some of the ideas on which this document is based arose during 1024 discussions over several years between members of the SAAG, the IETF 1025 CAT working group, and the PSRG, regarding integration of Kerberos 1026 and SPX. Some ideas have also been drawn from the DASS system. 1027 These changes are by no means endorsed by these groups. This is an 1028 attempt to revive some of the goals of those groups, and this 1029 document approaches those goals primarily from the Kerberos 1030 perspective. 1032 Lastly, comments from groups working on similar ideas in DCE have 1033 been invaluable. 1035 6. IANA Considerations 1037 This document has no actions for IANA. 1039 7. References 1041 7.1 Normative References 1043 [IEEE1363] 1044 IEEE, "Standard Specifications for Public Key 1045 Cryptography", IEEE 1363, 2000. 1047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, March 1997. 1050 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1051 RFC 2412, November 1998. 1053 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1054 RFC 2631, June 1999. 1056 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1057 Identifiers for the Internet X.509 Public Key 1058 Infrastructure Certificate and Certificate Revocation List 1059 (CRL) Profile", RFC 3279, April 2002. 1061 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1062 X.509 Public Key Infrastructure Certificate and 1063 Certificate Revocation List (CRL) Profile", RFC 3280, 1064 April 2002. 1066 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1067 Algorithms", RFC 3370, August 2002. 1069 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1070 Standards (PKCS) #1: RSA Cryptography Specifications 1071 Version 2.1", RFC 3447, February 2003. 1073 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1074 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1075 RFC 3526, May 2003. 1077 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1078 Encryption Algorithm in Cryptographic Message Syntax 1079 (CMS)", RFC 3565, July 2003. 1081 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1082 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1083 RFC 3766, April 2004. 1085 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1086 RFC 3852, July 2004. 1088 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1089 Kerberos 5", RFC 3961, February 2005. 1091 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1092 Encryption for Kerberos 5", RFC 3962, February 2005. 1094 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1095 Kerberos Network Authentication Service (V5)", RFC 4120, 1096 July 2005. 1098 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1099 Version 5 Generic Security Service Application Program 1100 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1101 July 2005. 1103 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication 1104 Framework. 1997. 1106 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1107 Rules (BER), Canonical Encoding Rules (CER) and 1108 Distinguished Encoding Rules (DER), ITU-T Recommendation 1109 X.690 (1997) | ISO/IEC International Standard 1110 8825-1:1998. 1112 7.2 Informative References 1114 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1115 pkix-certpathbuild. Work in Progress. 1117 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1118 Sizes", Journal of Cryptology 14 (2001) 255-293. 1120 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1121 future, Designs, Codes, and Cryptography (1999)". 1123 Authors' Addresses 1125 Brian Tung 1126 USC Information Sciences Institute 1127 4676 Admiralty Way Suite 1001, Marina del Rey CA 1128 Marina del Rey, CA 90292 1129 US 1131 Email: brian@isi.edu 1133 Larry Zhu 1134 Microsoft Corporation 1135 One Microsoft Way 1136 Redmond, WA 98052 1137 US 1139 Email: lzhu@microsoft.com 1141 Appendix A. PKINIT ASN.1 Module 1143 KerberosV5-PK-INIT-SPEC { 1144 iso(1) identified-organization(3) dod(6) internet(1) 1145 security(5) kerberosV5(2) modules(4) pkinit(5) 1146 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1148 IMPORTS 1149 SubjectPublicKeyInfo, AlgorithmIdentifier 1150 FROM PKIX1Explicit88 { iso (1) 1151 identified-organization (3) dod (6) internet (1) 1152 security (5) mechanisms (5) pkix (7) id-mod (0) 1153 id-pkix1-explicit (18) } 1154 -- As defined in RFC 3280. 1156 DomainParameters 1157 FROM PKIX1Algorithms88 { iso(1) 1158 identified-organization(3) dod(6) 1159 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1160 id-mod-pkix1-algorithms(17) } 1161 -- As defined in RFC 3279. 1163 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey 1164 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1165 dod(6) internet(1) security(5) kerberosV5(2) 1166 modules(4) krb5spec2(2) } ; 1168 id-pkinit OBJECT IDENTIFIER ::= 1169 { iso (1) org (3) dod (6) internet (1) security (5) 1170 kerberosv5 (2) pkinit (3) } 1172 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1173 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1174 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1175 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1176 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1178 pa-pk-as-req INTEGER ::= 16 1179 pa-pk-as-rep INTEGER ::= 17 1181 ad-initial-verified-cas INTEGER ::= 9 1183 td-trusted-certifiers INTEGER ::= 104 1184 td-invalid-certificates INTEGER ::= 105 1185 td-dh-parameters INTEGER ::= 109 1187 PA-PK-AS-REQ ::= SEQUENCE { 1188 signedAuthPack [0] IMPLICIT OCTET STRING, 1189 -- Contains a CMS type ContentInfo encoded 1190 -- according to [RFC3852]. 1191 -- The contentType field of the type ContentInfo 1192 -- is id-signedData (1.2.840.113549.1.7.2), 1193 -- and the content field is a SignedData. 1194 -- The eContentType field for the type SignedData is 1195 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1196 -- eContent field contains the DER encoding of the 1197 -- type AuthPack. 1198 -- AuthPack is defined below. 1199 trustedCertifiers [1] SEQUENCE OF 1200 ExternalPrincipalIdentifier OPTIONAL, 1201 -- A list of CAs, trusted by the client, that can 1202 -- be used to certify the KDC. 1203 -- Each ExternalPrincipalIdentifier identifies a CA 1204 -- or a CA certificate (thereby its public key). 1205 -- The information contained in the 1206 -- trustedCertifiers SHOULD be used by the KDC as 1207 -- hints to guide its selection of an appropriate 1208 -- certificate chain to return to the client. 1209 kdcPkId [2] IMPLICIT OCTET STRING 1210 OPTIONAL, 1211 -- Contains a CMS type SignerIdentifier encoded 1212 -- according to [RFC3852]. 1214 -- Identifies, if present, a particular KDC 1215 -- public key that the client already has. 1216 ... 1217 } 1219 DHNonce ::= OCTET STRING 1221 ExternalPrincipalIdentifier ::= SEQUENCE { 1222 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1223 -- Contains a PKIX type Name encoded according to 1224 -- [RFC3280]. 1225 -- Identifies the certificate subject by the 1226 -- distinguished subject name. 1227 -- REQUIRED when there is a distinguished subject 1228 -- name present in the certificate. 1229 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1230 -- Contains a CMS type IssuerAndSerialNumber encoded 1231 -- according to [RFC3852]. 1232 -- Identifies a certificate of the subject. 1233 -- REQUIRED for TD-INVALID-CERTIFICATES and 1234 -- TD-TRUSTED-CERTIFIERS. 1235 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1236 -- Identifies the subject's public key by a key 1237 -- identifier. When an X.509 certificate is 1238 -- referenced, this key identifier matches the X.509 1239 -- subjectKeyIdentifier extension value. When other 1240 -- certificate formats are referenced, the documents 1241 -- that specify the certificate format and their use 1242 -- with the CMS must include details on matching the 1243 -- key identifier to the appropriate certificate 1244 -- field. 1245 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1246 ... 1247 } 1249 AuthPack ::= SEQUENCE { 1250 pkAuthenticator [0] PKAuthenticator, 1251 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1252 -- Type SubjectPublicKeyInfo is defined in 1253 -- [RFC3280]. 1254 -- Specifies Diffie-Hellman domain parameters 1255 -- and the client's public key value [IEEE1363]. 1256 -- The DH public key value is encoded as a BIT 1257 -- STRING, as specified in Section 2.3.3 of 1258 -- [RFC3279]. 1259 -- This field is present only if the client wishes 1260 -- to use the Diffie-Hellman key agreement method. 1261 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1262 OPTIONAL, 1263 -- Type AlgorithmIdentifier is defined in 1264 -- [RFC3280]. 1265 -- List of CMS encryption types supported by the 1266 -- client in order of (decreasing) preference. 1267 clientDHNonce [3] DHNonce OPTIONAL, 1268 -- Present only if the client indicates that it 1269 -- wishes to reuse DH keys or to allow the KDC to 1270 -- do so. 1271 ... 1272 } 1274 PKAuthenticator ::= SEQUENCE { 1275 cusec [0] INTEGER (0..999999), 1276 ctime [1] KerberosTime, 1277 -- cusec and ctime are used as in [RFC4120], for 1278 -- replay prevention. 1279 nonce [2] INTEGER (0..4294967295), 1280 -- Chosen randomly; This nonce does not need to 1281 -- match with the nonce in the KDC-REQ-BODY. 1282 paChecksum [3] OCTET STRING, 1283 -- Contains the SHA1 checksum, performed over 1284 -- KDC-REQ-BODY. 1285 ... 1286 } 1288 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1289 ExternalPrincipalIdentifier 1290 -- Identifies a list of CAs trusted by the KDC. 1291 -- Each ExternalPrincipalIdentifier identifies a CA 1292 -- or a CA certificate (thereby its public key). 1294 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1295 ExternalPrincipalIdentifier 1296 -- Each ExternalPrincipalIdentifier identifies a 1297 -- certificate (sent by the client) with an invalid 1298 -- signature. 1300 KRB5PrincipalName ::= SEQUENCE { 1301 realm [0] Realm, 1302 principalName [1] PrincipalName 1303 } 1305 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1306 ExternalPrincipalIdentifier 1307 -- Identifies the certification path based on which 1308 -- the client certificate was validated. 1309 -- Each ExternalPrincipalIdentifier identifies a CA 1310 -- or a CA certificate (thereby its public key). 1312 PA-PK-AS-REP ::= CHOICE { 1313 dhInfo [0] DHRepInfo, 1314 -- Selected when Diffie-Hellman key exchange is 1315 -- used. 1316 encKeyPack [1] IMPLICIT OCTET STRING, 1317 -- Selected when public key encryption is used. 1318 -- Contains a CMS type ContentInfo encoded 1319 -- according to [RFC3852]. 1320 -- The contentType field of the type ContentInfo is 1321 -- id-envelopedData (1.2.840.113549.1.7.3). 1322 -- The content field is an EnvelopedData. 1323 -- The contentType field for the type EnvelopedData 1324 -- is id-signedData (1.2.840.113549.1.7.2). 1325 -- The eContentType field for the inner type 1326 -- SignedData (when unencrypted) is id-pkrkeydata 1327 -- (1.2.840.113549.1.7.3) and the eContent field 1328 -- contains the DER encoding of the type 1329 -- ReplyKeyPack. 1330 -- ReplyKeyPack is defined below. 1331 ... 1332 } 1334 DHRepInfo ::= SEQUENCE { 1335 dhSignedData [0] IMPLICIT OCTET STRING, 1336 -- Contains a CMS type ContentInfo encoded according 1337 -- to [RFC3852]. 1338 -- The contentType field of the type ContentInfo is 1339 -- id-signedData (1.2.840.113549.1.7.2), and the 1340 -- content field is a SignedData. 1341 -- The eContentType field for the type SignedData is 1342 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1343 -- eContent field contains the DER encoding of the 1344 -- type KDCDHKeyInfo. 1345 -- KDCDHKeyInfo is defined below. 1346 serverDHNonce [1] DHNonce OPTIONAL 1347 -- Present if and only if dhKeyExpiration is 1348 -- present. 1349 } 1351 KDCDHKeyInfo ::= SEQUENCE { 1352 subjectPublicKey [0] BIT STRING, 1353 -- KDC's DH public key. 1354 -- The DH public key value is encoded as a BIT 1355 -- STRING, as specified in Section 2.3.3 of 1356 -- [RFC3279]. 1357 nonce [1] INTEGER (0..4294967295), 1358 -- Contains the nonce in the PKAuthenticator of the 1359 -- request if DH keys are NOT reused, 1360 -- 0 otherwise. 1361 dhKeyExpiration [2] KerberosTime OPTIONAL, 1362 -- Expiration time for KDC's key pair, 1363 -- present if and only if DH keys are reused. If 1364 -- this field is omitted then the serverDHNonce 1365 -- field MUST also be omitted. 1366 ... 1367 } 1369 ReplyKeyPack ::= SEQUENCE { 1370 replyKey [0] EncryptionKey, 1371 -- Contains the session key used to encrypt the 1372 -- enc-part field in the AS-REP. 1373 asChecksum [1] Checksum, 1374 -- Contains the checksum of the AS-REQ 1375 -- corresponding to the containing AS-REP. 1376 -- The checksum is performed over the type AS-REQ. 1377 -- The protocol key [RFC3961] of the checksum is the 1378 -- replyKey and the key usage number is 6. 1379 -- If the replyKey's enctype is "newer" [RFC4120] 1380 -- [RFC4121], the checksum is the required 1381 -- checksum operation [RFC3961] for that enctype. 1382 -- The client MUST verify this checksum upon receipt 1383 -- of the AS-REP. 1384 ... 1385 } 1387 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1388 -- Each AlgorithmIdentifier specifies a set of 1389 -- Diffie-Hellman domain parameters [IEEE1363]. 1390 -- This list is in decreasing preference order. 1391 END 1393 Intellectual Property Statement 1395 The IETF takes no position regarding the validity or scope of any 1396 Intellectual Property Rights or other rights that might be claimed to 1397 pertain to the implementation or use of the technology described in 1398 this document or the extent to which any license under such rights 1399 might or might not be available; nor does it represent that it has 1400 made any independent effort to identify any such rights. Information 1401 on the procedures with respect to rights in RFC documents can be 1402 found in BCP 78 and BCP 79. 1404 Copies of IPR disclosures made to the IETF Secretariat and any 1405 assurances of licenses to be made available, or the result of an 1406 attempt made to obtain a general license or permission for the use of 1407 such proprietary rights by implementers or users of this 1408 specification can be obtained from the IETF on-line IPR repository at 1409 http://www.ietf.org/ipr. 1411 The IETF invites any interested party to bring to its attention any 1412 copyrights, patents or patent applications, or other proprietary 1413 rights that may cover technology that may be required to implement 1414 this standard. Please address the information to the IETF at 1415 ietf-ipr@ietf.org. 1417 Disclaimer of Validity 1419 This document and the information contained herein are provided on an 1420 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1421 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1422 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1423 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1424 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1425 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1427 Copyright Statement 1429 Copyright (C) The Internet Society (2005). This document is subject 1430 to the rights, licenses and restrictions contained in BCP 78, and 1431 except as set forth therein, the authors retain all their rights. 1433 Acknowledgment 1435 Funding for the RFC Editor function is currently provided by the 1436 Internet Society.