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