idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-23.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1199. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2005) is 7025 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 1162 -- Looks like a reference, but probably isn't: '1' on line 1165 -- Looks like a reference, but probably isn't: '2' on line 1153 -- Looks like a reference, but probably isn't: '3' on line 1080 ** 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' Summary: 9 errors (**), 0 flaws (~~), 2 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: August 4, 2005 L. Zhu 5 Microsoft Corporation 6 January 31, 2005 8 Public Key Cryptography for Initial Authentication in Kerberos 9 draft-ietf-cat-kerberos-pk-init-23 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 4, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes protocol extensions (hereafter called PKINIT) 45 to the Kerberos protocol specification. These extensions provide a 46 method for integrating public key cryptography into the initial 47 authentication exchange, by passing digital certificates and 48 associated authenticators in pre-authentication data fields. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 54 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 56 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 57 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 58 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 59 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6 60 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7 61 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9 62 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12 63 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17 64 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 70 7.2 Informative References . . . . . . . . . . . . . . . . . . 21 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 72 A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21 73 Intellectual Property and Copyright Statements . . . . . . . . 27 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. (In this document, we will 84 refer to both the AS and the TGS as the KDC.) Finally, the client 85 uses the service ticket to authenticate itself to the service. 87 The advantage afforded by the TGT is that the client exposes his 88 long-term secrets only once. The TGT and its associated session key 89 can then be used for any subsequent service ticket requests. One 90 result of this is that all further authentication is independent of 91 the method by which the initial authentication was performed. 92 Consequently, initial authentication provides a convenient place to 93 integrate public-key cryptography into Kerberos authentication. 95 As defined in [CLAR], Kerberos authentication exchanges use 96 symmetric-key cryptography, in part for performance. One 97 disadvantage of using symmetric-key cryptography is that the keys 98 must be shared, so that before a client can authenticate itself, he 99 must already be registered with the KDC. 101 Conversely, public-key cryptography (in conjunction with an 102 established Public Key Infrastructure) permits authentication without 103 prior registration with a KDC. Adding it to Kerberos allows the 104 widespread use of Kerberized applications by clients without 105 requiring them to register first with a KDC--a requirement that has 106 no inherent security benefit. 108 As noted above, a convenient and efficient place to introduce 109 public-key cryptography into Kerberos is in the initial 110 authentication exchange. This document describes the methods and 111 data formats for integrating public-key cryptography into Kerberos 112 initial authentication. 114 2. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Extensions 122 This section describes extensions to [CLAR] for supporting the use of 123 public-key cryptography in the initial request for a ticket. 125 Briefly, this document defines the following extensions to [CLAR]: 127 1. The client indicates the use of public-key authentication by 128 including a special preauthenticator in the initial request. This 129 preauthenticator contains the client's public-key data and a 130 signature. 132 2. The KDC tests the client's request against its authentication 133 policy and trusted Certification Authorities (CAs). 135 3. If the request passes the verification tests, the KDC replies as 136 usual, but the reply is encrypted using either: 138 a. a key generated through a Diffie-Hellman (DH) key exchange 139 [RFC2631] with the client, signed using the KDC's signature 140 key; or 142 b. a symmetric encryption key, signed using the KDC's signature 143 key and encrypted using the client's public key. 145 Any keying material required by the client to obtain the 146 encryption key for decrypting the KDC reply is returned in a 147 pre-authentication field accompanying the usual reply. 149 4. The client obtains the encryption key, decrypts the reply, and 150 then proceeds as usual. 152 Section 3.1 of this document enumerates the required algorithms and 153 necessary extension message types. Section 3.2 describes the 154 extension messages in greater detail. 156 3.1 Definitions, Requirements, and Constants 158 3.1.1 Required Algorithms 160 All PKINIT implementations MUST support the following algorithms: 162 o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. 164 o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. 166 o KDC AS reply key delivery method: ephemeral-ephemeral 167 Diffie-Hellman exchange (Diffie-Hellman keys are not cached). 169 3.1.2 Defined Message and Encryption Types 171 PKINIT makes use of the following new pre-authentication types: 173 PA-PK-AS-REQ 16 174 PA-PK-AS-REP 17 176 PKINIT also makes use of the following new authorization data type: 178 AD-INITIAL-VERIFIED-CAS 9 180 PKINIT introduces the following new error codes: 182 KDC_ERR_CLIENT_NOT_TRUSTED 62 183 KDC_ERR_KDC_NOT_TRUSTED 63 184 KDC_ERR_INVALID_SIG 64 185 KDC_ERR_KEY_SIZE 65 186 KDC_ERR_CERTIFICATE_MISMATCH 66 187 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 188 KDC_ERR_INVALID_CERTIFICATE 71 189 KDC_ERR_REVOKED_CERTIFICATE 72 190 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 191 KDC_ERR_CLIENT_NAME_MISMATCH 75 193 PKINIT uses the following typed data types for errors: 195 TD-TRUSTED-CERTIFIERS 104 196 TD-CERTIFICATE-INDEX 105 197 TD-DH-PARAMETERS 109 199 PKINIT defines the following encryption types, for use in the AS-REQ 200 message (to indicate acceptance of the corresponding encryption 201 Object Identifiers (OIDs) in PKINIT): 203 dsaWithSHA1-CmsOID 9 204 md5WithRSAEncryption-CmsOID 10 205 sha1WithRSAEncryption-CmsOID 11 206 rc2CBC-EnvOID 12 207 rsaEncryption-EnvOID (PKCS1 v1.5) 13 208 rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 209 des-ede3-cbc-EnvOID 15 211 The above encryption types are used by the client only within the 212 KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS) 213 [RFC3852] algorithms it supports. Their use within Kerberos 214 EncryptedData structures is not specified by this document. 216 The ASN.1 module for all structures defined in this document (plus 217 IMPORT statements for all imported structures) are 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]. All data 222 structures wrapped in OCTET STRINGs must be encoded according to the 223 rules specified in corresponding specifications. 225 Interoperability note: Some implementations may not be able to decode 226 CMS objects encoded with BER but not DER; specifically, they may not 227 be able to decode infinite length encodings. To maximize 228 interoperability, implementers SHOULD encode CMS objects used in 229 PKINIT with DER. 231 3.1.3 Algorithm Identifiers 233 PKINIT does not define, but does make use of, the following algorithm 234 identifiers. 236 PKINIT uses the following algorithm identifier for Diffie-Hellman key 237 agreement [RFC3279]: 239 dhpublicnumber 241 PKINIT uses the following signature algorithm identifiers [RFC3279]: 243 sha-1WithRSAEncryption (RSA with SHA1) 244 md5WithRSAEncryption (RSA with MD5) 245 id-dsa-with-sha1 (DSA with SHA1) 247 PKINIT uses the following encryption algorithm identifiers [RFC3447] 248 for encrypting the temporary key with a public key: 250 rsaEncryption (PKCS1 v1.5) 251 id-RSAES-OAEP (PKCS1 v2.0) 253 PKINIT uses the following algorithm identifiers [RFC3370][RFC3565] 254 for encrypting the reply key with the temporary key: 256 des-ede3-cbc (three-key 3DES, CBC mode) 257 rc2-cbc (RC2, CBC mode) 258 id-aes256-CBC (AES-256, CBC mode) 260 3.2 PKINIT Pre-authentication Syntax and Use 262 This section defines the syntax and use of the various 263 pre-authentication fields employed by PKINIT. 265 3.2.1 Generation of Client Request 267 The initial authentication request (AS-REQ) is sent as per [CLAR]; in 268 addition, a pre-authentication field contains data signed by the 269 client's private signature key, as follows: 271 PA-PK-AS-REQ ::= SEQUENCE { 272 signedAuthPack [0] IMPLICIT OCTET STRING, 273 -- Contains a CMS type ContentInfo encoded 274 -- according to [RFC3852]. 275 -- The contentType field of the type ContentInfo 276 -- is id-signedData (1.2.840.113549.1.7.2), 277 -- and the content field is a SignedData. 278 -- The eContentType field for the type SignedData is 279 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 280 -- eContent field contains the DER encoding of the 281 -- type AuthPack. 282 -- AuthPack is defined below. 283 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 284 -- A list of CAs, trusted by the client, that can 285 -- be used to validate KDC certificates. 286 kdcCert [2] IMPLICIT OCTET STRING 287 OPTIONAL, 288 -- Contains a CMS type IssuerAndSerialNumber encoded 289 -- according to [RFC3852]. 290 -- Identifies a particular KDC certificate, if the 291 -- client already has it. 292 ... 293 } 295 DHNonce ::= OCTET STRING 297 TrustedCA ::= CHOICE { 298 caName [1] IMPLICIT OCTET STRING, 299 -- Contains a PKIX type Name encoded according to 300 -- [RFC3280]. 301 issuerAndSerial [2] IMPLICIT OCTET STRING, 302 -- Contains a CMS type IssuerAndSerialNumber encoded 303 -- according to [RFC3852]. 304 -- Identifies a specific CA certificate. 305 ... 306 } 308 AuthPack ::= SEQUENCE { 309 pkAuthenticator [0] PKAuthenticator, 310 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 311 -- Defined in [RFC3280]. 312 -- Present only if the client wishes to use the 313 -- Diffie-Hellman key agreement method. 314 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 315 OPTIONAL, 316 -- List of CMS encryption types supported by 317 -- client in order of (decreasing) preference. 318 clientDHNonce [3] DHNonce OPTIONAL, 319 -- Present only if the client indicates that it 320 -- wishes to cache DH keys or to allow the KDC to 321 -- do so. 322 ... 323 } 325 PKAuthenticator ::= SEQUENCE { 326 cusec [0] INTEGER (0..999999), 327 ctime [1] KerberosTime, 328 -- cusec and ctime are used as in [CLAR], for replay 329 -- prevention. 330 nonce [2] INTEGER (0..4294967295), 331 -- Chosen randomly; This nonce does not need to 332 -- match with the nonce in the KDC-REQ-BODY. 333 paChecksum [3] OCTET STRING, 334 -- Contains the SHA1 checksum, performed over 335 -- KDC-REQ-BODY. 336 ... 337 } 339 The ContentInfo [RFC3852] structure for the signedAuthPack field is 340 filled out as follows: 342 1. The contentType field of the type ContentInfo is id-signedData 343 (as defined in [RFC3852]), and the content field is a SignedData 344 (as defined in [RFC3852]). 346 2. The eContentType field for the type SignedData is id-pkauthdata: 347 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 348 pkinit(3) pkauthdata(1) }. 350 3. The eContent field for the type SignedData contains the DER 351 encoding of the type AuthPack. 353 4. The signerInfos field of the type SignedData contains a single 354 signerInfo, which contains the signature over the type AuthPack. 356 5. The certificates field of the type SignedData contains the 357 client's certificate and additional certificates intended to 358 facilitate certification path construction, so that the KDC can 359 validate the client's certificate and verify the signature over 360 the type AuthPack. The certificates field MUST NOT contain 361 "root" CA certificates. 363 6. The client's Diffie-Hellman public value (clientPublicValue) is 364 included if and only if the client wishes to use the 365 Diffie-Hellman key agreement method. For the Diffie-Hellman key 366 agreement method, implementations MUST support Oakley 1024-bit 367 MODP well-known group 2 [RFC2412] and SHOULD support Oakley 368 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP 369 well-known group 16 [RFC3526]. They MAY support Oakley 185-bit 370 EC2N group 4 [RFC2412]. The Diffie-Hellman group size should be 371 chosen so as to provide sufficient cryptographic security. The 372 exponents should have at least twice as many bits as the 373 symmetric keys that will be derived from them [ODL99]. 375 7. The client may wish to cache DH keys or to allow the KDC to do 376 so. If so, then the client includes the clientDHNonce field. 377 This nonce string needs to be as long as the longest key length 378 of the symmetric key types that the client supports. This nonce 379 MUST be chosen randomly. 381 3.2.2 Receipt of Client Request 383 Upon receiving the client's request, the KDC validates it. This 384 section describes the steps that the KDC MUST (unless otherwise 385 noted) take in validating the request. 387 The KDC looks for the client's certificate in the signedAuthPack 388 (based on the signerInfo) and validate this certificate. 390 If the KDC cannot find a certification path to validate the client's 391 certificate, it sends back an error of type 392 KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this 393 error is a TYPED-DATA (as defined in [CLAR]). For this error, the 394 data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER 395 encoding of 397 TrustedCertifiers ::= SEQUENCE OF OCTET STRING 398 -- The OCTET STRING contains a PKIX type Name encoded 399 -- according to [RFC3280]. 401 If, while processing the certification path, the KDC determines that 402 the signature on one of the certificates in the signedAuthPack is 403 invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. 404 The accompanying e-data for this error is a TYPED-DATA, whose 405 data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER 406 encoding of the index into the CertificateSet field, ordered as sent 407 by the client: 409 CertificateIndex ::= OCTET STRING 410 -- Contains a CMS type IssuerAndSerialNumber encoded 411 -- according to [RFC3852]. 412 -- IssuerAndSerialNumber of certificate with an 413 -- invalid signature. 415 If more than one certificate signature is invalid, the KDC MAY send 416 one TYPED-DATA per invalid signature. 418 The KDC SHOULD also check whether any certificates in the client's 419 certification path have been revoked. If any of them have been 420 revoked, the KDC MUST return an error of type 421 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the 422 revocation status but is unable to do so, it SHOULD return an error 423 of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or 424 certificates affected are identified exactly as for an error of type 425 KDC_ERR_INVALID_CERTIFICATE (see above). 427 In addition to validating the client's certificate, the KDC MUST also 428 check that this certificate properly maps to the client's principal 429 name as specified in the AS-REQ as follows: 431 1. If the KDC has its own mapping from the name in the client's 432 certificate to a Kerberos name, it uses that Kerberos name. 434 2. Otherwise, if the client's certificate contains a SubjectAltName 435 extension with a Kerberos name in the otherName field, it uses 436 that name. 438 The otherName field (of type AnotherName) in the SubjectAltName 439 extension MUST contain KRB5PrincipalName as defined below. 441 The type-id field of the type AnotherName is id-pksan: 443 id-pksan OBJECT IDENTIFIER ::= 444 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 445 x509-sanan (2) } 447 The value field of the type AnotherName is the DER encoding of the 448 following ASN.1 type: 450 KRB5PrincipalName ::= SEQUENCE { 451 realm [0] Realm, 452 principalName [1] PrincipalName 453 } 455 If the KDC does not have its own mapping and there is no Kerberos 456 name present in the client's certificate, or if the name in the 457 request does not match the name in the certificate (including the 458 realm name), the KDC MUST return error code 459 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for 460 this error. 462 Even if the client's certificate is validated and it is mapped to the 463 client's principal name, the KDC may decide not to accept the 464 client's certificate, depending on local policy. 466 The KDC MAY require the presence of an Extended Key Usage (EKU) 467 KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the 468 client's certificate: 470 id-pkekuoid OBJECT IDENTIFIER ::= 471 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 472 pkinit(3) pkekuoid(4) } 473 -- PKINIT client authentication. 474 -- Key usage bits that may be consistent: digitalSignature 475 -- nonRepudiation, and (keyEncipherment or keyAgreement). 477 As a matter of local policy, the KDC may decide to reject requests on 478 the basis of the absence or presence of specific EKU OIDs. KDCs 479 implementing this requirement SHOULD also accept the EKU KeyPurposeId 480 id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, 481 as there are a large number of client certificates deployed for use 482 with PKINIT which have this EKU. 484 The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the 485 client's certificate is not accepted. 487 Once the client's certificate is accepted, the KDC can then verify 488 the client's signature over the type AuthPack according to [RFC3852]. 489 If the signature fails to verify, the KDC MUST return error 490 KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error. 492 The KDC MUST check the timestamp to ensure that the request is not a 493 replay, and that the time skew falls within acceptable limits. The 494 recommendations clock skew times in [CLAR] apply here. If the check 495 fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or 496 KRB_AP_ERR_SKEW, respectively. 498 If the clientPublicValue is filled in, indicating that the client 499 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD 500 check to see if the key parameters satisfy its policy. If they do 501 not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying 502 e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and 503 whose data-value is the DER encoding of the following: 505 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters 506 -- Type DomainParameters is defined in [RFC3279]. 507 -- Contains a list of Diffie-Hellman group 508 -- parameters in decreasing preference order. 510 TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters 511 that the KDC supports in decreasing preference order, from which the 512 client should pick one to retry the request. 514 The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 515 client included a kdcCert field in the PA-PK-AS-REQ and the KDC does 516 not have the corresponding certificate. 518 The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client 519 did not include a kdcCert field, but did include a trustedCertifiers 520 field, and the KDC does not possesses a certificate issued by one of 521 the listed certifiers. 523 If there is a supportedCMSTypes field in the AuthPack, the KDC must 524 check to see if it supports any of the listed types. If it supports 525 more than one of the types, the KDC SHOULD use the one listed first. 526 If it does not support any of them, it MUST return an error of type 527 KRB5KDC_ERR_ETYPE_NOSUPP. 529 3.2.3 Generation of KDC Reply 531 Assuming that the client's request has been properly validated, the 532 KDC proceeds as per [CLAR], except as follows. 534 The KDC MUST set the initial flag and include an authorization data 535 of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is 536 an OCTET STRING containing the DER encoding of InitialVerifiedCAs: 538 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 539 ca [0] IMPLICIT OCTET STRING, 540 -- Contains a PKIX type Name encoded according to 541 -- [RFC3280]. 542 validated [1] BOOLEAN, 543 ... 544 } 546 The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 547 containers if the list of CAs satisfies the KDC's realm's policy 548 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag 549 [CLAR]). Furthermore, any TGS must copy such authorization data from 550 tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 551 including the AD-IF-RELEVANT container, if present. 553 Application servers that understand this authorization data type 554 SHOULD apply local policy to determine whether a given ticket bearing 555 such a type *not* contained within an AD-IF-RELEVANT container is 556 acceptable. (This corresponds to the AP server checking the 557 transited field when the TRANSITED-POLICY-CHECKED flag has not been 558 set [CLAR].) If such a data type is contained within an 559 AD-IF-RELEVANT container, AP servers MAY apply local policy to 560 determine whether the authorization data is acceptable. 562 The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the 563 reply as usual, but not with the client's long-term key. Instead, it 564 encrypts it with either a shared key derived from a Diffie-Hellman 565 exchange, or a generated encryption key. The contents of the 566 PA-PK-AS-REP indicate which key delivery method is used: 568 PA-PK-AS-REP ::= CHOICE { 569 dhInfo [0] DHRepInfo, 570 encKeyPack [1] IMPLICIT OCTET STRING, 571 -- Contains a CMS type ContentInfo encoded 572 -- according to [RFC3852]. 573 -- The contentType field of the type ContentInfo is 574 -- id-envelopedData (1.2.840.113549.1.7.3). 575 -- The content field is an EnvelopedData. 576 -- The contentType field for the type EnvelopedData 577 -- is id-signedData (1.2.840.113549.1.7.2). 578 -- The eContentType field for the inner type 579 -- SignedData (when unencrypted) is id-pkrkeydata 580 -- (1.2.840.113549.1.7.3) and the eContent field 581 -- contains the DER encoding of the type 582 -- ReplyKeyPack. 583 -- ReplyKeyPack is defined below. 584 ... 585 } 587 DHRepInfo ::= SEQUENCE { 588 dhSignedData [0] IMPLICIT OCTET STRING, 589 -- Contains a CMS type ContentInfo encoded according 590 -- to [RFC3852]. 591 -- The contentType field of the type ContentInfo is 592 -- id-signedData (1.2.840.113549.1.7.2), and the 593 -- content field is a SignedData. 594 -- The eContentType field for the type SignedData is 595 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 596 -- eContent field contains the DER encoding of the 597 -- type KDCDHKeyInfo. 598 -- KDCDHKeyInfo is defined below. 599 serverDHNonce [1] DHNonce OPTIONAL 600 -- Present if and only if dhKeyExpiration is 601 -- present. 602 } 604 KDCDHKeyInfo ::= SEQUENCE { 605 subjectPublicKey [0] BIT STRING, 606 -- KDC's public key, y = g^x mod p. 607 -- MUST be ASN.1 encoded as an INTEGER; 608 -- This encoding is then used as the contents 609 -- (i.e., the value) of this BIT STRING field. 610 nonce [1] INTEGER (0..4294967295), 611 -- Contains the nonce in the PKAuthenticator of the 612 -- request if cached DH keys are NOT used, 613 -- 0 otherwise. 614 dhKeyExpiration [2] KerberosTime OPTIONAL, 615 -- Expiration time for KDC's cached values, present 616 -- if and only if cached DH keys are used. If this 617 -- field is omitted then the serverDHNonce field 618 -- MUST also be omitted. 619 ... 620 } 622 3.2.3.1 Using Diffie-Hellman Key Exchange 624 In this case, the PA-PK-AS-REP contains a DHRepInfo structure. 626 The ContentInfo [RFC3852] structure for the dhSignedData field is 627 filled in as follows: 629 1. The contentType field of the type ContentInfo is id-signedData 630 (as defined in [RFC3852]), and the content field is a SignedData 631 (as defined in [RFC3852]). 633 2. The eContentType field for the type SignedData is the OID value 634 for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) 635 security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. 637 3. The eContent field for the type SignedData contains the DER 638 encoding of the type KDCDHKeyInfo. 640 4. The signerInfos field of the type SignedData contains a single 641 signerInfo, which contains the signature over the type 642 KDCDHKeyInfo. 644 5. The certificates field of the type SignedData contains the KDC's 645 certificate and additional certificates intended to facilitate 646 certification path construction, so that the client can validate 647 the KDC's certificate and verify the KDC's signature over the 648 type KDCDHKeyInfo. This field may only be left empty if the 649 client did include a kdcCert field in the PA-PK-AS-REQ, 650 indicating that the client already has the KDC's certificate. 651 The certificates field MUST NOT contain "root" CA certificates. 653 6. If the client included the clientDHNonce field, then the KDC may 654 choose to reuse its DH keys. If the server reuses DH keys then 655 it MUST include an expiration time in the dhKeyExperiation field. 656 Past the point of the expiration time, the signature over the 657 type DHRepInfo is considered expired/invalid. When the server 658 reuses DH keys then it MUST include a serverDHNonce at least as 659 long as the length of keys for the symmetric encryption system 660 used to encrypt the AS reply. Note that including the 661 serverDHNonce changes how the client and server calculate the key 662 to use to encrypt the reply; see below for details. The KDC 663 SHOULD NOT reuse DH keys unless the clientDHNonce field is 664 present in the request. 666 The reply key for use to decrypt the KDC reply [CLAR] is derived as 667 follows: 669 1. Both the KDC and the client calculate the shared secret value 670 DHKey: 672 DHKey = g^(xb * xa) mod p 674 where xb and xa are the KDC's and client's private exponents, 675 respectively. DHKey, padded first with leading zeros as needed to 676 make it as long as the modulus p, is represented as a string of 677 octets in big-endian order (such that the size of DHKey in octets 678 is the size of the modulus p). 680 2. Let K be the key-generation seed length [KCRYPTO] of the reply 681 key whose enctype is selected according to [CLAR]. 683 3. Define the function octetstring2key() as follows: 685 octetstring2key(x) == random-to-key(K-truncate( 686 SHA1(0x00 | x) | 687 SHA1(0x01 | x) | 688 SHA1(0x02 | x) | 689 ... 690 )) 692 where x is an octet string; | is the concatenation operator; 0x00, 693 0x01, 0x02, etc., are each represented as a single octet; 694 random-to-key() is an operation that generates a protocol key from 695 a bitstring of length K; and K-truncate truncates its input to the 696 first K bits. Both K and random-to-key() are defined in the 697 kcrypto profile [KCRYPTO] for the enctype of the reply key. 699 4. When cached DH keys are used, let n_c be the clientDHNonce, and 700 n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty 701 octet strings. 703 5. The reply key k is: 705 k = octetstring2key(DHKey | n_c | n_k) 707 3.2.3.2 Using Public Key Encryption 709 In this case, the PA-PK-AS-REP contains a ContentInfo structure 710 wrapped in an OCTET STRING. The reply key for use to decrypt the KDC 711 reply [CLAR] is encrypted in the encKeyPack field, which contains 712 data of type ReplyKeyPack: 714 ReplyKeyPack ::= SEQUENCE { 715 replyKey [0] EncryptionKey, 716 -- Contains the session key used to encrypt the 717 -- enc-part field in the AS-REP. 718 nonce [1] INTEGER (0..4294967295), 719 -- Contains the nonce in the PKAuthenticator of the 720 -- request. 721 ... 722 } 724 The ContentInfo [RFC3852] structure for the encKeyPack field is 725 filled in as follows: 727 1. The contentType field of the type ContentInfo is id-envelopedData 728 (as defined in [RFC3852]), and the content field is an 729 EnvelopedData (as defined in [RFC3852]). 731 2. The contentType field for the type EnvelopedData is 732 id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) 733 pkcs (1) pkcs7 (7) signedData (2) }. 735 3. The eContentType field for the inner type SignedData (when 736 decrypted from the encryptedContent field for the type 737 EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) 738 internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. 740 4. The eContent field for the inner type SignedData contains the DER 741 encoding of the type ReplyKeyPack. 743 5. The signerInfos field of the inner type SignedData contains a 744 single signerInfo, which contains the signature over the type 745 ReplyKeyPack. 747 6. The certificates field of the inner type SignedData contains the 748 KDC's certificate and additional certificates intended to 749 facilitate certification path construction, so that the client 750 can validate the KDC's certificate and verify the KDC's signature 751 over the type ReplyKeyPack. This field may only be left empty if 752 the client included a kdcCert field in the PA-PK-AS-REQ, 753 indicating that the client already has the KDC's certificate. 754 The certificates field MUST NOT contain "root" CA certificates. 756 7. The recipientInfos field of the type EnvelopedData is a SET which 757 MUST contain exactly one member of type KeyTransRecipientInfo. 758 The encryptedKey of this member contains the temporary key which 759 is encrypted using the client's public key. 761 8. The unprotectedAttrs or originatorInfo fields of the type 762 EnvelopedData MAY be present. 764 3.2.4 Receipt of KDC Reply 766 Upon receipt of the KDC's reply, the client proceeds as follows. If 767 the PA-PK-AS-REP contains the dhSignedData field, the client derives 768 the shared key using the same procedure used by the KDC as defined in 769 Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and 770 the client decrypts and verifies the temporary encryption key. 772 In either case, the client MUST validate the KDC's certificate and 773 verify the signature in the SignedData according to [RFC3852]. 774 Unless the client can otherwise prove that the KDC's certificate is 775 for the target KDC (i.e., the subject distinguished name in the KDC 776 certificate is bound to the hostname or IP address of the KDC 777 authenticating the client), it MUST do the following to verify the 778 responder's identity: 780 1. The client checks to see if the included certificate contains a 781 Subject Alternative Name extension [RFC3280] carrying a dNSName or 782 an iPAddress (if the KDC is specified by an IP address instead of 783 a name). If it does, it MUST check to see if that name value 784 matches that of the KDC it believes it is communicating with, with 785 matching rules specified in [RFC3280]. 787 2. The client verifies that the KDC's certificate MUST contain the 788 EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: 790 id-pkkdcekuoid OBJECT IDENTIFIER ::= 791 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) 792 pkinit(3) pkkdcekuoid(5) } 793 -- Signing KDC responses. 794 -- Key usage bits that may be consistent: 795 -- digitalSignature. 797 If all applicable checks are satisfied, the client then decrypts the 798 enc-part of the KDC-REP in the AS_REP with the resulting key, and 799 then proceeds as described in [CLAR]. 801 3.3 KDC Indication of PKINIT Support 803 If pre-authentication is required, but was not present in the 804 request, per [CLAR] an error message with the code 805 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be 806 stored in the e-data field of the KRB-ERROR message to specify which 807 pre-authentication mechanisms are acceptable. The KDC can then 808 indicate the support of PKINIT by including a PA-PK-AS-REQ element in 809 that METHOD-DATA object. 811 Otherwise if it is required by the KDC's local policy that the client 812 must be pre-authenticated using the pre-authentication mechanism 813 specified in this document, but no PKINIT pre-authentication was 814 present in the request, an error message with the code 815 KDC_ERR_PREAUTH_FAILED SHOULD be returned. 817 KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the 818 KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET 819 STRING), and clients MUST ignore this and any other value. Future 820 extensions to this protocol may specify other data to send instead of 821 an empty OCTET STRING. 823 4. Security Considerations 825 PKINIT raises certain security considerations beyond those that can 826 be regulated strictly in protocol definitions. We will address them 827 in this section. 829 PKINIT extends the cross-realm model to the public-key 830 infrastructure. Users of PKINIT must understand security policies 831 and procedures appropriate to the use of Public Key Infrastructures. 833 Standard Kerberos allows the possibility of interactions between 834 cryptosystems of varying strengths; this document adds interactions 835 with public-key cryptosystems to Kerberos. Some administrative 836 policies may allow the use of relatively weak public keys. Using 837 such keys to wrap data encrypted under stronger conventional 838 cryptosystems may be inappropriate. 840 PKINIT requires keys for symmetric cryptosystems to be generated. 841 Some such systems contain "weak" keys. For recommendations regarding 842 these weak keys, see [CLAR]. 844 PKINIT uses the same RSA key pair for encryption and signing when 845 doing RSA encryption based key delivery. This is not recommended 846 usage of RSA keys [RFC3447], by using DH based key delivery this is 847 avoided. 849 Care should be taken in how certificates are chosen for the purposes 850 of authentication using PKINIT. Some local policies may require that 851 key escrow be used for certain certificate types. Deployers of 852 PKINIT should be aware of the implications of using certificates that 853 have escrowed keys for the purposes of authentication. 855 PKINIT does not provide for a "return routability" test to prevent 856 attackers from mounting a denial-of-service attack on the KDC by 857 causing it to perform unnecessary and expensive public-key 858 operations. Strictly speaking, this is also true of standard 859 Kerberos, although the potential cost is not as great, because 860 standard Kerberos does not make use of public-key cryptography. 862 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does 863 permit empty SEQUENCEs to be encoded. Such empty sequences may only 864 be used if the KDC itself vouches for the user's certificate. 866 5. Acknowledgements 868 The following people have made significant contributions to this 869 draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love 870 Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan 871 Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and 872 Karthik Jaganathan. 874 Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who 875 wrote earlier versions of this document. 877 The authors are indebt to the Kerberos working group chair Jeffrey 878 Hutzelman who kept track of various issues and was enormously helpful 879 during the creation of this document. 881 Some of the ideas on which this document is based arose during 882 discussions over several years between members of the SAAG, the IETF 883 CAT working group, and the PSRG, regarding integration of Kerberos 884 and SPX. Some ideas have also been drawn from the DASS system. 885 These changes are by no means endorsed by these groups. This is an 886 attempt to revive some of the goals of those groups, and this 887 document approaches those goals primarily from the Kerberos 888 perspective. 890 Lastly, comments from groups working on similar ideas in DCE have 891 been invaluable. 893 6. IANA Considerations 895 This document has no actions for IANA. 897 7. References 899 7.1 Normative References 901 [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- 902 krb-wg-kerberos-clarifications. Work in Progress. 904 [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf- 905 krb-wg-crypto. Work in Progress. 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, March 1997. 910 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 911 RFC 2412, November 1998. 913 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 914 RFC 2631, June 1999. 916 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and 917 Identifiers for the Internet X.509 Public Key 918 Infrastructure Certificate and Certificate Revocation List 919 (CRL) Profile", RFC 3279, April 2002. 921 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 922 X.509 Public Key Infrastructure Certificate and 923 Certificate Revocation List (CRL) Profile", RFC 3280, 924 April 2002. 926 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 927 Algorithms", RFC 3370, August 2002. 929 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 930 Standards (PKCS) #1: RSA Cryptography Specifications 931 Version 2.1", RFC 3447, February 2003. 933 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 934 Diffie-Hellman groups for Internet Key Exchange (IKE)", 935 RFC 3526, May 2003. 937 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 938 Encryption Algorithm in Cryptographic Message Syntax 939 (CMS)", RFC 3565, July 2003. 941 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 942 RFC 3852, July 2004. 944 [X690] ASN.1 encoding rules: Specification of Basic Encoding 945 Rules (BER), Canonical Encoding Rules (CER) and 946 Distinguished Encoding Rules (DER), ITU-T Recommendation 947 X.690 (1997) | ISO/IEC International Standard 948 8825-1:1998. 950 7.2 Informative References 952 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the 953 future, Designs, Codes, and Cryptography (1999)". 955 Authors' Addresses 957 Brian Tung 958 USC Information Sciences Institute 959 4676 Admiralty Way Suite 1001, Marina del Rey CA 960 Marina del Rey, CA 90292 961 US 963 Email: brian@isi.edu 965 Larry Zhu 966 Microsoft Corporation 967 One Microsoft Way 968 Redmond, WA 98052 969 US 971 Email: lzhu@microsoft.com 973 Appendix A. PKINIT ASN.1 Module 975 KerberosV5-PK-INIT-SPEC { 976 iso(1) identified-organization(3) dod(6) internet(1) 977 security(5) kerberosV5(2) modules(4) pkinit(5) 978 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 980 IMPORTS 981 SubjectPublicKeyInfo, AlgorithmIdentifier 982 FROM PKIX1Explicit88 { iso (1) 983 identified-organization (3) dod (6) internet (1) 984 security (5) mechanisms (5) pkix (7) id-mod (0) 985 id-pkix1-explicit (18) } 986 -- As defined in RFC 3280. 988 DomainParameters 989 FROM PKIX1Algorithms88 { iso(1) 990 identified-organization(3) dod(6) 991 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 992 id-mod-pkix1-algorithms(17) } 993 -- As defined in RFC 3279. 995 KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey 996 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 997 dod(6) internet(1) security(5) kerberosV5(2) 998 modules(4) krb5spec2(2) } ; 1000 id-pkinit OBJECT IDENTIFIER ::= 1001 { iso (1) org (3) dod (6) internet (1) security (5) 1002 kerberosv5 (2) pkinit (3) } 1004 id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } 1005 id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } 1006 id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } 1007 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } 1008 id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } 1010 pa-pk-as-req INTEGER ::= 16 1011 pa-pk-as-rep INTEGER ::= 17 1013 ad-initial-verified-cas INTEGER ::= 9 1015 td-trusted-certifiers INTEGER ::= 104 1016 td-certificate-index INTEGER ::= 105 1017 td-dh-parameters INTEGER ::= 109 1019 PA-PK-AS-REQ ::= SEQUENCE { 1020 signedAuthPack [0] IMPLICIT OCTET STRING, 1021 -- Contains a CMS type ContentInfo encoded 1022 -- according to [RFC3852]. 1023 -- The contentType field of the type ContentInfo 1024 -- is id-signedData (1.2.840.113549.1.7.2), 1025 -- and the content field is a SignedData. 1026 -- The eContentType field for the type SignedData is 1027 -- id-pkauthdata (1.3.6.1.5.2.3.1), and the 1028 -- eContent field contains the DER encoding of the 1029 -- type AuthPack. 1030 -- AuthPack is defined below. 1031 trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, 1032 -- A list of CAs, trusted by the client, that can 1033 -- be used to validate KDC certificates. 1034 kdcCert [2] IMPLICIT OCTET STRING 1035 OPTIONAL, 1036 -- Contains a CMS type IssuerAndSerialNumber encoded 1037 -- according to [RFC3852]. 1038 -- Identifies a particular KDC certificate, if the 1039 -- client already has it. 1040 ... 1041 } 1043 DHNonce ::= OCTET STRING 1045 TrustedCA ::= CHOICE { 1046 caName [1] IMPLICIT OCTET STRING, 1047 -- Contains a PKIX type Name encoded according to 1048 -- [RFC3280]. 1049 issuerAndSerial [2] IMPLICIT OCTET STRING, 1050 -- Contains a CMS type IssuerAndSerialNumber encoded 1051 -- according to [RFC3852]. 1052 -- Identifies a specific CA certificate. 1053 ... 1054 } 1056 AuthPack ::= SEQUENCE { 1057 pkAuthenticator [0] PKAuthenticator, 1058 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, 1059 -- Defined in [RFC3280]. 1060 -- Present only if the client wishes to use the 1061 -- Diffie-Hellman key agreement method. 1062 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier 1063 OPTIONAL, 1064 -- List of CMS encryption types supported by 1065 -- client in order of (decreasing) preference. 1066 clientDHNonce [3] DHNonce OPTIONAL, 1067 -- Present only if the client indicates that it 1068 -- wishes to cache DH keys or to allow the KDC to 1069 -- do so. 1070 ... 1071 } 1072 PKAuthenticator ::= SEQUENCE { 1073 cusec [0] INTEGER (0..999999), 1074 ctime [1] KerberosTime, 1075 -- cusec and ctime are used as in [CLAR], for replay 1076 -- prevention. 1077 nonce [2] INTEGER (0..4294967295), 1078 -- Chosen randomly; This nonce does not need to 1079 -- match with the nonce in the KDC-REQ-BODY. 1080 paChecksum [3] OCTET STRING, 1081 -- Contains the SHA1 checksum, performed over 1082 -- KDC-REQ-BODY. 1083 ... 1084 } 1086 TrustedCertifiers ::= SEQUENCE OF OCTET STRING 1087 -- The OCTET STRING contains a PKIX type Name encoded 1088 -- according to [RFC3280]. 1090 CertificateIndex ::= OCTET STRING 1091 -- Contains a CMS type IssuerAndSerialNumber encoded 1092 -- according to [RFC3852]. 1094 KRB5PrincipalName ::= SEQUENCE { 1095 realm [0] Realm, 1096 principalName [1] PrincipalName 1097 } 1099 InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { 1100 ca [0] IMPLICIT OCTET STRING, 1101 -- Contains a PKIX type Name encoded according to 1102 -- [RFC3280]. 1103 validated [1] BOOLEAN, 1104 ... 1105 } 1107 PA-PK-AS-REP ::= CHOICE { 1108 dhInfo [0] DHRepInfo, 1109 encKeyPack [1] IMPLICIT OCTET STRING, 1110 -- Contains a CMS type ContentInfo encoded 1111 -- according to [RFC3852]. 1112 -- The contentType field of the type ContentInfo is 1113 -- id-envelopedData (1.2.840.113549.1.7.3). 1114 -- The content field is an EnvelopedData. 1115 -- The contentType field for the type EnvelopedData 1116 -- is id-signedData (1.2.840.113549.1.7.2). 1117 -- The eContentType field for the inner type 1118 -- SignedData (when unencrypted) is id-pkrkeydata 1119 -- (1.2.840.113549.1.7.3) and the eContent field 1120 -- contains the DER encoding of the type 1121 -- ReplyKeyPack. 1122 -- ReplyKeyPack is defined below. 1123 ... 1124 } 1126 DHRepInfo ::= SEQUENCE { 1127 dhSignedData [0] IMPLICIT OCTET STRING, 1128 -- Contains a CMS type ContentInfo encoded according 1129 -- to [RFC3852]. 1130 -- The contentType field of the type ContentInfo is 1131 -- id-signedData (1.2.840.113549.1.7.2), and the 1132 -- content field is a SignedData. 1133 -- The eContentType field for the type SignedData is 1134 -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the 1135 -- eContent field contains the DER encoding of the 1136 -- type KDCDHKeyInfo. 1137 -- KDCDHKeyInfo is defined below. 1138 serverDHNonce [1] DHNonce OPTIONAL 1139 -- Present if and only if dhKeyExpiration is 1140 -- present. 1141 } 1143 KDCDHKeyInfo ::= SEQUENCE { 1144 subjectPublicKey [0] BIT STRING, 1145 -- KDC's public key, y = g^x mod p. 1146 -- MUST be ASN.1 encoded as an INTEGER; 1147 -- This encoding is then used as the contents 1148 -- (i.e., the value) of this BIT STRING field. 1149 nonce [1] INTEGER (0..4294967295), 1150 -- Contains the nonce in the PKAuthenticator of the 1151 -- request if cached DH keys are NOT used, 1152 -- 0 otherwise. 1153 dhKeyExpiration [2] KerberosTime OPTIONAL, 1154 -- Expiration time for KDC's cached values, present 1155 -- if and only if cached DH keys are used. If this 1156 -- field is omitted then the serverDHNonce field 1157 -- MUST also be omitted. 1158 ... 1159 } 1161 ReplyKeyPack ::= SEQUENCE { 1162 replyKey [0] EncryptionKey, 1163 -- Contains the session key used to encrypt the 1164 -- enc-part field in the AS-REP. 1165 nonce [1] INTEGER (0..4294967295), 1166 -- Contains the nonce in the PKAuthenticator of the 1167 -- request. 1169 ... 1170 } 1172 TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters 1173 -- Contains a list of Diffie-Hellman group 1174 -- parameters in decreasing preference order. 1175 END 1177 Intellectual Property Statement 1179 The IETF takes no position regarding the validity or scope of any 1180 Intellectual Property Rights or other rights that might be claimed to 1181 pertain to the implementation or use of the technology described in 1182 this document or the extent to which any license under such rights 1183 might or might not be available; nor does it represent that it has 1184 made any independent effort to identify any such rights. Information 1185 on the procedures with respect to rights in RFC documents can be 1186 found in BCP 78 and BCP 79. 1188 Copies of IPR disclosures made to the IETF Secretariat and any 1189 assurances of licenses to be made available, or the result of an 1190 attempt made to obtain a general license or permission for the use of 1191 such proprietary rights by implementers or users of this 1192 specification can be obtained from the IETF on-line IPR repository at 1193 http://www.ietf.org/ipr. 1195 The IETF invites any interested party to bring to its attention any 1196 copyrights, patents or patent applications, or other proprietary 1197 rights that may cover technology that may be required to implement 1198 this standard. Please address the information to the IETF at 1199 ietf-ipr@ietf.org. 1201 Disclaimer of Validity 1203 This document and the information contained herein are provided on an 1204 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1205 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1206 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1207 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1208 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 Copyright Statement 1213 Copyright (C) The Internet Society (2005). This document is subject 1214 to the rights, licenses and restrictions contained in BCP 78, and 1215 except as set forth therein, the authors retain all their rights. 1217 Acknowledgment 1219 Funding for the RFC Editor function is currently provided by the 1220 Internet Society.