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