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