1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman 3Updates: RFC 1510 ISI 4expires December 1, 1999 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 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 To learn the current status of any Internet-Draft, please check 39 the "1id-abstracts.txt" listing contained in the Internet-Drafts 40 Shadow Directories on ftp.ietf.org (US East Coast), 41 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 42 munnari.oz.au (Pacific Rim). 43 44 The distribution of this memo is unlimited. It is filed as 45 draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1, 46 1999. Please send comments to the authors. 47 481. Abstract 49 50 This document defines extensions (PKINIT) to the Kerberos protocol 51 specification (RFC 1510 [1]) to provide a method for using public 52 key cryptography during initial authentication. The methods 53 defined specify the ways in which preauthentication data fields and 54 error data fields in Kerberos messages are to be used to transport 55 public key data. 56 572. Introduction 58 59 The popularity of public key cryptography has produced a desire for 60 its support in Kerberos [2]. The advantages provided by public key 61 cryptography include simplified key management (from the Kerberos 62 perspective) and the ability to leverage existing and developing 63 public key certification infrastructures. 64 65 Public key cryptography can be integrated into Kerberos in a number 66 of ways. One is to associate a key pair with each realm, which can 67 then be used to facilitate cross-realm authentication; this is the 68 topic of another draft proposal. Another way is to allow users with 69 public key certificates to use them in initial authentication. This 70 is the concern of the current document. 71 72 PKINIT utilizes Diffie-Hellman keys in combination with digital 73 signature keys as the primary, required mechanism. It also allows 74 for the use of RSA keys. Note that PKINIT supports the use of 75 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 a request to the KDC as before, except that if that user 82 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 The PKINIT specification may also be used as a building block for 92 other specifications. PKCROSS [3] utilizes PKINIT for establishing 93 the inter-realm key and associated inter-realm policy to be applied 94 in issuing cross realm service tickets. As specified in [4], 95 anonymous Kerberos tickets can be issued by applying a NULL 96 signature in combination with Diffie-Hellman in the PKINIT exchange. 97 Additionally, the PKINIT specification may be used for direct peer 98 to peer authentication without contacting a central KDC. This 99 application of PKINIT is described in PKTAPP [5] and is based on 100 concepts introduced in [6, 7]. For direct client-to-server 101 authentication, the client uses PKINIT to authenticate to the end 102 server (instead of a central KDC), which then issues a ticket for 103 itself. This approach has an advantage over TLS [8] in that the 104 server does not need to save state (cache session keys). 105 Furthermore, an additional benefit is that Kerberos tickets can 106 facilitate delegation (see [9]). 107 1083. Proposed Extensions 109 110 This section describes extensions to RFC 1510 for supporting the 111 use of public key cryptography in the initial request for a ticket 112 granting ticket (TGT). 113 114 In summary, the following change to RFC 1510 is proposed: 115 116 * Users may authenticate using either a public key pair or a 117 conventional (symmetric) key. If public key cryptography is 118 used, public key data is transported in preauthentication 119 data fields to help establish identity. The user presents 120 a public key certificate and obtains an ordinary TGT that may 121 be used for subsequent authentication, with such 122 authentication using only conventional cryptography. 123 124 Section 3.1 provides definitions to help specify message formats. 125 Section 3.2 describes the extensions for the initial authentication 126 method. 127 1283.1. Definitions 129 130 The extensions involve new preauthentication fields; we introduce 131 the following preauthentication types: 132 133 PA-PK-AS-REQ 14 134 PA-PK-AS-REP 15 135 136 The extensions also involve new error types; we introduce the 137 following types: 138 139 KDC_ERR_CLIENT_NOT_TRUSTED 62 140 KDC_ERR_KDC_NOT_TRUSTED 63 141 KDC_ERR_INVALID_SIG 64 142 KDC_ERR_KEY_TOO_WEAK 65 143 KDC_ERR_CERTIFICATE_MISMATCH 66 144 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 145 KDC_ERR_INVALID_CERTIFICATE 71 146 KDC_ERR_REVOKED_CERTIFICATE 72 147 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 148 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 149 KDC_ERR_CLIENT_NAME_MISMATCH 75 150 KDC_ERR_KDC_NAME_MISMATCH 76 151 152 We utilize the following typed data for errors: 153 154 TD-PKINIT-CMS-CERTIFICATES 101 155 TD-KRB-PRINCIPAL 102 156 TD-KRB-REALM 103 157 TD-TRUSTED-CERTIFIERS 104 158 TD-CERTIFICATE-INDEX 105 159 160 We utilize the following encryption types (which map directly to 161 OIDs): 162 163 dsaWithSHA1-CmsOID 9 164 md5WithRSAEncryption-CmsOID 10 165 sha1WithRSAEncryption-CmsOID 11 166 rc2CBC-EnvOID 12 167 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 168 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 169 des-ede3-cbc-Env-OID 15 170 171 These mappings are provided so that a client may send the 172 appropriate enctypes in the AS-REQ message in order to indicate 173 support for the corresponding OIDs (for performing PKINIT). 174 175 In many cases, PKINIT requires the encoding of an X.500 name as a 176 Realm. In these cases, the realm will be represented using a 177 different style, specified in RFC 1510 with the following example: 178 179 NAMETYPE:rest/of.name=without-restrictions 180 181 For a realm derived from an X.500 name, NAMETYPE will have the value 182 X500-RFC2253. The full realm name will appear as follows: 183 184 X500-RFC2253:RFC2253Encode(DistinguishedName) 185 186 where DistinguishedName is an X.500 name, and RFC2253Encode is a 187 readable UTF encoding of an X.500 name, as defined by 188 RFC 2253 [14] (part of LDAPv3). 189 190 To ensure that this encoding is unique, we add the following rule 191 to those specified by RFC 2253: 192 193 The order in which the attributes appear in the RFC 2253 194 encoding must be the reverse of the order in the ASN.1 195 encoding of the X.500 name that appears in the public key 196 certificate. The order of the relative distinguished names 197 (RDNs), as well as the order of the AttributeTypeAndValues 198 within each RDN, will be reversed. (This is despite the fact 199 that an RDN is defined as a SET of AttributeTypeAndValues, where 200 an order is normally not important.) 201 202 Similarly, PKINIT may require the encoding of an X.500 name as a 203 PrincipalName. In these cases, the name-type of the principal name 204 shall be set to KRB_NT-X500-PRINCIPAL. This new name type is 205 defined as: 206 207 KRB_NT_X500_PRINCIPAL 6 208 209 The name-string shall be set as follows: 210 211 RFC2253Encode(DistinguishedName) 212 213 as described above. 214 215 RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: 216 217 PrincipalName ::= SEQUENCE { 218 name-type[0] INTEGER, 219 name-string[1] SEQUENCE OF GeneralString 220 } 221 222 For the purposes of encoding an X.500 name within this structure, 223 the name-string shall be encoded as a single GeneralString. 224 225 Note that name mapping may be required or optional based on 226 policy. 227 2283.1.1. Encryption and Key Formats 229 230 In the exposition below, we use the terms public key and private 231 key generically. It should be understood that the term "public 232 key" may be used to refer to either a public encryption key or a 233 signature verification key, and that the term "private key" may be 234 used to refer to either a private decryption key or a signature 235 generation key. The fact that these are logically distinct does 236 not preclude the assignment of bitwise identical keys. 237 238 In the case of Diffie-Hellman, the key shall be produced from the 239 agreed bit string as follows: 240 241 * Truncate the bit string to the appropriate length. 242 * Rectify parity in each byte (if necessary) to obtain the key. 243 244 For instance, in the case of a DES key, we take the first eight 245 bytes of the bit stream, and then adjust the least significant bit 246 of each byte to ensure that each byte has odd parity. 247 2483.1.2. Algorithm Identifiers 249 250 PKINIT does not define, but does permit, the algorithm identifiers 251 listed below. 252 2533.1.2.1. Signature Algorithm Identifiers 254 255 The following signature algorithm identifiers specified in [11] and 256 in [15] shall be used with PKINIT: 257 258 id-dsa-with-sha1 (DSA with SHA1) 259 md5WithRSAEncryption (RSA with MD5) 260 sha-1WithRSAEncryption (RSA with SHA1) 261 2623.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 263 264 The following algorithm identifier shall be used within the 265 SubjectPublicKeyInfo data structure: dhpublicnumber 266 267 This identifier and the associated algorithm parameters are 268 specified in RFC 2459 [15]. 269 2703.1.2.3. Algorithm Identifiers for RSA Encryption 271 272 These algorithm identifiers are used inside the EnvelopedData data 273 structure, for encrypting the temporary key with a public key: 274 275 rsaEncryption (RSA encryption, PKCS#1 v1.5) 276 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) 277 278 Both of the above RSA encryption schemes are specified in [16]. 279 Currently, only PKCS#1 v1.5 is specified by CMS [11], although the 280 CMS specification says that it will likely include PKCS#1 v2.0 in 281 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext 282 vulnerability discovered in PKCS#1 v1.5.) 283 2843.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 285 286 These algorithm identifiers are used inside the EnvelopedData data 287 structure in the PKINIT Reply, for encrypting the reply key with the 288 temporary key: 289 des-ede3-cbc (3-key 3-DES, CBC mode) 290 rc2-cbc (RC2, CBC mode) 291 292 The full definition of the above algorithm identifiers and their 293 corresponding parameters (an IV for block chaining) is provided in 294 the CMS specification [11]. 295 2963.2. Public Key Authentication 297 298 Implementation of the changes in this section is REQUIRED for 299 compliance with PKINIT. 300 301 It is assumed that all public keys are signed by some certification 302 authority (CA). The initial authentication request is sent as per 303 RFC 1510, except that a preauthentication field containing data 304 signed by the user's private key accompanies the request: 305 306 PA-PK-AS-REQ ::= SEQUENCE { 307 -- PA TYPE 14 308 signedAuthPack [0] SignedData 309 -- defined in CMS [11] 310 -- AuthPack (below) defines the data 311 -- that is signed 312 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, 313 -- CAs that the client trusts 314 kdcCert [2] IssuerAndSerialNumber OPTIONAL 315 -- as defined in CMS [11] 316 -- specifies a particular KDC 317 -- certificate if the client 318 -- already has it; 319 -- must be accompanied by 320 -- a single trustedCertifier 321 encryptionCert [3] IssuerAndSerialNumber OPTIONAL 322 -- For example, this may be the 323 -- client's Diffie-Hellman 324 -- certificate, or it may be the 325 -- client's RSA encryption 326 -- certificate. 327 } 328 329 TrustedCas ::= CHOICE { 330 principalName [0] KerberosName, 331 -- as defined below 332 caName [1] Name 333 -- fully qualified X.500 name 334 -- as defined by X.509 335 issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL 336 -- Since a CA may have a number of 337 -- certificates, only one of which 338 -- a client trusts 339 } 340 341 Usage of SignedData: 342 The SignedData data type is specified in the Cryptographic 343 Message Syntax, a product of the S/MIME working group of the IETF. 344 - The encapContentInfo field must contain the PKAuthenticator 345 and, optionally, the client's Diffie Hellman public value. 346 - The eContentType field shall contain the OID value for 347 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 348 pkcs(1) pkcs7(7) data(1) 349 - The eContent field is data of the type AuthPack (below). 350 - The signerInfos field contains the signature of AuthPack. 351 - The Certificates field, when non-empty, contains the client's 352 certificate chain. If present, the KDC uses the public key from 353 the client's certificate to verify the signature in the request. 354 Note that the client may pass different certificates that are used 355 for signing or for encrypting. Thus, the KDC may utilize a 356 different client certificate for signature verification than the 357 one it uses to encrypt the reply to the client. For example, the 358 client may place a Diffie-Hellman certificate in this field in 359 order to convey its static Diffie Hellman certificate to the KDC 360 enable static-ephemeral Diffie-Hellman mode for the reply. As 361 another example, the client may place an RSA encryption 362 certificate in this field. 363 364 AuthPack ::= SEQUENCE { 365 pkAuthenticator [0] PKAuthenticator, 366 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 367 -- if client is using Diffie-Hellman 368 } 369 370 PKAuthenticator ::= SEQUENCE { 371 kdcName [0] PrincipalName, 372 kdcRealm [1] Realm, 373 cusec [2] INTEGER, 374 -- for replay prevention 375 ctime [3] KerberosTime, 376 -- for replay prevention 377 nonce [4] INTEGER 378 } 379 380 SubjectPublicKeyInfo ::= SEQUENCE { 381 algorithm AlgorithmIdentifier, 382 -- dhKeyAgreement 383 subjectPublicKey BIT STRING 384 -- for DH, equals 385 -- public exponent (INTEGER encoded 386 -- as payload of BIT STRING) 387 } -- as specified by the X.509 recommendation [10] 388 389 AlgorithmIdentifier ::= SEQUENCE { 390 algorithm ALGORITHM.&id, 391 parameters ALGORITHM.&type 392 } -- as specified by the X.509 recommendation [10] 393 394 If the client passes an issuer and serial number in the request, 395 the KDC is requested to use the referred-to certificate. If none 396 exists, then the KDC returns an error of type 397 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 398 other hand, the client does not pass any trustedCertifiers, 399 believing that it has the KDC's certificate, but the KDC has more 400 than one certificate. The KDC should include information in the 401 KRB-ERROR message that indicates the KDC certificate(s) that a 402 client may utilize. This data is specified in the e-data, which 403 is defined in RFC 1510 revisions as a SEQUENCE of TypedData: 404 405 TypedData ::= SEQUENCE { 406 data-type [0] INTEGER, 407 data-value [1] OCTET STRING, 408 } -- per Kerberos RFC 1510 revisions 409 410 where: 411 data-type = TD-PKINIT-CMS-CERTIFICATES = 101 412 data-value = CertificateSet // as specified by CMS [11] 413 414 The PKAuthenticator carries information to foil replay attacks, 415 to bind the request and response. The PKAuthenticator is signed 416 with the private key corresponding to the public key in the 417 certificate found in userCert (or cached by the KDC). 418 419 The trustedCertifiers field contains a list of certification 420 authorities trusted by the client, in the case that the client does 421 not possess the KDC's public key certificate. If the KDC has no 422 certificate signed by any of the trustedCertifiers, then it returns 423 an error of type KDC_ERR_KDC_NOT_TRUSTED. 424 425 KDCs should try to (in order of preference): 426 1. Use the KDC certificate identified by the serialNumber included 427 in the client's request. 428 2. Use a certificate issued to the KDC by the client's CA (if in the 429 middle of a CA key roll-over, use the KDC cert issued under same 430 CA key as user cert used to verify request). 431 3. Use a certificate issued to the KDC by one of the client's 432 trustedCertifier(s); 433 If the KDC is unable to comply with any of these options, then the 434 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 435 client. 436 437 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 438 type, the KDC attempts to verify the user's certificate chain 439 (userCert), if one is provided in the request. This is done by 440 verifying the certification path against the KDC's policy of 441 legitimate certifiers. This may be based on a certification 442 hierarchy, or it may be simply a list of recognized certifiers in a 443 system like PGP. 444 445 If the client's certificate chain contains no certificate signed by 446 a CA trusted by the KDC, then the KDC sends back an error message 447 of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data 448 is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) 449 whose data-value is an OCTET STRING which is the DER encoding of 450 451 TrustedCertifiers ::= SEQUENCE OF PrincipalName 452 -- X.500 name encoded as a principal name 453 -- see Section 3.1 454 455 If the signature on one of the certificates in the client's chain 456 fails verification, then the KDC returns an error of type 457 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE 458 of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose 459 data-value is an OCTET STRING which is the DER encoding of 460 461 CertificateIndex ::= INTEGER 462 -- 0 = 1st certificate, 463 -- (in order of encoding) 464 -- 1 = 2nd certificate, etc 465 466 The KDC may also check whether any of the certificates in the 467 client's chain has been revoked. If one of the certificates has 468 been revoked, then the KDC returns an error of type 469 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the 470 certificate's revocation status is unknown, the KDC returns an 471 error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation 472 status is unavailable, the KDC returns an error of type 473 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three 474 cases, the affected certificate is identified by the accompanying 475 e-data, which contains a CertificateIndex as described for 476 KDC_ERR_INVALID_CERTIFICATE. 477 478 If the certificate chain can be verified, but the name of the 479 client in the certificate does not match the client's name in the 480 request, then the KDC returns an error of type 481 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 482 field in this case. 483 484 Finally, if the certificate chain is verified, but the KDC's name 485 or realm as given in the PKAuthenticator does not match the KDC's 486 actual principal name, then the KDC returns an error of type 487 KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again 488 a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or 489 TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET 490 STRING whose data-value is the DER encoding of a PrincipalName or 491 Realm as defined in RFC 1510 revisions. 492 493 Even if all succeeds, the KDC may--for policy reasons--decide not 494 to trust the client. In this case, the KDC returns an error message 495 of type KDC_ERR_CLIENT_NOT_TRUSTED. 496 497 If a trust relationship exists, the KDC then verifies the client's 498 signature on AuthPack. If that fails, the KDC returns an error 499 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 500 timestamp (ctime and cusec) in the PKAuthenticator to assure that 501 the request is not a replay. The KDC also verifies that its name 502 is specified in the PKAuthenticator. 503 504 If the clientPublicValue field is filled in, indicating that the 505 client wishes to use Diffie-Hellman key agreement, then the KDC 506 checks to see that the parameters satisfy its policy. If they do 507 not (e.g., the prime size is insufficient for the expected 508 encryption type), then the KDC sends back an error message of type 509 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 510 private values for the response. 511 512 The KDC also checks that the timestamp in the PKAuthenticator is 513 within the allowable window and that the principal name and realm 514 are correct. If the local (server) time and the client time in the 515 authenticator differ by more than the allowable clock skew, then the 516 KDC returns an error message of type KRB_AP_ERR_SKEW. 517 518 Assuming no errors, the KDC replies as per RFC 1510, except as 519 follows. The user's name in the ticket is determined by the 520 following decision algorithm: 521 522 1. If the KDC has a mapping from the name in the certificate 523 to a Kerberos name, then use that name. 524 Else 525 2. If the certificate contains a Kerberos name in an extension 526 field, and local KDC policy allows, then use that name. 527 Else 528 3. Use the name as represented in the certificate, mapping 529 as necessary (e.g., as per RFC 2253 for X.500 names). In 530 this case the realm in the ticket shall be the name of the 531 certification authority that issued the user's certificate. 532 533 The KDC encrypts the reply not with the user's long-term key, but 534 with a random key generated only for this particular response. This 535 random key is sealed in the preauthentication field: 536 537 PA-PK-AS-REP ::= CHOICE { 538 -- PA TYPE 15 539 dhSignedData [0] SignedData, 540 -- Defined in CMS and used only with 541 -- Diffie-Helman key exchange 542 -- This choice MUST be supported 543 -- by compliant implementations. 544 encKeyPack [1] EnvelopedData, 545 -- Defined in CMS 546 -- The temporary key is encrypted 547 -- using the client public key 548 -- key 549 -- SignedReplyKeyPack, encrypted 550 -- with the temporary key, is also 551 -- included. 552 } 553 554 Usage of SignedData: 555 If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP 556 provides authenticated Diffie-Hellman parameters of the KDC. The 557 reply key used to encrypt part of the KDC reply message is derived 558 from the Diffie-Hellman exchange: 559 - Both the KDC and the client calculate a secret value (g^ab mod p), 560 where a is the client's private exponent and b is the KDC's 561 private exponent. 562 - Both the KDC and the client take the first N bits of this secret 563 value and convert it into a reply key. N depends on the reply key 564 type. 565 - If the reply key is DES, N=64 bits, where some of the bits are 566 replaced with parity bits, according to FIPS PUB 74. 567 - If the reply key is (3-key) 3-DES, N=192 bits, where some of the 568 bits are replaced with parity bits, according to FIPS PUB 74. 569 - The encapContentInfo field must contain the KdcDHKeyInfo as 570 defined below. 571 - The eContentType field shall contain the OID value for 572 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 573 pkcs(1) pkcs7(7) data(1) 574 - The certificates field must contain the certificates necessary 575 for the client to establish trust in the KDC's certificate 576 based on the list of trusted certifiers sent by the client in 577 the PA-PK-AS-REQ. This field may be empty if the client did 578 not send to the KDC a list of trusted certifiers (the 579 trustedCertifiers field was empty, meaning that the client 580 already possesses the KDC's certificate). 581 - The signerInfos field is a SET that must contain at least one 582 member, since it contains the actual signature. 583 584 Usage of EnvelopedData: 585 The EnvelopedData data type is specified in the Cryptographic 586 Message Syntax, a product of the S/MIME working group of the IETF. 587 It contains an temporary key encrypted with the PKINIT 588 client's public key. It also contains a signed and encrypted 589 reply key. 590 - The originatorInfo field is not required, since that information 591 may be presented in the signedData structure that is encrypted 592 within the encryptedContentInfo field. 593 - The optional unprotectedAttrs field is not required for PKINIT. 594 - The recipientInfos field is a SET which must contain exactly one 595 member of the KeyTransRecipientInfo type for encryption 596 with an RSA public key. 597 - The encryptedKey field (in KeyTransRecipientInfo) contains 598 the temporary key which is encrypted with the PKINIT client's 599 public key. 600 - The encryptedContentInfo field contains the signed and encrypted 601 reply key. 602 - The contentType field shall contain the OID value for 603 id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) 604 pkcs(1) pkcs7(7) signedData(2) 605 - The encryptedContent field is encrypted data of the CMS type 606 signedData as specified below. 607 - The encapContentInfo field must contains the ReplyKeyPack. 608 - The eContentType field shall contain the OID value for 609 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 610 pkcs(1) pkcs7(7) data(1) 611 - The eContent field is data of the type ReplyKeyPack (below). 612 - The certificates field must contain the certificates necessary 613 for the client to establish trust in the KDC's certificate 614 based on the list of trusted certifiers sent by the client in 615 the PA-PK-AS-REQ. This field may be empty if the client did 616 not send to the KDC a list of trusted certifiers (the 617 trustedCertifiers field was empty, meaning that the client 618 already possesses the KDC's certificate). 619 - The signerInfos field is a SET that must contain at least one 620 member, since it contains the actual signature. 621 622 KdcDHKeyInfo ::= SEQUENCE { 623 -- used only when utilizing Diffie-Hellman 624 nonce [0] INTEGER, 625 -- binds responce to the request 626 subjectPublicKey [2] BIT STRING 627 -- Equals public exponent (g^a mod p) 628 -- INTEGER encoded as payload of 629 -- BIT STRING 630 } 631 632 ReplyKeyPack ::= SEQUENCE { 633 -- not used for Diffie-Hellman 634 replyKey [0] EncryptionKey, 635 -- used to encrypt main reply 636 -- ENCTYPE is at least as strong as 637 -- ENCTYPE of session key 638 nonce [1] INTEGER, 639 -- binds response to the request 640 -- must be same as the nonce 641 -- passed in the PKAuthenticator 642 } 643 644 645 Since each certifier in the certification path of a user's 646 certificate is essentially a separate realm, the name of each 647 certifier must be added to the transited field of the ticket. The 648 format of these realm names is defined in Section 3.1 of this 649 document. If applicable, the transit-policy-checked flag should be 650 set in the issued ticket. 651 652 The KDC's certificate must bind the public key to a name derivable 653 from the name of the realm for that KDC. X.509 certificates shall 654 contain the principal name of the KDC as the SubjectAltName version 655 3 extension. Below is the definition of this version 3 extension, as 656 specified by the X.509 standard: 657 658 subjectAltName EXTENSION ::= { 659 SYNTAX GeneralNames 660 IDENTIFIED BY id-ce-subjectAltName 661 } 662 663 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 664 665 GeneralName ::= CHOICE { 666 otherName [0] INSTANCE OF OTHER-NAME, 667 ... 668 } 669 670 OTHER-NAME ::= TYPE-IDENTIFIER 671 672 In this definition, otherName is a name of any form defined as an 673 instance of the OTHER-NAME information object class. For the purpose 674 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 675 be chosen and replaced by the type KerberosName: 676 677 KerberosName ::= SEQUENCE { 678 realm [0] Realm, 679 -- as define in RFC 1510 680 principalName [1] PrincipalName, 681 -- as define in RFC 1510 682 } 683 684 This specific syntax is identified within subjectAltName by setting 685 the OID id-ce-subjectAltName to krb5PrincipalName, where (from the 686 Kerberos specification) we have 687 688 krb5 OBJECT IDENTIFIER ::= { iso (1) 689 org (3) 690 dod (6) 691 internet (1) 692 security (5) 693 kerberosv5 (2) } 694 695 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 696 697 This specification may also be used to specify a Kerberos name 698 within the user's certificate. 699 700 If a non-KDC X.509 certificate contains the principal name within 701 the subjectAltName version 3 extension , that name may utilize 702 KerberosName as defined below, or, in the case of an S/MIME 703 certificate [17], may utilize the email address. If the KDC 704 is presented with as S/MIME certificate, then the email address 705 within subjectAltName will be interpreted as a principal and realm 706 separated by the "@" sign, or as a name that needs to be 707 canonicalized. If the resulting name does not correspond to a 708 registered principal name, then the principal name is formed as 709 defined in section 3.1. 710 711 The client then extracts the random key used to encrypt the main 712 reply. This random key (in encPaReply) is encrypted with either the 713 client's public key or with a key derived from the DH values 714 exchanged between the client and the KDC. 715 7163.2.2. Required Algorithms 717 718 Not all of the algorithms in the PKINIT protocol specification have 719 to be implemented in order to comply with the proposed standard. 720 Below is a list of the required algorithms: 721 722 - Diffie-Hellman public/private key pairs 723 - utilizing Diffie-Hellman ephemeral-ephemeral mode 724 - SHA1 digest and DSA for signatures 725 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 726 - 3-key triple DES Temporary and Reply keys 727 7284. Logistics and Policy 729 730 This section describes a way to define the policy on the use of 731 PKINIT for each principal and request. 732 733 The KDC is not required to contain a database record for users 734 who use public key authentication. However, if these users are 735 registered with the KDC, it is recommended that the database record 736 for these users be modified to an additional flag in the attributes 737 field to indicate that the user should authenticate using PKINIT. 738 If this flag is set and a request message does not contain the 739 PKINIT preauthentication field, then the KDC sends back as error of 740 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication 741 field of type PA-PK-AS-REQ must be included in the request. 742 7435. Security Considerations 744 745 PKINIT raises a few security considerations, which we will address 746 in this section. 747 748 First of all, PKINIT introduces a new trust model, where KDCs do not 749 (necessarily) certify the identity of those for whom they issue 750 tickets. PKINIT does allow KDCs to act as their own CAs, in order 751 to simplify key management, but one of the additional benefits is to 752 align Kerberos authentication with a global public key 753 infrastructure. Anyone using PKINIT in this way must be aware of 754 how the certification infrastructure they are linking to works. 755 756 Secondly, PKINIT also introduces the possibility of interactions 757 between different cryptosystems, which may be of widely varying 758 strengths. Many systems, for instance, allow the use of 512-bit 759 public keys. Using such keys to wrap data encrypted under strong 760 conventional cryptosystems, such as triple-DES, is inappropriate; 761 it adds a weak link to a strong one at extra cost. Implementors 762 and administrators should take care to avoid such wasteful and 763 deceptive interactions. 764 765 Lastly, PKINIT calls for randomly generated keys for conventional 766 cryptosystems. Many such systems contain systematically "weak" 767 keys. PKINIT implementations MUST avoid use of these keys, either 768 by discarding those keys when they are generated, or by fixing them 769 in some way (e.g., by XORing them with a given mask). These 770 precautions vary from system to system; it is not our intention to 771 give an explicit recipe for them here. 772 7736. Transport Issues 774 775 Certificate chains can potentially grow quite large and span several 776 UDP packets; this in turn increases the probability that a Kerberos 777 message involving PKINIT extensions will be broken in transit. In 778 light of the possibility that the Kerberos specification will 779 require KDCs to accept requests using TCP as a transport mechanism, 780 we make the same recommendation with respect to the PKINIT 781 extensions as well. 782 7837. Bibliography 784 785 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 786 (V5). Request for Comments 1510. 787 788 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 789 for Computer Networks, IEEE Communications, 32(9):33-38. September 790 1994. 791 792 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 793 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 794 Authentication in Kerberos. 795 draft-ietf-cat-kerberos-pk-cross-04.txt 796 797 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 798 Kerberos. 799 draft-ietf-cat-kerberos-anoncred-00.txt 800 801 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 802 Tickets for Application Servers (PKTAPP). 803 draft-ietf-cat-pktapp-00.txt 804 805 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 806 Using Public Key Cryptography. Symposium On Network and Distributed 807 System Security, 1997. 808 809 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 810 Protocol. In Proceedings of the USENIX Workshop on Electronic 811 Commerce, July 1995. 812 813 [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 814 Request for Comments 2246, January 1999. 815 816 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 817 Distributed Systems. In Proceedings of the 13th International 818 Conference on Distributed Computing Systems, May 1993. 819 820 [10] ITU-T (formerly CCITT) Information technology - Open Systems 821 Interconnection - The Directory: Authentication Framework 822 Recommendation X.509 ISO/IEC 9594-8 823 824 [11] R. Housley. Cryptographic Message Syntax. 825 draft-ietf-smime-cms-13.txt, April 1999. 826 827 [12] PKCS #7: Cryptographic Message Syntax Standard, 828 An RSA Laboratories Technical Note Version 1.5 829 Revised November 1, 1993 830 831 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data 832 Security, Inc. A Description of the RC2(r) Encryption Algorithm 833 March 1998. 834 Request for Comments 2268. 835 836 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 837 Protocol (v3): UTF-8 String Representation of Distinguished Names. 838 Request for Comments 2253. 839 840 [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 841 Key Infrastructure, Certificate and CRL Profile, January 1999. 842 Request for Comments 2459. 843 844 [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 845 Specifications, October 1998. 846 Request for Comments 2437. 847 848 [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. 849 S/MIME Version 2 Certificate Handling, March 1998. 850 Request for Comments 2312 851 8528. Acknowledgements 853 854 Some of the ideas on which this proposal is based arose during 855 discussions over several years between members of the SAAG, the IETF 856 CAT working group, and the PSRG, regarding integration of Kerberos 857 and SPX. Some ideas have also been drawn from the DASS system. 858 These changes are by no means endorsed by these groups. This is an 859 attempt to revive some of the goals of those groups, and this 860 proposal approaches those goals primarily from the Kerberos 861 perspective. Lastly, comments from groups working on similar ideas 862 in DCE have been invaluable. 863 8649. Expiration Date 865 866 This draft expires December 1, 1999. 867 86810. Authors 869 870 Brian Tung 871 Clifford Neuman 872 USC Information Sciences Institute 873 4676 Admiralty Way Suite 1001 874 Marina del Rey CA 90292-6695 875 Phone: +1 310 822 1511 876 E-mail: {brian, bcn}@isi.edu 877 878 Matthew Hur 879 CyberSafe Corporation 880 1605 NW Sammamish Road 881 Issaquah WA 98027-5378 882 Phone: +1 425 391 6000 883 E-mail: matt.hur@cybersafe.com 884 885 Ari Medvinsky 886 Excite 887 555 Broadway 888 Redwood City, CA 94063 889 Phone +1 650 569 2119 890 E-mail: amedvins@excitecorp.com 891 892 Sasha Medvinsky 893 General Instrument 894 6450 Sequence Drive 895 San Diego, CA 92121 896 Phone +1 619 404 2825 897 E-mail: smedvinsky@gi.com 898 899 John Wray 900 Iris Associates, Inc. 901 5 Technology Park Dr. 902 Westford, MA 01886 903 E-mail: John_Wray@iris.com 904 905 Jonathan Trostle 906 170 W. Tasman Dr. 907 San Jose, CA 95134 908 E-mail: jtrostle@cisco.com 909