1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-15.txt Clifford Neuman 3Updates: RFC 1510bis USC/ISI 4expires May 25, 2002 Matthew Hur 5 Cisco 6 Ari Medvinsky 7 Keen.com, Inc. 8 Sasha Medvinsky 9 Motorola 10 John Wray 11 Iris Associates, Inc. 12 Jonathan Trostle 13 Cisco 14 15 Public Key Cryptography for Initial Authentication in Kerberos 16 170. Status Of This Memo 18 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026. Internet-Drafts are 21 working documents of the Internet Engineering Task Force (IETF), 22 its areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 To learn the current status of any Internet-Draft, please check 38 the "1id-abstracts.txt" listing contained in the Internet-Drafts 39 Shadow Directories on ftp.ietf.org (US East Coast), 40 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 41 munnari.oz.au (Pacific Rim). 42 43 The distribution of this memo is unlimited. It is filed as 44 draft-ietf-cat-kerberos-pk-init-15.txt, and expires May 25, 2002. 45 Please send comments to the authors. 46 471. Abstract 48 49 This document defines extensions (PKINIT) to the Kerberos protocol 50 specification (RFC 1510bis [1]) to provide a method for using public 51 key cryptography during initial authentication. The methods 52 defined specify the ways in which preauthentication data fields and 53 error data fields in Kerberos messages are to be used to transport 54 public key data. 55 562. Introduction 57 58 The popularity of public key cryptography has produced a desire for 59 its support in Kerberos [2]. The advantages provided by public key 60 cryptography include simplified key management (from the Kerberos 61 perspective) and the ability to leverage existing and developing 62 public key certification infrastructures. 63 64 Public key cryptography can be integrated into Kerberos in a number 65 of ways. One is to associate a key pair with each realm, which can 66 then be used to facilitate cross-realm authentication; this is the 67 topic of another draft proposal. Another way is to allow users with 68 public key certificates to use them in initial authentication. This 69 is the concern of the current document. 70 71 PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in 72 combination with DSA keys as the primary, required mechanism. Note 73 that PKINIT supports the use of separate signature and encryption 74 keys. 75 76 PKINIT enables access to Kerberos-secured services based on initial 77 authentication utilizing public key cryptography. PKINIT utilizes 78 standard public key signature and encryption data formats within the 79 standard Kerberos messages. The basic mechanism is as follows: The 80 user sends an AS-REQ message to the KDC as before, except that if that 81 user is to use public key cryptography in the initial authentication 82 step, his certificate and a signature accompany the initial request 83 in the preauthentication fields. Upon receipt of this request, the 84 KDC verifies the certificate and issues a ticket granting ticket 85 (TGT) as before, except that the encPart from the AS-REP message 86 carrying the TGT is now encrypted utilizing either a Diffie-Hellman 87 derived key or the user's public key. This message is authenticated 88 utilizing the public key signature of the KDC. 89 90 Note that PKINIT does not require the use of certificates. A KDC 91 may store the public key of a principal as part of that principal's 92 record. In this scenario, the KDC is the trusted party that vouches 93 for the principal (as in a standard, non-cross realm, Kerberos 94 environment). Thus, for any principal, the KDC may maintain a 95 symmetric key, a public key, or both. 96 97 The PKINIT specification may also be used as a building block for 98 other specifications. PKINIT may be utilized to establish 99 inter-realm keys for the purposes of issuing cross-realm service 100 tickets. It may also be used to issue anonymous Kerberos tickets 101 using the Diffie-Hellman option. Efforts are under way to draft 102 specifications for these two application protocols. 103 104 Additionally, the PKINIT specification may be used for direct peer 105 to peer authentication without contacting a central KDC. This 106 application of PKINIT is based on concepts introduced in [6, 7]. 107 For direct client-to-server authentication, the client uses PKINIT 108 to authenticate to the end server (instead of a central KDC), which 109 then issues a ticket for itself. This approach has an advantage 110 over TLS [5] in that the server does not need to save state (cache 111 session keys). Furthermore, an additional benefit is that Kerberos 112 tickets can facilitate delegation (see [6]). 113 1143. Proposed Extensions 115 116 This section describes extensions to RFC 1510bis for supporting the 117 use of public key cryptography in the initial request for a ticket 118 granting ticket (TGT). 119 120 In summary, the following change to RFC 1510bis is proposed: 121 122 * Users may authenticate using either a public key pair or a 123 conventional (symmetric) key. If public key cryptography is 124 used, public key data is transported in preauthentication 125 data fields to help establish identity. The user presents 126 a public key certificate and obtains an ordinary TGT that may 127 be used for subsequent authentication, with such 128 authentication using only conventional cryptography. 129 130 Section 3.1 provides definitions to help specify message formats. 131 Section 3.2 describes the extensions for the initial authentication 132 method. 133 1343.1. Definitions 135 136 The extensions involve new preauthentication fields; we introduce 137 the following preauthentication types: 138 139 PA-PK-AS-REQ 14 140 PA-PK-AS-REP 15 141 142 The extensions also involve new error types; we introduce the 143 following types: 144 145 KDC_ERR_CLIENT_NOT_TRUSTED 62 146 KDC_ERR_KDC_NOT_TRUSTED 63 147 KDC_ERR_INVALID_SIG 64 148 KDC_ERR_KEY_TOO_WEAK 65 149 KDC_ERR_CERTIFICATE_MISMATCH 66 150 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 151 KDC_ERR_INVALID_CERTIFICATE 71 152 KDC_ERR_REVOKED_CERTIFICATE 72 153 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 154 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 155 KDC_ERR_CLIENT_NAME_MISMATCH 75 156 KDC_ERR_KDC_NAME_MISMATCH 76 157 158 We utilize the following typed data for errors: 159 160 TD-PKINIT-CMS-CERTIFICATES 101 161 TD-KRB-PRINCIPAL 102 162 TD-KRB-REALM 103 163 TD-TRUSTED-CERTIFIERS 104 164 TD-CERTIFICATE-INDEX 105 165 166 We utilize the following encryption types (which map directly to 167 OIDs): 168 169 dsaWithSHA1-CmsOID 9 170 md5WithRSAEncryption-CmsOID 10 171 sha1WithRSAEncryption-CmsOID 11 172 rc2CBC-EnvOID 12 173 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 174 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 175 des-ede3-cbc-Env-OID 15 176 177 These mappings are provided so that a client may send the 178 appropriate enctypes in the AS-REQ message in order to indicate 179 support for the corresponding OIDs (for performing PKINIT). The 180 above encryption types are utilized only within CMS structures 181 within the PKINIT preauthentication fields. Their use within 182 the Kerberos EncryptedData structure is unspecified. 183 184 In many cases, PKINIT requires the encoding of the X.500 name of a 185 certificate authority as a Realm. When such a name appears as 186 a realm it will be represented using the "Other" form of the realm 187 name as specified in the naming constraints section of RFC 1510bis. 188 For a realm derived from an X.500 name, NAMETYPE will have the value 189 X500-RFC2253. The full realm name will appear as follows: 190 191 <nametype> + ":" + <string> 192 193 where nametype is "X500-RFC2253" and string is the result of doing 194 an RFC2253 encoding of the distinguished name, i.e. 195 196 "X500-RFC2253:" + RFC2253Encode(DistinguishedName) 197 198 where DistinguishedName is an X.500 name, and RFC2253Encode is a 199 function returing a readable UTF encoding of an X.500 name, as 200 defined by RFC 2253 [11] (part of LDAPv3 [15]). 201 202 Each component of a DistinguishedName is called a 203 RelativeDistinguishedName, where a RelativeDistinguishedName is a 204 SET OF AttributeTypeAndValue. RFC 2253 does not specify the order 205 in which to encode the elements of the RelativeDistinguishedName and 206 so to ensure that this encoding is unique, we add the following rule 207 to those specified by RFC 2253: 208 209 When converting a multi-valued RelativeDistinguishedName 210 to a string, the output consists of the string encodings 211 of each AttributeTypeAndValue, in the same order as 212 specified by the DER encoding. 213 214 Similarly, in cases where the KDC does not provide a specific 215 policy-based mapping from the X.500 name or X.509 Version 3 216 SubjectAltName extension in the user's certificate to a Kerberos 217 principal name, PKINIT requires the direct encoding of the X.500 218 name as a PrincipalName. In this case, the name-type of the 219 principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new 220 name type is defined in RFC 1510bis as: 221 222 KRB_NT_X500_PRINCIPAL 6 223 224 For this type, the name-string MUST be set as follows: 225 226 RFC2253Encode(DistinguishedName) 227 228 as described above. When this name type is used, the principal's 229 realm MUST be set to the certificate authority's distinguished 230 name using the X500-RFC2253 realm name format described earlier in 231 this section. 232 233 Note that the same string may be represented using several different 234 ASN.1 data types. As the result, the reverse conversion from an 235 RFC2253-encoded principal name back to an X.500 name may not be 236 unique and may result in an X.500 name that is not the same as the 237 original X.500 name found in the client certificate. 238 239 RFC 1510bis describes an alternate encoding of an X.500 name into a 240 realm name. However, as described in RFC 1510bis, the alternate 241 encoding does not guarantee a unique mapping from a 242 DistinguishedName inside a certificate into a realm name and 243 similarly cannot be used to produce a unique principal name. PKINIT 244 therefore uses an RFC 2253-based name mapping approach, as specified 245 above. 246 247 RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: 248 249 PrincipalName ::= SEQUENCE { 250 name-type[0] INTEGER, 251 name-string[1] SEQUENCE OF GeneralString 252 } 253 254 The following rules relate to the the matching of PrincipalNames 255 with regard to the PKI name constraints for CAs as laid out in RFC 256 2459 [12]. In order to be regarded as a match (for permitted and 257 excluded name trees), the following MUST be satisfied. 258 259 1. If the constraint is given as a user plus realm name, or 260 as a client principal name plus realm name (as specified in 261 RFC 1510bis), the realm name MUST be valid (see 2.a-d below) 262 and the match MUST be exact, byte for byte. 263 264 2. If the constraint is given only as a realm name, matching 265 depends on the type of the realm: 266 267 a. If the realm contains a colon (':') before any equal 268 sign ('='), it is treated as a realm of type Other, 269 and MUST match exactly, byte for byte. 270 271 b. Otherwise, if the realm name conforms to rules regarding 272 the format of DNS names, it is considered a realm name of 273 type Domain. The constraint may be given as a realm 274 name 'FOO.BAR', which matches any PrincipalName within 275 the realm 'FOO.BAR' but not those in subrealms such as 276 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' 277 matches PrincipalNames in subrealms of the form 278 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. 279 280 c. Otherwise, the realm name is invalid and does not match 281 under any conditions. 282 2833.1.1. Encryption and Key Formats 284 285 In the exposition below, we use the terms public key and private 286 key generically. It should be understood that the term "public 287 key" may be used to refer to either a public encryption key or a 288 signature verification key, and that the term "private key" may be 289 used to refer to either a private decryption key or a signature 290 generation key. The fact that these are logically distinct does 291 not preclude the assignment of bitwise identical keys for RSA 292 keys. 293 294 In the case of Diffie-Hellman, the key is produced from the agreed 295 bit string as follows: 296 297 * Truncate the bit string to the required length. 298 * Apply the specific cryptosystem's random-to-key function. 299 300 Appropriate key constraints for each valid cryptosystem are given 301 in RFC 1510bis. 302 3033.1.2. Algorithm Identifiers 304 305 PKINIT does not define, but does permit, the algorithm identifiers 306 listed below. 307 3083.1.2.1. Signature Algorithm Identifiers 309 310 The following signature algorithm identifiers specified in [8] and 311 in [12] are used with PKINIT: 312 313 id-dsa-with-sha1 (DSA with SHA1) 314 md5WithRSAEncryption (RSA with MD5) 315 sha-1WithRSAEncryption (RSA with SHA1) 316 3173.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 318 319 The following algorithm identifier shall be used within the 320 SubjectPublicKeyInfo data structure: dhpublicnumber 321 322 This identifier and the associated algorithm parameters are 323 specified in RFC 2459 [12]. 324 3253.1.2.3. Algorithm Identifiers for RSA Encryption 326 327 These algorithm identifiers are used inside the EnvelopedData data 328 structure, for encrypting the temporary key with a public key: 329 330 rsaEncryption (RSA encryption, PKCS#1 v1.5) 331 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) 332 333 Both of the above RSA encryption schemes are specified in [13]. 334 Currently, only PKCS#1 v1.5 is specified by CMS [8], although the 335 CMS specification says that it will likely include PKCS#1 v2.0 in 336 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext 337 vulnerability discovered in PKCS#1 v1.5.) 338 3393.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 340 341 These algorithm identifiers are used inside the EnvelopedData data 342 structure in the PKINIT Reply, for encrypting the reply key with the 343 temporary key: 344 des-ede3-cbc (3-key 3-DES, CBC mode) 345 rc2-cbc (RC2, CBC mode) 346 347 The full definition of the above algorithm identifiers and their 348 corresponding parameters (an IV for block chaining) is provided in 349 the CMS specification [8]. 350 3513.2. Public Key Authentication 352 353 Implementation of the changes in this section is REQUIRED for 354 compliance with PKINIT. 355 3563.2.1. Client Request 357 358 Public keys may be signed by some certification authority (CA), or 359 they may be maintained by the KDC in which case the KDC is the 360 trusted authority. Note that the latter mode does not require the 361 use of certificates. 362 363 The initial authentication request is sent as per RFC 1510bis, except 364 that a preauthentication field containing data signed by the user's 365 private key accompanies the request: 366 367 PA-PK-AS-REQ ::= SEQUENCE { 368 -- PA TYPE 14 369 signedAuthPack [0] ContentInfo, 370 -- Defined in CMS [8]; 371 -- SignedData OID is {pkcs7 2} 372 -- AuthPack (below) defines the 373 -- data that is signed. 374 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, 375 -- This is a list of CAs that the 376 -- client trusts and that certify 377 -- KDCs. 378 kdcCert [2] IssuerAndSerialNumber OPTIONAL 379 -- As defined in CMS [8]; 380 -- specifies a particular KDC 381 -- certificate if the client 382 -- already has it. 383 encryptionCert [3] IssuerAndSerialNumber OPTIONAL 384 -- For example, this may be the 385 -- client's Diffie-Hellman 386 -- certificate, or it may be the 387 -- client's RSA encryption 388 -- certificate. 389 } 390 391 TrustedCas ::= CHOICE { 392 principalName [0] KerberosName, 393 -- as defined below 394 caName [1] Name 395 -- fully qualified X.500 name 396 -- as defined by X.509 397 issuerAndSerial [2] IssuerAndSerialNumber 398 -- Since a CA may have a number of 399 -- certificates, only one of which 400 -- a client trusts 401 } 402 403 The type of the ContentInfo in the signedAuthPack is SignedData. 404 Its usage is as follows: 405 406 The SignedData data type is specified in the Cryptographic 407 Message Syntax, a product of the S/MIME working group of the 408 IETF. The following describes how to fill in the fields of 409 this data: 410 411 1. The encapContentInfo field MUST contain the PKAuthenticator 412 and, optionally, the client's Diffie Hellman public value. 413 414 a. The eContentType field MUST contain the OID value for 415 pkauthdata: iso (1) org (3) dod (6) internet (1) 416 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) 417 418 b. The eContent field is data of the type AuthPack (below). 419 420 2. The signerInfos field contains the signature of AuthPack. 421 422 3. The Certificates field, when non-empty, contains the client's 423 certificate chain. If present, the KDC uses the public key 424 from the client's certificate to verify the signature in the 425 request. Note that the client may pass different certificate 426 chains that are used for signing or for encrypting. Thus, 427 the KDC may utilize a different client certificate for 428 signature verification than the one it uses to encrypt the 429 reply to the client. For example, the client may place a 430 Diffie-Hellman certificate in this field in order to convey 431 its static Diffie Hellman certificate to the KDC to enable 432 static-ephemeral Diffie-Hellman mode for the reply; in this 433 case, the client does NOT place its public value in the 434 AuthPack (defined below). As another example, the client may 435 place an RSA encryption certificate in this field. However, 436 there MUST always be (at least) a signature certificate. 437 438 4. When a DH key is being used, the public exponent is provided 439 in the subjectPublicKey field of the SubjectPublicKeyInfo and 440 the DH parameters are supplied as a DHParameter in the 441 AlgorithmIdentitfier parameters. The DH paramters SHOULD be 442 chosen from the First and Second defined Oakley Groups [The 443 Internet Key Exchange (IKE) RFC-2409], if a server will not 444 accept either of these groups, it will respond with a krb-error 445 of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a 446 DHParameter with appropriate parameters for the client to use. 447 448 5. The KDC may wish to use cached Diffie-Hellman parameters 449 (see Section 3.2.2, KDC Response). To indicate acceptance 450 of cached parameters, the client sends zero in the nonce 451 field of the PKAuthenticator. Zero is not a valid value 452 for this field under any other circumstances. If cached 453 parameters are used, the client and the KDC MUST perform 454 key derivation (for the appropriate cryptosystem) on the 455 resulting encryption key, as specified in RFC 1510bis. (With 456 a zero nonce, message binding is performed using the nonce 457 in the main request, which must be encrypted using the 458 encapsulated reply key.) 459 460 AuthPack ::= SEQUENCE { 461 pkAuthenticator [0] PKAuthenticator, 462 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 463 -- if client is using Diffie-Hellman 464 -- (ephemeral-ephemeral only) 465 } 466 467 PKAuthenticator ::= SEQUENCE { 468 cusec [0] INTEGER, 469 -- for replay prevention as in RFC 1510bis 470 ctime [1] KerberosTime, 471 -- for replay prevention as in RFC 1510bis 472 nonce [2] INTEGER, 473 -- zero only if client will accept 474 -- cached DH parameters from KDC; 475 -- must be non-zero otherwise 476 pachecksum [3] Checksum 477 -- Checksum over KDC-REQ-BODY 478 -- Defined by Kerberos spec; 479 -- must be unkeyed, e.g. sha1 or rsa-md5 480 } 481 482 SubjectPublicKeyInfo ::= SEQUENCE { 483 algorithm AlgorithmIdentifier, 484 -- dhKeyAgreement 485 subjectPublicKey BIT STRING 486 -- for DH, equals 487 -- public exponent (INTEGER encoded 488 -- as payload of BIT STRING) 489 } -- as specified by the X.509 recommendation [7] 490 491 AlgorithmIdentifier ::= SEQUENCE { 492 algorithm OBJECT IDENTIFIER, 493 -- for dhKeyAgreement, this is 494 -- { iso (1) member-body (2) US (840) 495 -- rsadsi (113459) pkcs (1) 3 1 } 496 -- from PKCS #3 [17] 497 parameters ANY DEFINED by algorithm OPTIONAL 498 -- for dhKeyAgreement, this is 499 -- DHParameter 500 } -- as specified by the X.509 recommendation [7] 501 502 DHParameter ::= SEQUENCE { 503 prime INTEGER, 504 -- p 505 base INTEGER, 506 -- g 507 privateValueLength INTEGER OPTIONAL 508 -- l 509 } -- as defined in PKCS #3 [17] 510 511 If the client passes an issuer and serial number in the request, 512 the KDC is requested to use the referred-to certificate. If none 513 exists, then the KDC returns an error of type 514 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 515 other hand, the client does not pass any trustedCertifiers, 516 believing that it has the KDC's certificate, but the KDC has more 517 than one certificate. The KDC should include information in the 518 KRB-ERROR message that indicates the KDC certificate(s) that a 519 client may utilize. This data is specified in the e-data, which 520 is defined in RFC 1510bis revisions as a SEQUENCE of TypedData: 521 522 TypedData ::= SEQUENCE { 523 data-type [0] INTEGER, 524 data-value [1] OCTET STRING, 525 } -- per Kerberos RFC 1510bis 526 527 where: 528 data-type = TD-PKINIT-CMS-CERTIFICATES = 101 529 data-value = CertificateSet // as specified by CMS [8] 530 531 The PKAuthenticator carries information to foil replay attacks, to 532 bind the pre-authentication data to the KDC-REQ-BODY, and to bind the 533 request and response. The PKAuthenticator is signed with the client's 534 signature key. 535 5363.2.2. KDC Response 537 538 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 539 type, the KDC attempts to verify the user's certificate chain 540 (userCert), if one is provided in the request. This is done by 541 verifying the certification path against the KDC's policy of 542 legitimate certifiers. 543 544 If the client's certificate chain contains no certificate signed by 545 a CA trusted by the KDC, then the KDC sends back an error message 546 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data 547 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) 548 whose data-value is an OCTET STRING which is the DER encoding of 549 550 TrustedCertifiers ::= SEQUENCE OF PrincipalName 551 -- X.500 name encoded as a principal name 552 -- see Section 3.1 553 554 If while verifying a certificate chain the KDC determines that the 555 signature on one of the certificates in the CertificateSet from 556 the signedAuthPack fails verification, then the KDC returns an 557 error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying 558 e-data is a SEQUENCE of one TypedData (with type 559 TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING 560 which is the DER encoding of the index into the CertificateSet 561 ordered as sent by the client. 562 563 CertificateIndex ::= INTEGER 564 -- 0 = 1st certificate, 565 -- (in order of encoding) 566 -- 1 = 2nd certificate, etc 567 568 The KDC may also check whether any of the certificates in the 569 client's chain has been revoked. If one of the certificates has 570 been revoked, then the KDC returns an error of type 571 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that 572 the certificate's revocation status is unknown or not 573 available, then if required by policy, the KDC returns the 574 appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or 575 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three 576 cases, the affected certificate is identified by the accompanying 577 e-data, which contains a CertificateIndex as described for 578 KDC_ERR_INVALID_CERTIFICATE. 579 580 If the certificate chain can be verified, but the name of the 581 client in the certificate does not match the client's name in the 582 request, then the KDC returns an error of type 583 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 584 field in this case. 585 586 Even if all succeeds, the KDC may--for policy reasons--decide not 587 to trust the client. In this case, the KDC returns an error message 588 of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is 589 the presence or absence of an Enhanced Key Usage (EKU) OID within 590 the certificate extensions. The rules regarding acceptability of 591 an EKU sequence (or the absence of any sequence) are a matter of 592 local policy. For the benefit of implementers, we define a PKINIT 593 EKU OID as the following: iso (1) org (3) dod (6) internet (1) 594 security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). 595 596 If a trust relationship exists, the KDC then verifies the client's 597 signature on AuthPack. If that fails, the KDC returns an error 598 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 599 timestamp (ctime and cusec) in the PKAuthenticator to assure that 600 the request is not a replay. The KDC also verifies that its name 601 is specified in the PKAuthenticator. 602 603 If the clientPublicValue field is filled in, indicating that the 604 client wishes to use Diffie-Hellman key agreement, then the KDC 605 checks to see that the parameters satisfy its policy. If they do 606 not (e.g., the prime size is insufficient for the expected 607 encryption type), then the KDC sends back an error message of type 608 KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of 609 type DHParameter with appropriate DH parameters for the client to 610 retry the request. Otherwise, it generates its own public and 611 private values for the response. 612 613 The KDC also checks that the timestamp in the PKAuthenticator is 614 within the allowable window and that the principal name and realm 615 are correct. If the local (server) time and the client time in the 616 authenticator differ by more than the allowable clock skew, then the 617 KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 618 RFC 1510bis. 619 620 Assuming no errors, the KDC replies as per RFC 1510bis, except as 621 follows. The user's name in the ticket is determined by the 622 following decision algorithm: 623 624 1. If the KDC has a mapping from the name in the certificate 625 to a Kerberos name, then use that name. 626 Else 627 2. If the certificate contains the SubjectAltName extention 628 and the local KDC policy defines a mapping from the 629 SubjectAltName to a Kerberos name, then use that name. 630 Else 631 3. Use the name as represented in the certificate, mapping 632 as necessary (e.g., as per RFC 2253 for X.500 names). In 633 this case the realm in the ticket MUST be the name of the 634 certifier that issued the user's certificate. 635 636 Note that a principal name may be carried in the subjectAltName 637 field of a certificate. This name may be mapped to a principal 638 record in a security database based on local policy, for example 639 the subjectAltName may be kerberos/principal@realm format. In 640 this case the realm name is not that of the CA but that of the 641 local realm doing the mapping (or some realm name chosen by that 642 realm). 643 644 If a non-KDC X.509 certificate contains the principal name within 645 the subjectAltName version 3 extension, that name may utilize 646 KerberosName as defined below, or, in the case of an S/MIME 647 certificate [14], may utilize the email address. If the KDC 648 is presented with an S/MIME certificate, then the email address 649 within subjectAltName will be interpreted as a principal and realm 650 separated by the "@" sign, or as a name that needs to be mapped 651 according to local policy. If the resulting name does not correspond 652 to a registered principal name, then the principal name is formed as 653 defined in section 3.1. 654 655 The trustedCertifiers field contains a list of certification 656 authorities trusted by the client, in the case that the client does 657 not possess the KDC's public key certificate. If the KDC has no 658 certificate signed by any of the trustedCertifiers, then it returns 659 an error of type KDC_ERR_KDC_NOT_TRUSTED. 660 661 KDCs should try to (in order of preference): 662 1. Use the KDC certificate identified by the serialNumber included 663 in the client's request. 664 2. Use a certificate issued to the KDC by one of the client's 665 trustedCertifier(s); 666 If the KDC is unable to comply with any of these options, then the 667 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 668 client. 669 670 The KDC encrypts the reply not with the user's long-term key, but 671 with the Diffie Hellman derived key or a random key generated 672 for this particular response which is carried in the padata field of 673 the TGS-REP message. 674 675 PA-PK-AS-REP ::= CHOICE { 676 -- PA TYPE 15 677 dhSignedData [0] ContentInfo, 678 -- Defined in CMS [8] and used only with 679 -- Diffie-Hellman key exchange (if the 680 -- client public value was present in the 681 -- request). 682 -- SignedData OID is {pkcs7 2} 683 -- This choice MUST be supported 684 -- by compliant implementations. 685 encKeyPack [1] ContentInfo 686 -- Defined in CMS [8]. 687 -- The temporary key is encrypted 688 -- using the client public key 689 -- key. 690 -- EnvelopedData OID is {pkcs7 3} 691 -- SignedReplyKeyPack, encrypted 692 -- with the temporary key, is also 693 -- included. 694 } 695 696 The type of the ContentInfo in the dhSignedData is SignedData. 697 Its usage is as follows: 698 699 When the Diffie-Hellman option is used, dhSignedData in 700 PA-PK-AS-REP provides authenticated Diffie-Hellman parameters 701 of the KDC. The reply key used to encrypt part of the KDC reply 702 message is derived from the Diffie-Hellman exchange: 703 704 1. Both the KDC and the client calculate a secret value 705 (g^ab mod p), where a is the client's private exponent and 706 b is the KDC's private exponent. 707 708 2. Both the KDC and the client take the first N bits of this 709 secret value and convert it into a reply key. N depends on 710 the reply key type. 711 712 a. For example, if the reply key is DES, N=64 bits, where 713 some of the bits are replaced with parity bits, according 714 to FIPS PUB 74. 715 716 b. As another example, if the reply key is (3-key) 3-DES, 717 N=192 bits, where some of the bits are replaced with 718 parity bits, according to FIPS PUB 74. 719 720 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as 721 defined below. 722 723 a. The eContentType field MUST contain the OID value for 724 pkdhkeydata: iso (1) org (3) dod (6) internet (1) 725 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) 726 727 b. The eContent field is data of the type KdcDHKeyInfo 728 (below). 729 730 4. The certificates field MUST contain the certificates 731 necessary for the client to establish trust in the KDC's 732 certificate based on the list of trusted certifiers sent by 733 the client in the PA-PK-AS-REQ. This field may be empty if 734 the client did not send to the KDC a list of trusted 735 certifiers (the trustedCertifiers field was empty, meaning 736 that the client already possesses the KDC's certificate). 737 738 5. The signerInfos field is a SET that MUST contain at least 739 one member, since it contains the actual signature. 740 741 6. If the client indicated acceptance of cached Diffie-Hellman 742 parameters from the KDC, and the KDC supports such an option 743 (for performance reasons), the KDC should return a zero in 744 the nonce field and include the expiration time of the 745 parameters in the dhKeyExpiration field. If this time is 746 exceeded, the client SHOULD NOT use the reply. If the time 747 is absent, the client SHOULD NOT use the reply and MAY 748 resubmit a request with a non-zero nonce (thus indicating 749 non-acceptance of cached Diffie-Hellman parameters). As 750 indicated above in Section 3.2.1, Client Request, when the 751 KDC uses cached parameters, the client and the KDC MUST 752 perform key derivation (for the appropriate cryptosystem) 753 on the resulting encryption key, as specified in RFC 1510bis. 754 755 KdcDHKeyInfo ::= SEQUENCE { 756 -- used only when utilizing Diffie-Hellman 757 subjectPublicKey [0] BIT STRING, 758 -- Equals public exponent (g^a mod p) 759 -- INTEGER encoded as payload of 760 -- BIT STRING 761 nonce [1] INTEGER, 762 -- Binds response to the request 763 -- Exception: Set to zero when KDC 764 -- is using a cached DH value 765 dhKeyExpiration [2] KerberosTime OPTIONAL 766 -- Expiration time for KDC's cached 767 -- DH value 768 } 769 770 The type of the ContentInfo in the encKeyPack is EnvelopedData. Its 771 usage is as follows: 772 773 The EnvelopedData data type is specified in the Cryptographic 774 Message Syntax, a product of the S/MIME working group of the 775 IETF. It contains a temporary key encrypted with the PKINIT 776 client's public key. It also contains a signed and encrypted 777 reply key. 778 779 1. The originatorInfo field is not required, since that 780 information may be presented in the signedData structure 781 that is encrypted within the encryptedContentInfo field. 782 783 2. The optional unprotectedAttrs field is not required for 784 PKINIT. 785 786 3. The recipientInfos field is a SET which MUST contain exactly 787 one member of the KeyTransRecipientInfo type for encryption 788 with a public key. 789 790 a. The encryptedKey field (in KeyTransRecipientInfo) 791 contains the temporary key which is encrypted with the 792 PKINIT client's public key. 793 794 4. The encryptedContentInfo field contains the signed and 795 encrypted reply key. 796 797 a. The contentType field MUST contain the OID value for 798 id-signedData: iso (1) member-body (2) us (840) 799 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) 800 801 b. The encryptedContent field is encrypted data of the CMS 802 type signedData as specified below. 803 804 i. The encapContentInfo field MUST contains the 805 ReplyKeyPack. 806 807 * The eContentType field MUST contain the OID value 808 for pkrkeydata: iso (1) org (3) dod (6) internet (1) 809 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) 810 811 * The eContent field is data of the type ReplyKeyPack 812 (below). 813 814 ii. The certificates field MUST contain the certificates 815 necessary for the client to establish trust in the 816 KDC's certificate based on the list of trusted 817 certifiers sent by the client in the PA-PK-AS-REQ. 818 This field may be empty if the client did not send 819 to the KDC a list of trusted certifiers (the 820 trustedCertifiers field was empty, meaning that the 821 client already possesses the KDC's certificate). 822 823 iii. The signerInfos field is a SET that MUST contain at 824 least one member, since it contains the actual 825 signature. 826 827 ReplyKeyPack ::= SEQUENCE { 828 -- not used for Diffie-Hellman 829 replyKey [0] EncryptionKey, 830 -- from RFC 1510bis 831 -- used to encrypt main reply 832 -- ENCTYPE is at least as strong as 833 -- ENCTYPE of session key 834 nonce [1] INTEGER, 835 -- binds response to the request 836 -- must be same as the nonce 837 -- passed in the PKAuthenticator 838 } 839 840 8413.2.2.1. Use of transited Field 842 843 Since each certifier in the certification path of a user's 844 certificate is equivalent to a separate Kerberos realm, the name 845 of each certifier in the certificate chain MUST be added to the 846 transited field of the ticket. The format of these realm names is 847 defined in Section 3.1 of this document. If applicable, the 848 transit-policy-checked flag should be set in the issued ticket. 849 850 8513.2.2.2. Kerberos Names in Certificates 852 853 The KDC's certificate(s) MUST bind the public key(s) of the KDC to 854 a name derivable from the name of the realm for that KDC. X.509 855 certificates MUST contain the principal name of the KDC (defined in 856 RFC 1510bis) as the SubjectAltName version 3 extension. Below is 857 the definition of this version 3 extension, as specified by the 858 X.509 standard: 859 860 subjectAltName EXTENSION ::= { 861 SYNTAX GeneralNames 862 IDENTIFIED BY id-ce-subjectAltName 863 } 864 865 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 866 867 GeneralName ::= CHOICE { 868 otherName [0] OtherName, 869 ... 870 } 871 872 OtherName ::= SEQUENCE { 873 type-id OBJECT IDENTIFIER, 874 value [0] EXPLICIT ANY DEFINED BY type-id 875 } 876 877 For the purpose of specifying a Kerberos principal name, the value 878 in OtherName MUST be a KerberosName, defined as follows: 879 880 KerberosName ::= SEQUENCE { 881 realm [0] Realm, 882 principalName [1] PrincipalName 883 } 884 885 This specific syntax is identified within subjectAltName by setting 886 the type-id in OtherName to krb5PrincipalName, where (from the 887 Kerberos specification) we have 888 889 krb5 OBJECT IDENTIFIER ::= { iso (1) 890 org (3) 891 dod (6) 892 internet (1) 893 security (5) 894 kerberosv5 (2) } 895 896 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 897 898 (This specification may also be used to specify a Kerberos name 899 within the user's certificate.) The KDC's certificate may be signed 900 directly by a CA, or there may be intermediaries if the server resides 901 within a large organization, or it may be unsigned if the client 902 indicates possession (and trust) of the KDC's certificate. 903 904 Note that the KDC's principal name has the instance equal to the 905 realm, and those fields should be appropriately set in the realm 906 and principalName fields of the KerberosName. This is the case 907 even when obtaining a cross-realm ticket using PKINIT. 908 909 9103.2.3. Client Extraction of Reply 911 912 The client then extracts the random key used to encrypt the main 913 reply. This random key (in encPaReply) is encrypted with either the 914 client's public key or with a key derived from the DH values 915 exchanged between the client and the KDC. The client uses this 916 random key to decrypt the main reply, and subsequently proceeds as 917 described in RFC 1510bis. 918 9193.2.4. Required Algorithms 920 921 Not all of the algorithms in the PKINIT protocol specification have 922 to be implemented in order to comply with the proposed standard. 923 Below is a list of the required algorithms: 924 925 * Diffie-Hellman public/private key pairs 926 * utilizing Diffie-Hellman ephemeral-ephemeral mode 927 * SHA1 digest and DSA for signatures 928 * SHA1 digest for the Checksum in the PKAuthenticator 929 * using Kerberos checksum type 'sha1' 930 * 3-key triple DES keys derived from the Diffie-Hellman Exchange 931 * 3-key triple DES Temporary and Reply keys 932 9334. Logistics and Policy 934 935 This section describes a way to define the policy on the use of 936 PKINIT for each principal and request. 937 938 The KDC is not required to contain a database record for users 939 who use public key authentication. However, if these users are 940 registered with the KDC, it is recommended that the database record 941 for these users be modified to an additional flag in the attributes 942 field to indicate that the user should authenticate using PKINIT. 943 If this flag is set and a request message does not contain the 944 PKINIT preauthentication field, then the KDC sends back as error of 945 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication 946 field of type PA-PK-AS-REQ must be included in the request. 947 9485. Security Considerations 949 950 PKINIT raises a few security considerations, which we will address 951 in this section. 952 953 First of all, PKINIT extends the cross-realm model to the public 954 key infrastructure. Anyone using PKINIT must be aware of how the 955 certification infrastructure they are linking to works. 956 957 Also, as in standard Kerberos, PKINIT presents the possibility of 958 interactions between different cryptosystems of varying strengths, 959 and this now includes public-key cryptosystems. Many systems, for 960 instance, allow the use of 512-bit public keys. Using such keys 961 to wrap data encrypted under strong conventional cryptosystems, 962 such as triple-DES, may be inappropriate. 963 964 Care should be taken in how certificates are choosen for the purposes 965 of authentication using PKINIT. Some local policies require that key 966 escrow be applied for certain certificate types. People deploying 967 PKINIT should be aware of the implications of using certificates that 968 have escrowed keys for the purposes of authentication. 969 970 As described in Section 3.2, PKINIT allows for the caching of the 971 Diffie-Hellman parameters on the KDC side, for performance reasons. 972 For similar reasons, the signed data in this case does not vary from 973 message to message, until the cached parameters expire. Because of 974 the persistence of these parameters, the client and the KDC are to 975 use the appropriate key derivation measures (as described in RFC 976 1510bis) when using cached DH parameters. 977 978 Lastly, PKINIT calls for randomly generated keys for conventional 979 cryptosystems. Many such systems contain systematically "weak" 980 keys. For recommendations regarding these weak keys, see RFC 981 1510bis. 982 9836. Transport Issues 984 985 Certificate chains can potentially grow quite large and span several 986 UDP packets; this in turn increases the probability that a Kerberos 987 message involving PKINIT extensions will be broken in transit. In 988 light of the possibility that the Kerberos specification will 989 require KDCs to accept requests using TCP as a transport mechanism, 990 we make the same recommendation with respect to the PKINIT 991 extensions as well. 992 9937. Bibliography 994 995 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 996 (V5). Request for Comments 1510. 997 998 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 999 for Computer Networks, IEEE Communications, 32(9):33-38. September 1000 1994. 1001 1002 [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 1003 Using Public Key Cryptography. Symposium On Network and Distributed 1004 System Security, 1997. 1005 1006 [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 1007 Protocol. In Proceedings of the USENIX Workshop on Electronic 1008 Commerce, July 1995. 1009 1010 [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 1011 Request for Comments 2246, January 1999. 1012 1013 [6] B.C. Neuman, Proxy-Based Authorization and Accounting for 1014 Distributed Systems. In Proceedings of the 13th International 1015 Conference on Distributed Computing Systems, May 1993. 1016 1017 [7] ITU-T (formerly CCITT) Information technology - Open Systems 1018 Interconnection - The Directory: Authentication Framework 1019 Recommendation X.509 ISO/IEC 9594-8 1020 1021 [8] R. Housley. Cryptographic Message Syntax. 1022 draft-ietf-smime-cms-13.txt, April 1999, approved for publication 1023 as RFC. 1024 1025 [9] PKCS #7: Cryptographic Message Syntax Standard, 1026 An RSA Laboratories Technical Note Version 1.5 1027 Revised November 1, 1993 1028 1029 [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data 1030 Security, Inc. A Description of the RC2(r) Encryption Algorithm 1031 March 1998. 1032 Request for Comments 2268. 1033 1034 [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 1035 Protocol (v3): UTF-8 String Representation of Distinguished Names. 1036 Request for Comments 2253. 1037 1038 [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 1039 Key Infrastructure, Certificate and CRL Profile, January 1999. 1040 Request for Comments 2459. 1041 1042 [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 1043 Specifications, October 1998. Request for Comments 2437. 1044 1045 [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME 1046 Version 2 Certificate Handling, March 1998. Request for 1047 Comments 2312. 1048 1049 [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access 1050 Protocol (v3), December 1997. Request for Comments 2251. 1051 1052 [16] ITU-T (formerly CCITT) Information Processing Systems - Open 1053 Systems Interconnection - Specification of Abstract Syntax Notation 1054 One (ASN.1) Rec. X.680 ISO/IEC 8824-1 1055 1056 [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA 1057 Laboratories Technical Note, Version 1.4, Revised November 1, 1993. 1058 10598. Acknowledgements 1060 1061 Some of the ideas on which this proposal is based arose during 1062 discussions over several years between members of the SAAG, the IETF 1063 CAT working group, and the PSRG, regarding integration of Kerberos 1064 and SPX. Some ideas have also been drawn from the DASS system. 1065 These changes are by no means endorsed by these groups. This is an 1066 attempt to revive some of the goals of those groups, and this 1067 proposal approaches those goals primarily from the Kerberos 1068 perspective. Lastly, comments from groups working on similar ideas 1069 in DCE have been invaluable. 1070 10719. Expiration Date 1072 1073 This draft expires May 25, 2002. 1074 107510. Authors 1076 1077 Brian Tung 1078 Clifford Neuman 1079 USC Information Sciences Institute 1080 4676 Admiralty Way Suite 1001 1081 Marina del Rey CA 90292-6695 1082 Phone: +1 310 822 1511 1083 E-mail: {brian, bcn}@isi.edu 1084 1085 Matthew Hur 1086 Cisco Systems 1087 2901 Third Avenue 1088 Seattle WA 98121 1089 Phone: (206) 256-3197 1090 E-Mail: mhur@cisco.com 1091 1092 Ari Medvinsky 1093 Keen.com, Inc. 1094 150 Independence Drive 1095 Menlo Park CA 94025 1096 Phone: +1 650 289 3134 1097 E-mail: ari@keen.com 1098 1099 Sasha Medvinsky 1100 Motorola 1101 6450 Sequence Drive 1102 San Diego, CA 92121 1103 +1 858 404 2367 1104 E-mail: smedvinsky@gi.com 1105 1106 John Wray 1107 Iris Associates, Inc. 1108 5 Technology Park Dr. 1109 Westford, MA 01886 1110 E-mail: John_Wray@iris.com 1111 1112 Jonathan Trostle 1113 Cisco Systems 1114 170 W. Tasman Dr. 1115 San Jose, CA 95134 1116 E-mail: jtrostle@cisco.com 1117