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