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