idnits 2.17.00 (12 Aug 2021) /tmp/idnits6708/draft-ietf-cat-kerberos-pk-init-28.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 1538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1528. ** 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 (September 12, 2005) is 6094 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 1382 -- Looks like a reference, but probably isn't: '1' on line 1385 -- Looks like a reference, but probably isn't: '2' on line 1373 -- Looks like a reference, but probably isn't: '3' on line 1294 == Unused Reference: 'LENSTRA' is defined on line 1153, 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: March 16, 2006 L. Zhu 5 Microsoft Corporation 6 September 12, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-28 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 March 16, 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 . . . . . . . . . . . . . . . . . . . . . . . 23 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 70 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25 71 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 31 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 73 Intellectual Property and Copyright Statements . . . . . . . . . . 34 75 1. Introduction 77 A client typically authenticates itself to a service in Kerberos 78 using three distinct though related exchanges. First, the client 79 requests a ticket-granting ticket (TGT) from the Kerberos 80 authentication server (AS). Then, it uses the TGT to request a 81 service ticket from the Kerberos ticket-granting server (TGS). 82 Usually, the AS and TGS are integrated in a single device known as a 83 Kerberos Key Distribution Center, or KDC. Finally, the client uses 84 the service ticket to authenticate itself to the service. 86 The advantage afforded by the TGT is that the client exposes his 87 long-term secrets only once. The TGT and its associated session key 88 can then be used for any subsequent service ticket requests. One 89 result of this is that all further authentication is independent of 90 the method by which the initial authentication was performed. 91 Consequently, initial authentication provides a convenient place to 92 integrate public-key cryptography into Kerberos authentication. 94 As defined in [RFC4120], Kerberos authentication exchanges use 95 symmetric-key cryptography, in part for performance. One 96 disadvantage of using symmetric-key cryptography is that the keys 97 must be shared, so that before a client can authenticate itself, he 98 must already be registered with the KDC. 100 Conversely, public-key cryptography (in conjunction with an 101 established Public Key Infrastructure) permits authentication without 102 prior registration with a KDC. Adding it to Kerberos allows the 103 widespread use of Kerberized applications by clients without 104 requiring them to register first with a KDC--a requirement that has 105 no inherent security benefit. 107 As noted above, a convenient and efficient place to introduce public- 108 key cryptography into Kerberos is in the initial authentication 109 exchange. This document describes the methods and data formats for 110 integrating public-key cryptography into Kerberos initial 111 authentication. 113 2. Conventions Used in This Document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Both the AS and the TGS are referred to as the KDC. 121 In this document, the encryption key used to encrypt the enc-part 122 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS 123 reply key. 125 3. Extensions 127 This section describes extensions to [RFC4120] for supporting the use 128 of public-key cryptography in the initial request for a ticket. 130 Briefly, this document defines the following extensions to [RFC4120]: 132 1. The client indicates the use of public-key authentication by 133 including a special preauthenticator in the initial request. This 134 preauthenticator contains the client's public-key data and a 135 signature. 137 2. The KDC tests the client's request against its authentication 138 policy and trusted Certification Authorities (CAs). 140 3. If the request passes the verification tests, the KDC replies as 141 usual, but the reply is encrypted using either: 143 a. a key generated through a Diffie-Hellman (DH) key exchange 144 [RFC2631] [IEEE1363] with the client, signed using the KDC's 145 signature key; or 147 b. a symmetric encryption key, signed using the KDC's signature 148 key and encrypted using the client's public key. 150 Any keying material required by the client to obtain the 151 encryption key for decrypting the KDC reply is returned in a pre- 152 authentication field accompanying the usual reply. 154 4. The client validates the KDC's signature, obtains the encryption 155 key, decrypts the reply, and then proceeds as usual. 157 Section 3.1 of this document enumerates the required algorithms and 158 necessary extension message types. Section 3.2 describes the 159 extension messages in greater detail. 161 3.1. Definitions, Requirements, and Constants 163 3.1.1. Required Algorithms 165 All PKINIT implementations MUST support the following algorithms: 167 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- 168 sha1-96 [RFC3962]. 170 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 172 o AS reply key delivery method: Diffie-Hellman key exchange 173 [RFC2631]. 175 In addition, implementations of this specification MUST be capable of 176 processing the Extended Key Usage (EKU) extension and the id-pksan 177 (as defined in Section 3.2.2) otherName of the Subject Alternative 178 Name (SAN) extension in X.509 certificates [RFC3280], if present. 180 3.1.2. Defined Message and Encryption Types 182 PKINIT makes use of the following new pre-authentication types: 184 PA_PK_AS_REQ 16 185 PA_PK_AS_REP 17 187 PKINIT also makes use of the following new authorization data type: 189 AD_INITIAL_VERIFIED_CAS 9 191 PKINIT introduces the following new error codes: 193 KDC_ERR_CLIENT_NOT_TRUSTED 62 194 KDC_ERR_INVALID_SIG 64 195 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 196 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 197 KDC_ERR_INVALID_CERTIFICATE 71 198 KDC_ERR_REVOKED_CERTIFICATE 72 199 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 200 KDC_ERR_CLIENT_NAME_MISMATCH 75 201 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 203 PKINIT uses the following typed data types for errors: 205 TD_TRUSTED_CERTIFIERS 104 206 TD_INVALID_CERTIFICATES 105 207 TD_DH_PARAMETERS 109 209 PKINIT defines the following encryption types, for use in the AS-REQ 210 message to indicate acceptance of the corresponding algorithms that 211 can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in 212 the reply: 214 dsaWithSHA1-CmsOID 9 215 md5WithRSAEncryption-CmsOID 10 216 sha1WithRSAEncryption-CmsOID 11 217 rc2CBC-EnvOID 12 218 rsaEncryption-EnvOID (PKCS1 v1.5) 13 219 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 220 des-ede3-cbc-EnvOID 15 222 The ASN.1 module for all structures defined in this document (plus 223 IMPORT statements for all imported structures) is given in 224 Appendix A. 226 All structures defined in or imported into this document MUST be 227 encoded using Distinguished Encoding Rules (DER) [X690] (unless 228 otherwise noted). All data structures carried in OCTET STRINGs must 229 be encoded according to the rules specified in corresponding 230 specifications. 232 Interoperability note: Some implementations may not be able to decode 233 wrapped CMS objects encoded with BER but not DER; specifically, they 234 may not be able to decode infinite length encodings. To maximize 235 interoperability, implementers SHOULD encode CMS objects used in 236 PKINIT with DER. 238 3.1.3. Algorithm Identifiers 240 PKINIT does not define, but does make use of, the following algorithm 241 identifiers. 243 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman 244 key agreement [RFC3279]: 246 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) 248 PKINIT uses the following signature algorithm identifiers [RFC3279]: 250 sha-1WithRSAEncryption (RSA with SHA1) 251 md5WithRSAEncryption (RSA with MD5) 252 id-dsa-with-sha1 (DSA with SHA1) 254 PKINIT uses the following encryption algorithm identifiers [RFC3447] 255 for encrypting the temporary key with a public key: 257 rsaEncryption (PKCS1 v1.5) 258 id-RSAES-OAEP (PKCS1 v2.0) 260 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] 261 for encrypting the AS reply key with the temporary key: 263 des-ede3-cbc (three-key 3DES, CBC mode) 264 rc2-cbc (RC2, CBC mode) 265 id-aes256-CBC (AES-256, CBC mode) 267 3.2. PKINIT Pre-authentication Syntax and Use 269 This section defines the syntax and use of the various pre- 270 authentication fields employed by PKINIT. 272 3.2.1. Generation of Client Request 274 The initial authentication request (AS-REQ) is sent as per [RFC4120]; 275 in addition, a pre-authentication data element, whose padata-type is 276 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the 277 type PA-PK-AS-REQ, is included. 279 PA-PK-AS-REQ ::= SEQUENCE { 280 signedAuthPack [0] IMPLICIT OCTET STRING, 281 -- Contains a CMS type ContentInfo encoded 282 -- according to [RFC3852]. 283 -- The contentType field of the type ContentInfo 284 -- is id-signedData (1.2.840.113549.1.7.2), 285 -- and the content field is a SignedData. 286 -- The eContentType field for the type SignedData is 287 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 288 -- eContent field contains the DER encoding of the 289 -- type AuthPack. 290 -- AuthPack is defined below. 291 trustedCertifiers [1] SEQUENCE OF 292 ExternalPrincipalIdentifier OPTIONAL, 293 -- A list of CAs, trusted by the client, that can 294 -- be used to certify the KDC. 295 -- Each ExternalPrincipalIdentifier identifies a CA 296 -- or a CA certificate (thereby its public key). 297 -- The information contained in the 298 -- trustedCertifiers SHOULD be used by the KDC as 299 -- hints to guide its selection of an appropriate 300 -- certificate chain to return to the client. 301 kdcPkId [2] IMPLICIT OCTET STRING 302 OPTIONAL, 303 -- Contains a CMS type SignerIdentifier encoded 304 -- according to [RFC3852]. 305 -- Identifies, if present, a particular KDC 306 -- public key that the client already has. 307 ... 308 } 310 DHNonce ::= OCTET STRING 311 ExternalPrincipalIdentifier ::= SEQUENCE { 312 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 313 -- Contains a PKIX type Name encoded according to 314 -- [RFC3280]. 315 -- Identifies the certificate subject by the 316 -- distinguished subject name. 317 -- REQUIRED when there is a distinguished subject 318 -- name present in the certificate. 319 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 320 -- Contains a CMS type IssuerAndSerialNumber encoded 321 -- according to [RFC3852]. 322 -- Identifies a certificate of the subject. 323 -- REQUIRED for TD-INVALID-CERTIFICATES and 324 -- TD-TRUSTED-CERTIFIERS. 325 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 326 -- Identifies the subject's public key by a key 327 -- identifier. When an X.509 certificate is 328 -- referenced, this key identifier matches the X.509 329 -- subjectKeyIdentifier extension value. When other 330 -- certificate formats are referenced, the documents 331 -- that specify the certificate format and their use 332 -- with the CMS must include details on matching the 333 -- key identifier to the appropriate certificate 334 -- field. 335 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 336 ... 337 } 339 AuthPack ::= SEQUENCE { 340 pkAuthenticator [0] PKAuthenticator, 341 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 342 -- Type SubjectPublicKeyInfo is defined in 343 -- [RFC3280]. 344 -- Specifies Diffie-Hellman domain parameters 345 -- and the client's public key value [IEEE1363]. 346 -- The DH public key value is encoded as a BIT 347 -- STRING according to [RFC3279]. 348 -- This field is present only if the client wishes 349 -- to use the Diffie-Hellman key agreement method. 350 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 351 OPTIONAL, 352 -- Type AlgorithmIdentifier is defined in 353 -- [RFC3280]. 354 -- List of CMS encryption types supported by the 355 -- client in order of (decreasing) preference. 356 clientDHNonce [3] DHNonce OPTIONAL, 357 -- Present only if the client indicates that it 358 -- wishes to reuse DH keys or to allow the KDC to 359 -- do so (see Section 3.2.3.1). 360 ... 361 } 363 PKAuthenticator ::= SEQUENCE { 364 cusec [0] INTEGER (0..999999), 365 ctime [1] KerberosTime, 366 -- cusec and ctime are used as in [RFC4120], for 367 -- replay prevention. 368 nonce [2] INTEGER (0..4294967295), 369 -- Chosen randomly; This nonce does not need to 370 -- match with the nonce in the KDC-REQ-BODY. 371 paChecksum [3] OCTET STRING, 372 -- Contains the SHA1 checksum, performed over 373 -- KDC-REQ-BODY. 374 ... 375 } 377 The ContentInfo [RFC3852] structure for the signedAuthPack field is 378 filled out as follows: 380 1. The contentType field of the type ContentInfo is id-signedData 381 (as defined in [RFC3852]), and the content field is a SignedData 382 (as defined in [RFC3852]). 384 2. The eContentType field for the type SignedData is id-pkauthdata: 385 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 386 pkinit(3) pkauthdata(1) }. 388 3. The eContent field for the type SignedData contains the DER 389 encoding of the type AuthPack. 391 4. The signerInfos field of the type SignedData contains a single 392 signerInfo, which contains the signature over the type AuthPack. 394 5. The certificates field of the type SignedData contains 395 certificates intended to facilitate certification path 396 construction, so that the KDC can verify the signature over the 397 type AuthPack. For path validation, these certificates SHOULD be 398 sufficient to construct at least one certification path from the 399 client certificate to one trust anchor acceptable by the KDC 400 [CAPATH]. The client MUST be capable of including such a set of 401 certificates if configured to do so. The certificates field MUST 402 NOT contain "root" CA certificates. 404 6. The client's Diffie-Hellman public value (clientPublicValue) is 405 included if and only if the client wishes to use the Diffie- 406 Hellman key agreement method. The Diffie-Hellman domain 407 parameters [IEEE1363] for the client's public key are specified 408 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] 409 and the client's Diffie-Hellman public key value is mapped to a 410 subjectPublicKey (a BIT STRING) according to [RFC3279]. When 411 using the Diffie-Hellman key agreement method, implementations 412 MUST support Oakley 1024-bit Modular Exponential (MODP) well- 413 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 414 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known 415 group 16 [RFC3526]. 417 The Diffie-Hellman field size should be chosen so as to provide 418 sufficient cryptographic security [RFC3766]. 420 When MODP Diffie-Hellman is used, the exponents should have at 421 least twice as many bits as the symmetric keys that will be 422 derived from them [ODL99]. 424 7. The client may wish to reuse DH keys or to allow the KDC to do so 425 (see Section 3.2.3.1). If so, then the client includes the 426 clientDHNonce field. This nonce string needs to be as long as 427 the longest key length of the symmetric key types that the client 428 supports. This nonce MUST be chosen randomly. 430 3.2.2. Receipt of Client Request 432 Upon receiving the client's request, the KDC validates it. This 433 section describes the steps that the KDC MUST (unless otherwise 434 noted) take in validating the request. 436 The KDC verifies the client's signature in the signedAuthPack field 437 according to [RFC3852]. 439 If, while validating the client's X.509 certificate [RFC3280], the 440 KDC cannot build a certification path to validate the client's 441 certificate, it sends back a KRB-ERROR [RFC4120] message with the 442 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for 443 this error message is a TYPED-DATA (as defined in [RFC4120]) that 444 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and 445 whose data-value contains the DER encoding of the type TD-TRUSTED- 446 CERTIFIERS: 448 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 449 ExternalPrincipalIdentifier 450 -- Identifies a list of CAs trusted by the KDC. 451 -- Each ExternalPrincipalIdentifier identifies a CA 452 -- or a CA certificate (thereby its public key). 454 Upon receiving this error message, the client SHOULD retry only if it 455 has a different set of certificates (from those of the previous 456 requests) that form a certification path (or a partial path) from one 457 of the trust anchors acceptable by the KDC to its own certificate. 459 If, while processing the certification path, the KDC determines that 460 the signature on one of the certificates in the signedAuthPack field 461 is invalid, it returns a KRB-ERROR [RFC4120] message with the code 462 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error 463 message is a TYPED-DATA that contains an element whose data-type is 464 TD_INVALID_CERTIFICATES, and whose data-value contains the DER 465 encoding of the type TD-INVALID-CERTIFICATES: 467 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 468 ExternalPrincipalIdentifier 469 -- Each ExternalPrincipalIdentifier identifies a 470 -- certificate (sent by the client) with an invalid 471 -- signature. 473 If more than one X.509 certificate signature is invalid, the KDC MAY 474 include one IssuerAndSerialNumber per invalid signature within the 475 TD-INVALID-CERTIFICATES. 477 The client's X.509 certificate is validated according to [RFC3280]. 479 Based on local policy, the KDC may also check whether any X.509 480 certificates in the certification path validating the client's 481 certificate have been revoked. If any of them have been revoked, the 482 KDC MUST return an error message with the code 483 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 484 revocation status but is unable to do so, it SHOULD return an error 485 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The 486 certificate or certificates affected are identified exactly as for 487 the error code KDC_ERR_INVALID_CERTIFICATE (see above). 489 Note that the TD_INVALID_CERTIFICATES error data is only used to 490 identify invalid certificates sent by the client in the request. 492 The client's public key is then used to verify the signature. If the 493 signature fails to verify, the KDC MUST return an error message with 494 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for 495 this error message. 497 In addition to validating the client's signature, the KDC MUST also 498 check that the client's public key used to verify the client's 499 signature is bound to the client's principal name as specified in the 500 AS-REQ as follows: 502 1. If the KDC has its own binding between either the client's 503 signature-verification public key or the client's certificate and 504 the client's Kerberos principal name, it uses that binding. 506 2. Otherwise, if the client's X.509 certificate contains a Subject 507 Alternative Name (SAN) extension carrying a KRB5PrincipalName 508 (defined below) in the otherName field of the type GeneralName 509 [RFC3280], it binds the client's X.509 certificate to that name. 511 The type of the otherName field is AnotherName. The type-id field 512 of the type AnotherName is id-pksan: 514 id-pksan OBJECT IDENTIFIER ::= 515 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 516 x509-sanan (2) } 518 And the value field of the type AnotherName is a 519 KRB5PrincipalName. 521 KRB5PrincipalName ::= SEQUENCE { 522 realm [0] Realm, 523 principalName [1] PrincipalName 524 } 526 If the KDC does not have its own binding and there is no 527 KRB5PrincipalName name present in the client's X.509 certificate, or 528 if the Kerberos name in the request does not match the 529 KRB5PrincipalName in the client's X.509 certificate (including the 530 realm name), the KDC MUST return an error message with the code 531 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 532 this error message. 534 Even if the certification path is validated and the certificate is 535 mapped to the client's principal name, the KDC may decide not to 536 accept the client's certificate, depending on local policy. 538 The KDC MAY require the presence of an Extended Key Usage (EKU) 539 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the 540 client's X.509 certificate: 542 id-pkekuoid OBJECT IDENTIFIER ::= 543 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 544 pkinit(3) pkekuoid(4) } 545 -- PKINIT client authentication. 546 -- Key usage bits that MUST be consistent: 547 -- digitalSignature. 549 If this EKU KeyPurposeId is required but it is not present or if the 550 client certificate is restricted not to be used for PKINIT client 551 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return 552 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There 553 is no accompanying e-data for this error message. KDCs implementing 554 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc- 555 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there 556 are a large number of X.509 client certificates deployed for use with 557 PKINIT which have this EKU. 559 As a matter of local policy, the KDC MAY decide to reject requests on 560 the basis of the absence or presence of other specific EKU OID's. 562 If the client's public key is not accepted, the KDC returns an error 563 message with the code KDC_ERR_CLIENT_NOT_TRUSTED. 565 The KDC MUST check the timestamp to ensure that the request is not a 566 replay, and that the time skew falls within acceptable limits. The 567 recommendations for clock skew times in [RFC4120] apply here. If the 568 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 569 KRB_AP_ERR_SKEW, respectively. 571 If the clientPublicValue is filled in, indicating that the client 572 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 573 check to see if the key parameters satisfy its policy. If they do 574 not, it MUST return an error message with the code 575 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a 576 TYPED-DATA that contains an element whose data-type is 577 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of 578 the type TD-DH-PARAMETERS: 580 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 581 -- Each AlgorithmIdentifier specifies a set of 582 -- Diffie-Hellman domain parameters [IEEE1363]. 583 -- This list is in decreasing preference order. 585 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters 586 that the KDC supports in decreasing preference order, from which the 587 client SHOULD pick one to retry the request. 589 If the client included a kdcPkId field in the PA-PK-AS-REQ and the 590 KDC does not possess the corresponding key, the KDC MUST ignore the 591 kdcPkId field as if the client did not include one. 593 If there is a supportedCMSTypes field in the AuthPack, the KDC must 594 check to see if it supports any of the listed types. If it supports 595 more than one of the types, the KDC SHOULD use the one listed first. 596 If it does not support any of them, it MUST return an error message 597 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. 599 3.2.3. Generation of KDC Reply 601 Assuming that the client's request has been properly validated, the 602 KDC proceeds as per [RFC4120], except as follows. 604 The KDC MUST set the initial flag and include an authorization data 605 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued 606 ticket. The ad-data [RFC4120] field contains the DER encoding of the 607 type AD-INITIAL-VERIFIED-CAS: 609 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 610 ExternalPrincipalIdentifier 611 -- Identifies the certification path based on which 612 -- the client certificate was validated. 613 -- Each ExternalPrincipalIdentifier identifies a CA 614 -- or a CA certificate (thereby its public key). 616 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 617 containers if the list of CAs satisfies the AS' realm's local policy 618 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 619 [RFC4120]). Furthermore, any TGS MUST copy such authorization data 620 from tickets used within a PA-TGS-REQ of the TGS-REQ into the 621 resulting ticket. If the list of CAs satisfies the local KDC's 622 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT 623 container, otherwise it MAY unwrap the authorization data out of the 624 AD-IF-RELEVANT container. 626 Application servers that understand this authorization data type 627 SHOULD apply local policy to determine whether a given ticket bearing 628 such a type *not* contained within an AD-IF-RELEVANT container is 629 acceptable. (This corresponds to the AP server checking the 630 transited field when the TRANSITED-POLICY-CHECKED flag has not been 631 set [RFC4120].) If such a data type is contained within an AD-IF- 632 RELEVANT container, AP servers MAY apply local policy to determine 633 whether the authorization data is acceptable. 635 The content of the AS-REP is otherwise unchanged from [RFC4120]. The 636 KDC encrypts the reply as usual, but not with the client's long-term 637 key. Instead, it encrypts it with either a shared key derived from a 638 Diffie-Hellman exchange, or a generated encryption key. The contents 639 of the PA-PK-AS-REP indicate which key delivery method is used: 641 PA-PK-AS-REP ::= CHOICE { 642 dhInfo [0] DHRepInfo, 643 -- Selected when Diffie-Hellman key exchange is 644 -- used. 645 encKeyPack [1] IMPLICIT OCTET STRING, 646 -- Selected when public key encryption is used. 648 -- Contains a CMS type ContentInfo encoded 649 -- according to [RFC3852]. 650 -- The contentType field of the type ContentInfo is 651 -- id-envelopedData (1.2.840.113549.1.7.3). 652 -- The content field is an EnvelopedData. 653 -- The contentType field for the type EnvelopedData 654 -- is id-signedData (1.2.840.113549.1.7.2). 655 -- The eContentType field for the inner type 656 -- SignedData (when unencrypted) is id-pkrkeydata 657 -- (1.2.840.113549.1.7.3) and the eContent field 658 -- contains the DER encoding of the type 659 -- ReplyKeyPack. 660 -- ReplyKeyPack is defined in Section 3.2.3.2. 661 ... 662 } 664 DHRepInfo ::= SEQUENCE { 665 dhSignedData [0] IMPLICIT OCTET STRING, 666 -- Contains a CMS type ContentInfo encoded according 667 -- to [RFC3852]. 668 -- The contentType field of the type ContentInfo is 669 -- id-signedData (1.2.840.113549.1.7.2), and the 670 -- content field is a SignedData. 671 -- The eContentType field for the type SignedData is 672 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 673 -- eContent field contains the DER encoding of the 674 -- type KDCDHKeyInfo. 675 -- KDCDHKeyInfo is defined below. 676 serverDHNonce [1] DHNonce OPTIONAL 677 -- Present if and only if dhKeyExpiration is 678 -- present in the KDCDHKeyInfo. 679 } 681 KDCDHKeyInfo ::= SEQUENCE { 682 subjectPublicKey [0] BIT STRING, 683 -- KDC's DH public key. 684 -- The DH public key value is encoded as a BIT 685 -- STRING according to [RFC3279]. 686 nonce [1] INTEGER (0..4294967295), 687 -- Contains the nonce in the PKAuthenticator of the 688 -- request if DH keys are NOT reused, 689 -- 0 otherwise. 690 dhKeyExpiration [2] KerberosTime OPTIONAL, 691 -- Expiration time for KDC's key pair, 692 -- present if and only if DH keys are reused. If 693 -- this field is omitted then the serverDHNonce 694 -- field MUST also be omitted. See Section 3.2.3.1. 695 ... 697 } 699 3.2.3.1. Using Diffie-Hellman Key Exchange 701 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 703 The ContentInfo [RFC3852] structure for the dhSignedData field is 704 filled in as follows: 706 1. The contentType field of the type ContentInfo is id-signedData 707 (as defined in [RFC3852]), and the content field is a SignedData 708 (as defined in [RFC3852]). 710 2. The eContentType field for the type SignedData is the OID value 711 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 712 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 714 3. The eContent field for the type SignedData contains the DER 715 encoding of the type KDCDHKeyInfo. 717 4. The signerInfos field of the type SignedData contains a single 718 signerInfo, which contains the signature over the type 719 KDCDHKeyInfo. 721 5. The certificates field of the type SignedData contains 722 certificates intended to facilitate certification path 723 construction, so that the client can verify the KDC's signature 724 over the type KDCDHKeyInfo. The information contained in the 725 trustedCertifiers in the request SHOULD be used by the KDC as 726 hints to guide its selection of an appropriate certificate chain 727 to return to the client. This field may only. be left empty if 728 the KDC public key specified by the kdcPkId field in the PA-PK- 729 AS-REQ was used for signing. Otherwise, for path validation, 730 these certificates SHOULD be sufficient to construct at least one 731 certification path from the KDC certificate to one trust anchor 732 acceptable by the client [CAPATH]. The KDC MUST be capable of 733 including such a set of certificates if configured to do so. The 734 certificates field MUST NOT contain "root" CA certificates. 736 6. If the client included the clientDHNonce field, then the KDC may 737 choose to reuse its DH keys (see Section 3.2.3.1). If the server 738 reuses DH keys then it MUST include an expiration time in the 739 dhKeyExpiration field. Past the point of the expiration time, 740 the signature over the type DHRepInfo is considered expired/ 741 invalid. When the server reuses DH keys then it MUST include a 742 serverDHNonce at least as long as the length of keys for the 743 symmetric encryption system used to encrypt the AS reply. Note 744 that including the serverDHNonce changes how the client and 745 server calculate the key to use to encrypt the reply; see below 746 for details. The KDC SHOULD NOT reuse DH keys unless the 747 clientDHNonce field is present in the request. 749 The AS reply key is derived as follows: 751 1. Both the KDC and the client calculate the shared secret value as 752 follows: 754 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the 755 shared secret value. DHSharedSecret is the value ZZ as 756 described in Section 2.1.1 of [RFC2631]. 758 DHSharedSecret is first padded with leading zeros such that the 759 size of DHSharedSecret in octets is the same as that of the 760 modulus, then represented as a string of octets in big-endian 761 order. 763 Implementation note: Both the client and the KDC can cache the 764 triple (ya, yb, DHSharedSecret), where ya is the client's public 765 key and yb is the KDC's public key. If both ya and yb are the 766 same in a later exchange, the cached DHSharedSecret can be used. 768 2. Let K be the key-generation seed length [RFC3961] of the AS reply 769 key whose enctype is selected according to [RFC4120]. 771 3. Define the function octetstring2key() as follows: 773 octetstring2key(x) == random-to-key(K-truncate( 774 SHA1(0x00 | x) | 775 SHA1(0x01 | x) | 776 SHA1(0x02 | x) | 777 ... 778 )) 780 where x is an octet string; | is the concatenation operator; 0x00, 781 0x01, 0x02, etc., are each represented as a single octet; random- 782 to-key() is an operation that generates a protocol key from a 783 bitstring of length K; and K-truncate truncates its input to the 784 first K bits. Both K and random-to-key() are as defined in the 785 kcrypto profile [RFC3961] for the enctype of the AS reply key. 787 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 788 the serverDHNonce; otherwise, let both n_c and n_k be empty octet 789 strings. 791 5. The AS reply key k is: 793 k = octetstring2key(DHSharedSecret | n_c | n_k) 795 3.2.3.2. Using Public Key Encryption 797 In this case, the PA-PK-AS-REP contains a ContentInfo structure 798 wrapped in an OCTET STRING. The AS reply key is encrypted in the 799 encKeyPack field, which contains data of type ReplyKeyPack: 801 ReplyKeyPack ::= SEQUENCE { 802 replyKey [0] EncryptionKey, 803 -- Contains the session key used to encrypt the 804 -- enc-part field in the AS-REP. 805 asChecksum [1] Checksum, 806 -- Contains the checksum of the AS-REQ 807 -- corresponding to the containing AS-REP. 808 -- The checksum is performed over the type AS-REQ. 809 -- The protocol key [RFC3961] of the checksum is the 810 -- replyKey and the key usage number is 6. 811 -- If the replyKey's enctype is "newer" [RFC4120] 812 -- [RFC4121], the checksum is the required 813 -- checksum operation [RFC3961] for that enctype. 814 -- The client MUST verify this checksum upon receipt 815 -- of the AS-REP. 816 ... 817 } 819 The ContentInfo [RFC3852] structure for the encKeyPack field is 820 filled in as follows: 822 1. The contentType field of the type ContentInfo is id-envelopedData 823 (as defined in [RFC3852]), and the content field is an 824 EnvelopedData (as defined in [RFC3852]). 826 2. The contentType field for the type EnvelopedData is id- 827 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 828 pkcs (1) pkcs7 (7) signedData (2) }. 830 3. The eContentType field for the inner type SignedData (when 831 decrypted from the encryptedContent field for the type 832 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 833 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 835 4. The eContent field for the inner type SignedData contains the DER 836 encoding of the type ReplyKeyPack. 838 5. The signerInfos field of the inner type SignedData contains a 839 single signerInfo, which contains the signature over the type 840 ReplyKeyPack. 842 6. The certificates field of the inner type SignedData contains 843 certificates intended to facilitate certification path 844 construction, so that the client can verify the KDC's signature 845 over the type ReplyKeyPack. The information contained in the 846 trustedCertifiers in the request SHOULD be used by the KDC as 847 hints to guide its selection of an appropriate certificate chain 848 to return to the client. This field may only be left empty if 849 the KDC public key specified by the kdcPkId field in the PA-PK- 850 AS-REQ was used for signing. Otherwise, for path validation, 851 these certificates SHOULD be sufficient to construct at least one 852 certification path from the KDC certificate to one trust anchor 853 acceptable by the client [CAPATH]. The KDC MUST be capable of 854 including such a set of certificates if configured to do so. The 855 certificates field MUST NOT contain "root" CA certificates. 857 7. The recipientInfos field of the type EnvelopedData is a SET which 858 MUST contain exactly one member of type KeyTransRecipientInfo. 859 The encryptedKey of this member contains the temporary key which 860 is encrypted using the client's public key. 862 8. The unprotectedAttrs or originatorInfo fields of the type 863 EnvelopedData MAY be present. 865 Implementations of this RSA encryption key delivery method are 866 RECOMMENDED to support for RSA keys at least 2048 bits in size. 868 3.2.4. Receipt of KDC Reply 870 Upon receipt of the KDC's reply, the client proceeds as follows. If 871 the PA-PK-AS-REP contains the dhSignedData field, the client derives 872 the AS reply key using the same procedure used by the KDC as defined 873 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack 874 field, and the client decrypts and extracts the temporary key in the 875 encryptedKey field of the member KeyTransRecipientInfo, and then uses 876 that as the AS reply key. 878 If the public key encrytion method is used, the client MUST verify 879 the asChecksum contained in the ReplyKeyPack. 881 In either case, the client MUST verify the signature in the 882 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST 883 be validated according to [RFC3280]. In addition, unless the client 884 can otherwise verify that the public key used to verify the KDC's 885 signature is bound to the KDC of the target realm, the KDC's X.509 886 certificate MUST contain a Subject Alternative Name extension 887 [RFC3280] carrying an AnotherName whose type-id is id-pksan (as 888 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that 889 matches the name of the TGS of the target realm (as defined in 890 Section 7.3 of [RFC4120]). 892 Unless the client knows by some other means that the KDC certificate 893 is intended for a Kerberos KDC, the client MUST require that the KDC 894 certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: 896 id-pkkdcekuoid OBJECT IDENTIFIER ::= 897 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 898 pkinit(3) pkkdcekuoid(5) } 899 -- Signing KDC responses. 900 -- Key usage bits that MUST be consistent: 901 -- digitalSignature. 903 If the KDC certificate contains the Kerberos TGS name encoded as an 904 id-pksan SAN, this certificate is certified by the issuing CA as a 905 KDC certificate, therefore the id-pkkdcekuoid EKU is not required. 907 If all applicable checks are satisfied, the client then decrypts the 908 enc-part field of the KDC-REP in the AS-REP using the AS reply key, 909 and then proceeds as described in [RFC4120]. 911 Implementation note: CAs issuing KDC certificates SHOULD place all 912 "short" and "fully-qualified" Kerberos realm names of the KDC (one 913 per GeneralName [RFC3280]) into the KDC certificate to allow maximum 914 flexibility. 916 3.3. Interoperability Requirements 918 The client MUST be capable of sending a set of certificates 919 sufficient to allow the KDC to construct a certification path for the 920 client's certificate, if the correct set of certificates is provided 921 through configuration or policy. 923 If the client sends all the X.509 certificates on a certification 924 path to a trust anchor acceptable by the KDC, and the KDC can not 925 verify the client's public key otherwise, the KDC MUST be able to 926 process path validation for the client's certificate based on the 927 certificates in the request. 929 The KDC MUST be capable of sending a set of certificates sufficient 930 to allow the client to construct a certification path for the KDC's 931 certificate, if the correct set of certificates is provided through 932 configuration or policy. 934 If the KDC sends all the X.509 certificates on a certification path 935 to a trust anchor acceptable by the client, and the client can not 936 verify the KDC's public key otherwise, the client MUST be able to 937 process path validation for the KDC's certificate based on the 938 certificates in the reply. 940 3.4. KDC Indication of PKINIT Support 942 If pre-authentication is required, but was not present in the 943 request, per [RFC4120] an error message with the code 944 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 945 stored in the e-data field of the KRB-ERROR message to specify which 946 pre-authentication mechanisms are acceptable. The KDC can then 947 indicate the support of PKINIT by including an empty element whose 948 padata-type is PA_PK_AS_REQ in that METHOD-DATA object. 950 Otherwise if it is required by the KDC's local policy that the client 951 must be pre-authenticated using the pre-authentication mechanism 952 specified in this document, but no PKINIT pre-authentication was 953 present in the request, an error message with the code 954 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 956 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in 957 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 958 STRING), and clients MUST ignore this and any other value. Future 959 extensions to this protocol may specify other data to send instead of 960 an empty OCTET STRING. 962 4. Security Considerations 964 The symmetric reply key size and Diffie-Hellman field size or RSA 965 modulus size should be chosen so as to provide sufficient 966 cryptographic security [RFC3766]. 968 When MODP Diffie-Hellman is used, the exponents should have at least 969 twice as many bits as the symmetric keys that will be derived from 970 them [ODL99]. 972 PKINIT raises certain security considerations beyond those that can 973 be regulated strictly in protocol definitions. We will address them 974 in this section. 976 PKINIT extends the cross-realm model to the public-key 977 infrastructure. Users of PKINIT must understand security policies 978 and procedures appropriate to the use of Public Key Infrastructures 979 [RFC3280]. 981 In order to trust a KDC certificate that is certified by a CA as a 982 KDC certificate for a target realm (for example, by asserting the TGS 983 name of that Kerberos realm as an id-pksan SAN and/or restricting the 984 certificate usage by using the id-pkkdcekuoid EKU, as described in 985 Section 3.2.4), the client MUST verify that the KDC certificate's 986 issuing CA is authorized to issue KDC certificates for that target 987 realm. Otherwise, the binding between the KDC certificate and the 988 KDC of the target realm is not established. 990 How to validate this authorization is a matter of local policy. A 991 way to achieve this is the configuration of specific sets of 992 intermediary CAs and trust anchors, one of which must be on the KDC 993 certificate's certification path [RFC3280]; and for each CA or trust 994 anchor the realms for which it is allowed to issue certificates. 996 In addition, if any CA is trusted to issue KDC certificates can also 997 issue other kinds of certificates, then local policy must be able to 998 distinguish between them: for example, it could require that KDC 999 certificates contain the id-pkkdcekuoid EKU or that the realm be 1000 specified with the id-pksan SAN. 1002 It is the responsibility of the PKI administrators for an 1003 organization to ensure that KDC certificates are only issued to KDCs, 1004 and that clients can ascertain this using their local policy. 1006 Standard Kerberos allows the possibility of interactions between 1007 cryptosystems of varying strengths; this document adds interactions 1008 with public-key cryptosystems to Kerberos. Some administrative 1009 policies may allow the use of relatively weak public keys. Using 1010 such keys to wrap data encrypted under stronger conventional 1011 cryptosystems may be inappropriate. 1013 PKINIT requires keys for symmetric cryptosystems to be generated. 1014 Some such systems contain "weak" keys. For recommendations regarding 1015 these weak keys, see [RFC4120]. 1017 PKINIT allows the use of the same RSA key pair for encryption and 1018 signing when doing RSA encryption based key delivery. This is not 1019 recommended usage of RSA keys [RFC3447], by using DH based key 1020 delivery this is avoided. 1022 Care should be taken in how certificates are chosen for the purposes 1023 of authentication using PKINIT. Some local policies may require that 1024 key escrow be used for certain certificate types. Deployers of 1025 PKINIT should be aware of the implications of using certificates that 1026 have escrowed keys for the purposes of authentication. Because 1027 signing only certificates are normally not escrowed, by using DH 1028 based key delivery this is avoided. 1030 PKINIT does not provide for a "return routability" test to prevent 1031 attackers from mounting a denial-of-service attack on the KDC by 1032 causing it to perform unnecessary and expensive public-key 1033 operations. Strictly speaking, this is also true of standard 1034 Kerberos, although the potential cost is not as great, because 1035 standard Kerberos does not make use of public-key cryptography. By 1036 using DH based key delivery and reusing DH keys, the necessary crypto 1037 processing cost per request can be minimized. 1039 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 1040 permit empty SEQUENCEs to be encoded. Such empty sequences may only 1041 be used if the KDC itself vouches for the user's certificate. 1043 5. Acknowledgements 1045 The following people have made significant contributions to this 1046 draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist 1047 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, 1048 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik 1049 Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and 1050 Aaron D. Jaggard. 1052 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and 1053 Jonathan Trostle who wrote earlier versions of this document. 1055 The authors are indebted to the Kerberos working group chair Jeffrey 1056 Hutzelman who kept track of various issues and was enormously helpful 1057 during the creation of this document. 1059 Some of the ideas on which this document is based arose during 1060 discussions over several years between members of the SAAG, the IETF 1061 CAT working group, and the PSRG, regarding integration of Kerberos 1062 and SPX. Some ideas have also been drawn from the DASS system. 1063 These changes are by no means endorsed by these groups. This is an 1064 attempt to revive some of the goals of those groups, and this 1065 document approaches those goals primarily from the Kerberos 1066 perspective. 1068 Lastly, comments from groups working on similar ideas in DCE have 1069 been invaluable. 1071 6. IANA Considerations 1073 This document has no actions for IANA. 1075 7. References 1077 7.1. Normative References 1079 [IEEE1363] 1080 IEEE, "Standard Specifications for Public Key 1081 Cryptography", IEEE 1363, 2000. 1083 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1084 Requirement Levels", BCP 14, RFC 2119, March 1997. 1086 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1087 RFC 2412, November 1998. 1089 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1090 RFC 2631, June 1999. 1092 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1093 Identifiers for the Internet X.509 Public Key 1094 Infrastructure Certificate and Certificate Revocation List 1095 (CRL) Profile", RFC 3279, April 2002. 1097 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1098 X.509 Public Key Infrastructure Certificate and 1099 Certificate Revocation List (CRL) Profile", RFC 3280, 1100 April 2002. 1102 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1103 Algorithms", RFC 3370, August 2002. 1105 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1106 Standards (PKCS) #1: RSA Cryptography Specifications 1107 Version 2.1", RFC 3447, February 2003. 1109 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1110 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1111 RFC 3526, May 2003. 1113 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1114 Encryption Algorithm in Cryptographic Message Syntax 1115 (CMS)", RFC 3565, July 2003. 1117 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1118 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1119 RFC 3766, April 2004. 1121 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1122 RFC 3852, July 2004. 1124 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1125 Kerberos 5", RFC 3961, February 2005. 1127 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1128 Encryption for Kerberos 5", RFC 3962, February 2005. 1130 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1131 Kerberos Network Authentication Service (V5)", RFC 4120, 1132 July 2005. 1134 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1135 Version 5 Generic Security Service Application Program 1136 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1137 July 2005. 1139 [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication 1140 Framework. 1997. 1142 [X690] ASN.1 encoding rules: Specification of Basic Encoding 1143 Rules (BER), Canonical Encoding Rules (CER) and 1144 Distinguished Encoding Rules (DER), ITU-T Recommendation 1145 X.690 (1997) | ISO/IEC International Standard 1146 8825-1:1998. 1148 7.2. Informative References 1150 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- 1151 pkix-certpathbuild. Work in Progress. 1153 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1154 Sizes", Journal of Cryptology 14 (2001) 255-293. 1156 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 1157 future, Designs, Codes, and Cryptography (1999)". 1159 Appendix A. PKINIT ASN.1 Module 1161 KerberosV5-PK-INIT-SPEC { 1162 iso(1) identified-organization(3) dod(6) internet(1) 1163 security(5) kerberosV5(2) modules(4) pkinit(5) 1164 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1166 IMPORTS 1167 SubjectPublicKeyInfo, AlgorithmIdentifier 1168 FROM PKIX1Explicit88 { iso (1) 1169 identified-organization (3) dod (6) internet (1) 1170 security (5) mechanisms (5) pkix (7) id-mod (0) 1171 id-pkix1-explicit (18) } 1172 -- As defined in RFC 3280. 1174 KerberosTime, PrincipalName, Realm, EncryptionKey 1175 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1176 dod(6) internet(1) security(5) kerberosV5(2) 1177 modules(4) krb5spec2(2) } ; 1179 id-pkinit OBJECT IDENTIFIER ::= 1180 { iso (1) org (3) dod (6) internet (1) security (5) 1181 kerberosv5 (2) pkinit (3) } 1183 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1184 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1185 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1186 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1187 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1189 id-pksan OBJECT IDENTIFIER ::= 1190 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 1191 x509-sanan (2) } 1193 pa-pk-as-req INTEGER ::= 16 1194 pa-pk-as-rep INTEGER ::= 17 1196 ad-initial-verified-cas INTEGER ::= 9 1198 td-trusted-certifiers INTEGER ::= 104 1199 td-invalid-certificates INTEGER ::= 105 1200 td-dh-parameters INTEGER ::= 109 1202 PA-PK-AS-REQ ::= SEQUENCE { 1203 signedAuthPack [0] IMPLICIT OCTET STRING, 1204 -- Contains a CMS type ContentInfo encoded 1205 -- according to [RFC3852]. 1206 -- The contentType field of the type ContentInfo 1207 -- is id-signedData (1.2.840.113549.1.7.2), 1208 -- and the content field is a SignedData. 1209 -- The eContentType field for the type SignedData is 1210 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1211 -- eContent field contains the DER encoding of the 1212 -- type AuthPack. 1213 -- AuthPack is defined below. 1214 trustedCertifiers [1] SEQUENCE OF 1215 ExternalPrincipalIdentifier OPTIONAL, 1216 -- A list of CAs, trusted by the client, that can 1217 -- be used to certify the KDC. 1218 -- Each ExternalPrincipalIdentifier identifies a CA 1219 -- or a CA certificate (thereby its public key). 1220 -- The information contained in the 1221 -- trustedCertifiers SHOULD be used by the KDC as 1222 -- hints to guide its selection of an appropriate 1223 -- certificate chain to return to the client. 1224 kdcPkId [2] IMPLICIT OCTET STRING 1225 OPTIONAL, 1226 -- Contains a CMS type SignerIdentifier encoded 1227 -- according to [RFC3852]. 1228 -- Identifies, if present, a particular KDC 1229 -- public key that the client already has. 1230 ... 1231 } 1233 DHNonce ::= OCTET STRING 1235 ExternalPrincipalIdentifier ::= SEQUENCE { 1236 subjectName [0] IMPLICIT OCTET STRING OPTIONAL, 1237 -- Contains a PKIX type Name encoded according to 1238 -- [RFC3280]. 1239 -- Identifies the certificate subject by the 1240 -- distinguished subject name. 1241 -- REQUIRED when there is a distinguished subject 1242 -- name present in the certificate. 1243 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, 1244 -- Contains a CMS type IssuerAndSerialNumber encoded 1245 -- according to [RFC3852]. 1246 -- Identifies a certificate of the subject. 1247 -- REQUIRED for TD-INVALID-CERTIFICATES and 1248 -- TD-TRUSTED-CERTIFIERS. 1249 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, 1250 -- Identifies the subject's public key by a key 1251 -- identifier. When an X.509 certificate is 1252 -- referenced, this key identifier matches the X.509 1253 -- subjectKeyIdentifier extension value. When other 1254 -- certificate formats are referenced, the documents 1255 -- that specify the certificate format and their use 1256 -- with the CMS must include details on matching the 1257 -- key identifier to the appropriate certificate 1258 -- field. 1259 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. 1260 ... 1261 } 1262 AuthPack ::= SEQUENCE { 1263 pkAuthenticator [0] PKAuthenticator, 1264 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1265 -- Type SubjectPublicKeyInfo is defined in 1266 -- [RFC3280]. 1267 -- Specifies Diffie-Hellman domain parameters 1268 -- and the client's public key value [IEEE1363]. 1269 -- The DH public key value is encoded as a BIT 1270 -- STRING according to [RFC3279]. 1271 -- This field is present only if the client wishes 1272 -- to use the Diffie-Hellman key agreement method. 1273 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1274 OPTIONAL, 1275 -- Type AlgorithmIdentifier is defined in 1276 -- [RFC3280]. 1277 -- List of CMS encryption types supported by the 1278 -- client in order of (decreasing) preference. 1279 clientDHNonce [3] DHNonce OPTIONAL, 1280 -- Present only if the client indicates that it 1281 -- wishes to reuse DH keys or to allow the KDC to 1282 -- do so. 1283 ... 1284 } 1286 PKAuthenticator ::= SEQUENCE { 1287 cusec [0] INTEGER (0..999999), 1288 ctime [1] KerberosTime, 1289 -- cusec and ctime are used as in [RFC4120], for 1290 -- replay prevention. 1291 nonce [2] INTEGER (0..4294967295), 1292 -- Chosen randomly; This nonce does not need to 1293 -- match with the nonce in the KDC-REQ-BODY. 1294 paChecksum [3] OCTET STRING, 1295 -- Contains the SHA1 checksum, performed over 1296 -- KDC-REQ-BODY. 1297 ... 1298 } 1300 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF 1301 ExternalPrincipalIdentifier 1302 -- Identifies a list of CAs trusted by the KDC. 1303 -- Each ExternalPrincipalIdentifier identifies a CA 1304 -- or a CA certificate (thereby its public key). 1306 TD-INVALID-CERTIFICATES ::= SEQUENCE OF 1307 ExternalPrincipalIdentifier 1308 -- Each ExternalPrincipalIdentifier identifies a 1309 -- certificate (sent by the client) with an invalid 1310 -- signature. 1312 KRB5PrincipalName ::= SEQUENCE { 1313 realm [0] Realm, 1314 principalName [1] PrincipalName 1315 } 1317 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF 1318 ExternalPrincipalIdentifier 1319 -- Identifies the certification path based on which 1320 -- the client certificate was validated. 1321 -- Each ExternalPrincipalIdentifier identifies a CA 1322 -- or a CA certificate (thereby its public key). 1324 PA-PK-AS-REP ::= CHOICE { 1325 dhInfo [0] DHRepInfo, 1326 -- Selected when Diffie-Hellman key exchange is 1327 -- used. 1328 encKeyPack [1] IMPLICIT OCTET STRING, 1329 -- Selected when public key encryption is used. 1330 -- Contains a CMS type ContentInfo encoded 1331 -- according to [RFC3852]. 1332 -- The contentType field of the type ContentInfo is 1333 -- id-envelopedData (1.2.840.113549.1.7.3). 1334 -- The content field is an EnvelopedData. 1335 -- The contentType field for the type EnvelopedData 1336 -- is id-signedData (1.2.840.113549.1.7.2). 1337 -- The eContentType field for the inner type 1338 -- SignedData (when unencrypted) is id-pkrkeydata 1339 -- (1.2.840.113549.1.7.3) and the eContent field 1340 -- contains the DER encoding of the type 1341 -- ReplyKeyPack. 1342 -- ReplyKeyPack is defined below. 1343 ... 1344 } 1346 DHRepInfo ::= SEQUENCE { 1347 dhSignedData [0] IMPLICIT OCTET STRING, 1348 -- Contains a CMS type ContentInfo encoded according 1349 -- to [RFC3852]. 1350 -- The contentType field of the type ContentInfo is 1351 -- id-signedData (1.2.840.113549.1.7.2), and the 1352 -- content field is a SignedData. 1353 -- The eContentType field for the type SignedData is 1354 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1355 -- eContent field contains the DER encoding of the 1356 -- type KDCDHKeyInfo. 1357 -- KDCDHKeyInfo is defined below. 1359 serverDHNonce [1] DHNonce OPTIONAL 1360 -- Present if and only if dhKeyExpiration is 1361 -- present. 1362 } 1364 KDCDHKeyInfo ::= SEQUENCE { 1365 subjectPublicKey [0] BIT STRING, 1366 -- KDC's DH public key. 1367 -- The DH public key value is encoded as a BIT 1368 -- STRING according to [RFC3279]. 1369 nonce [1] INTEGER (0..4294967295), 1370 -- Contains the nonce in the PKAuthenticator of the 1371 -- request if DH keys are NOT reused, 1372 -- 0 otherwise. 1373 dhKeyExpiration [2] KerberosTime OPTIONAL, 1374 -- Expiration time for KDC's key pair, 1375 -- present if and only if DH keys are reused. If 1376 -- this field is omitted then the serverDHNonce 1377 -- field MUST also be omitted. 1378 ... 1379 } 1381 ReplyKeyPack ::= SEQUENCE { 1382 replyKey [0] EncryptionKey, 1383 -- Contains the session key used to encrypt the 1384 -- enc-part field in the AS-REP. 1385 asChecksum [1] Checksum, 1386 -- Contains the checksum of the AS-REQ 1387 -- corresponding to the containing AS-REP. 1388 -- The checksum is performed over the type AS-REQ. 1389 -- The protocol key [RFC3961] of the checksum is the 1390 -- replyKey and the key usage number is 6. 1391 -- If the replyKey's enctype is "newer" [RFC4120] 1392 -- [RFC4121], the checksum is the required 1393 -- checksum operation [RFC3961] for that enctype. 1394 -- The client MUST verify this checksum upon receipt 1395 -- of the AS-REP. 1396 ... 1397 } 1399 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier 1400 -- Each AlgorithmIdentifier specifies a set of 1401 -- Diffie-Hellman domain parameters [IEEE1363]. 1402 -- This list is in decreasing preference order. 1403 END 1405 Appendix B. Test Vectors 1407 Function octetstring2key() is defined in Section 3.2.3.1. This 1408 section describes a few sets of test vectors that would be useful for 1409 implementers of octetstring2key(). 1411 Set 1 1412 ===== 1413 Input octet string x is: 1415 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1416 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1417 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1418 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1421 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1422 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1423 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1424 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1425 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1426 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1427 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1428 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1429 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1432 Output of K-truncate() when the key size is 32 octets: 1434 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 1435 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 1437 Set 2: 1438 ===== 1439 Input octet string x is: 1441 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1442 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1443 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1444 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1445 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1446 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1447 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1448 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1450 Output of K-truncate() when the key size is 32 octets: 1452 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb 1453 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e 1455 Set 3: 1456 ====== 1457 Input octet string x is: 1459 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1460 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1461 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1462 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1463 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 1464 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 1465 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 1466 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1468 Output of K-truncate() when the key size is 32 octets: 1470 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 1471 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e 1473 Set 4: 1474 ===== 1475 Input octet string x is: 1477 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 1478 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 1479 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 1480 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 1481 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 1483 Output of K-truncate() when the key size is 32 octets: 1485 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a 1486 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc 1488 Authors' Addresses 1490 Brian Tung 1491 USC Information Sciences Institute 1492 4676 Admiralty Way Suite 1001, Marina del Rey CA 1493 Marina del Rey, CA 90292 1494 US 1496 Email: brian@isi.edu 1498 Larry Zhu 1499 Microsoft Corporation 1500 One Microsoft Way 1501 Redmond, WA 98052 1502 US 1504 Email: lzhu@microsoft.com 1506 Intellectual Property Statement 1508 The IETF takes no position regarding the validity or scope of any 1509 Intellectual Property Rights or other rights that might be claimed to 1510 pertain to the implementation or use of the technology described in 1511 this document or the extent to which any license under such rights 1512 might or might not be available; nor does it represent that it has 1513 made any independent effort to identify any such rights. Information 1514 on the procedures with respect to rights in RFC documents can be 1515 found in BCP 78 and BCP 79. 1517 Copies of IPR disclosures made to the IETF Secretariat and any 1518 assurances of licenses to be made available, or the result of an 1519 attempt made to obtain a general license or permission for the use of 1520 such proprietary rights by implementers or users of this 1521 specification can be obtained from the IETF on-line IPR repository at 1522 http://www.ietf.org/ipr. 1524 The IETF invites any interested party to bring to its attention any 1525 copyrights, patents or patent applications, or other proprietary 1526 rights that may cover technology that may be required to implement 1527 this standard. Please address the information to the IETF at 1528 ietf-ipr@ietf.org. 1530 Disclaimer of Validity 1532 This document and the information contained herein are provided on an 1533 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1534 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1535 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1536 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1537 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1538 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1540 Copyright Statement 1542 Copyright (C) The Internet Society (2005). This document is subject 1543 to the rights, licenses and restrictions contained in BCP 78, and 1544 except as set forth therein, the authors retain all their rights. 1546 Acknowledgment 1548 Funding for the RFC Editor function is currently provided by the 1549 Internet Society.