1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-08.txt Clifford Neuman 3Updates: RFC 1510 ISI 4expires November 12, 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 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-09.txt, and expires November 12, 45 1999. 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 Diffie-Hellman keys in combination with digital 72 signature keys as the primary, required mechanism. It also allows 73 for the use of RSA keys. Note that PKINIT supports the use of 74 separate signature and encryption keys. 75 76 PKINIT enables access to Kerberos-secured services based on initial 77 authentication utilizing public key cryptography. PKINIT utilizes 78 standard public key signature and encryption data formats within the 79 standard Kerberos messages. The basic mechanism is as follows: The 80 user sends a request to the KDC as before, except that if that user 81 is to use public key cryptography in the initial authentication 82 step, his certificate and a signature accompany the initial request 83 in the preauthentication fields. Upon receipt of this request, the 84 KDC verifies the certificate and issues a ticket granting ticket 85 (TGT) as before, except that the encPart from the AS-REP message 86 carrying the TGT is now encrypted utilizing either a Diffie-Hellman 87 derived key or the user's public key. This message is authenticated 88 utilizing the public key signature of the KDC. 89 90 The PKINIT specification may also be used as a building block for 91 other specifications. PKCROSS [3] utilizes PKINIT for establishing 92 the inter-realm key and associated inter-realm policy to be applied 93 in issuing cross realm service tickets. As specified in [4], 94 anonymous Kerberos tickets can be issued by applying a NULL 95 signature in combination with Diffie-Hellman in the PKINIT exchange. 96 Additionally, the PKINIT specification may be used for direct peer 97 to peer authentication without contacting a central KDC. This 98 application of PKINIT is described in PKTAPP [5] and is based on 99 concepts introduced in [6, 7]. For direct client-to-server 100 authentication, the client uses PKINIT to authenticate to the end 101 server (instead of a central KDC), which then issues a ticket for 102 itself. This approach has an advantage over TLS [8] in that the 103 server does not need to save state (cache session keys). 104 Furthermore, an additional benefit is that Kerberos tickets can 105 facilitate delegation (see [9]). 106 1073. Proposed Extensions 108 109 This section describes extensions to RFC 1510 for supporting the 110 use of public key cryptography in the initial request for a ticket 111 granting ticket (TGT). 112 113 In summary, the following change to RFC 1510 is proposed: 114 115 * Users may authenticate using either a public key pair or a 116 conventional (symmetric) key. If public key cryptography is 117 used, public key data is transported in preauthentication 118 data fields to help establish identity. The user presents 119 a public key certificate and obtains an ordinary TGT that may 120 be used for subsequent authentication, with such 121 authentication using only conventional cryptography. 122 123 Section 3.1 provides definitions to help specify message formats. 124 Section 3.2 describes the extensions for the initial authentication 125 method. 126 1273.1. Definitions 128 129 The extensions involve new preauthentication fields; we introduce 130 the following preauthentication types: 131 132 PA-PK-AS-REQ 14 133 PA-PK-AS-REP 15 134 PA-PK-KEY-REQ 18 135 PA-PK-KEY-REP 19 136 137 The extensions also involve new error types; we introduce the 138 following types: 139 140 KDC_ERR_CLIENT_NOT_TRUSTED 62 141 KDC_ERR_KDC_NOT_TRUSTED 63 142 KDC_ERR_INVALID_SIG 64 143 KDC_ERR_KEY_TOO_WEAK 65 144 KDC_ERR_CERTIFICATE_MISMATCH 66 145 146 We utilize the following typed data for errors: 147 148 ETD-PKINIT-CMS-CERTIFICATES 101 149 ETD-KRB-PRINCIPAL 102 150 ETD-KRB-REALM 103 151 152 We utilize the following encryption types (which map directly to 153 OIDs): 154 sha1WithRSAEncryption-CmsOID 8 155 dsaWithSHA1-CmsOID 9 156 md4WithRsaEncryption-CmsOID 10 157 md5WithRSAEncryption-CmsOID 11 158 rc2CBC-EnvOID 12 159 rc4-EnvOID 13 160 161 In many cases, PKINIT requires the encoding of an X.500 name as a 162 Realm. In these cases, the realm will be represented using a 163 different style, specified in RFC 1510 with the following example: 164 165 NAMETYPE:rest/of.name=without-restrictions 166 167 For a realm derived from an X.500 name, NAMETYPE will have the value 168 X500-RFC2253. The full realm name will appear as follows: 169 170 X500-RFC2253:RFC2253Encode(DistinguishedName) 171 172 where DistinguishedName is an X.500 name, and RFC2253Encode is a 173 readable ASCII encoding of an X.500 name, as defined by 174 RFC 2253 [14] (part of LDAPv3). 175 176 To ensure that this encoding is unique, we add the following rule 177 to those specified by RFC 2253: 178 179 The order in which the attributes appear in the RFC 2253 180 encoding must be the reverse of the order in the ASN.1 181 encoding of the X.500 name that appears in the public key 182 certificate. The order of the relative distinguished names 183 (RDNs), as well as the order of the AttributeTypeAndValues 184 within each RDN, will be reversed. (This is despite the fact 185 that an RDN is defined as a SET of AttributeTypeAndValues, where 186 an order is normally not important.) 187 188 Similarly, PKINIT may require the encoding of an X.500 name as a 189 PrincipalName. In these cases, the name-type of the principal name 190 shall be set to KRB_NT-X500-PRINCIPAL. This new name type is 191 defined as: 192 193 KRB_NT_X500_PRINCIPAL 6 194 195 The name-string shall be set as follows: 196 197 RFC2253Encode(DistinguishedName) 198 199 as described above. 200 201 Note that name mapping may be required or optional based on policy. 202 2033.1.1. Encryption and Key Formats 204 205 In the exposition below, we use the terms public key and private 206 key generically. It should be understood that the term "public 207 key" may be used to refer to either a public encryption key or a 208 signature verification key, and that the term "private key" may be 209 used to refer to either a private decryption key or a signature 210 generation key. The fact that these are logically distinct does 211 not preclude the assignment of bitwise identical keys. 212 213 In the case of Diffie-Hellman, the key shall be produced from the 214 agreed bit string as follows: 215 216 * Truncate the bit string to the appropriate length. 217 * Rectify parity in each byte (if necessary) to obtain the key. 218 219 For instance, in the case of a DES key, we take the first eight 220 bytes of the bit stream, and then adjust the least significant bit 221 of each byte to ensure that each byte has odd parity. 222 2233.1.2. Algorithm Identifiers 224 225 PKINIT does not define, but does permit, the algorithm identifiers 226 listed below. 227 2283.1.2.1. Signature Algorithm Identifiers 229 230 These are the algorithm identifiers for use in the Signature data 231 structure as specified in CMS [11]: 232 233 sha-1WithRSAEncryption ALGORITHM PARAMETER NULL 234 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 235 pkcs-1(1) 5 } 236 237 dsaWithSHA1 ALGORITHM PARAMETER NULL 238 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 239 oIWSecAlgorithm(2) dsaWithSHA1(27) } 240 241 md4WithRsaEncryption ALGORITHM PARAMETER NULL 242 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 243 oIWSecAlgorithm(2) md4WithRSAEncryption(4) } 244 245 md5WithRSAEncryption ALGORITHM PARAMETER NULL 246 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 247 pkcs-1(1) md5WithRSAEncryption(4) } 248 2493.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 250 251 This algorithm identifier is used inside the SubjectPublicKeyInfo 252 data structure: 253 254 dhKeyAgreement ALGORITHM PARAMETER DHParameters 255 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 256 pkcs-3(3) dhKeyAgreement(1) } 257 258 DHParameters ::= SEQUENCE { 259 prime INTEGER, 260 -- p 261 base INTEGER, 262 -- g 263 privateValueLength INTEGER OPTIONAL 264 } -- as specified by the X.509 recommendation [9] 265 2663.1.2.3. Algorithm Identifiers for RSA Encryption 267 268 These algorithm identifiers are used inside the EnvelopedData data 269 structure, for encrypting the temporary key with a public key: 270 271 id-RSAES-OAEP OBJECT IDENTIFIER 272 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 273 pkcs-1(1) 7 } 274 2753.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 276 277 These algorithm identifiers are used inside the EnvelopedData data 278 structure, for encrypting the temporary key with a Diffie-Hellman- 279 derived key, or for encrypting the reply key: 280 281 desCBC ALGORITHM PARAMETER IV8 282 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 283 oIWSecAlgorithm(2) desCBC(7) } 284 285 DES-EDE3-CBC ALGORITHM PARAMETER IV8 286 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 287 encryptionAlgorithm(3) desEDE3(7) } 288 289 IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector 290 291 rc2CBC ALGORITHM PARAMETER RC2-CBCParameter 292 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 293 encryptionAlgorithm(3) rc2CBC(2) } 294 295 The rc2CBC algorithm parameters (RC2-CBCParameter) are defined 296 in the following section. 297 298 rc4 ALGORITHM PARAMETER NULL 299 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 300 encryptionAlgorithm(3) rc4(4) } 301 302 The rc4 algorithm cannot be used with the Diffie-Hellman-derived 303 keys, because its parameters do not specify the size of the key. 304 3053.1.2.5. rc2CBC Algorithm Parameters 306 307 This definition of the RC2 parameters is taken from a paper by 308 Ron Rivest [13]. Refer to [13] for the complete description of the 309 RC2 algorithm. 310 311 RC2-CBCParameter ::= CHOICE { 312 iv IV, 313 params SEQUENCE { 314 version RC2Version, 315 iv IV 316 } 317 } 318 319 where 320 321 IV ::= OCTET STRING -- 8 octets 322 RC2Version ::= INTEGER -- 1-1024 323 324 RC2 in CBC mode has two parameters: an 8-byte initialization 325 vector (IV) and a version number in the range 1-1024 which 326 specifies in a roundabout manner the number of effective key bits 327 to be used for the RC2 encryption/decryption. 328 329 The correspondence between effective key bits and version number 330 is as follows: 331 332 1. If the number EKB of effective key bits is in the range 1-255, 333 then the version number is given by Table[EKB], where the 334 256-byte translation table is specified below. It specifies a 335 permutation on the numbers 0-255. 336 337 2. If the number EKB of effective key bits is in the range 338 256-1024, then the version number is simply EKB. 339 340 The default number of effective key bits for RC2 is 32. 341 If RC2-CBC is being performed with 32 effective key bits, the 342 parameters should be supplied as a simple IV, rather than as a 343 SEQUENCE containing a version and an IV. 344 345 0 1 2 3 4 5 6 7 8 9 a b c d e f 346 347 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 348 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a 349 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 350 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c 351 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 352 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa 353 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e 354 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf 355 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 356 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 357 a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c 358 b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 359 c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 360 d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 361 e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f 362 f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab 363 364 3653.2. Public Key Authentication 366 367 Implementation of the changes in this section is REQUIRED for 368 compliance with PKINIT. 369 370 It is assumed that all public keys are signed by some certification 371 authority (CA). The initial authentication request is sent as per 372 RFC 1510, except that a preauthentication field containing data 373 signed by the user's private key accompanies the request: 374 375 PA-PK-AS-REQ ::= SEQUENCE { 376 -- PA TYPE 14 377 signedAuthPack [0] SignedData 378 -- defined in CMS [11] 379 -- AuthPack (below) defines the data 380 -- that is signed 381 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 382 -- CAs that the client trusts 383 kdcCert [2] IssuerAndSerialNumber OPTIONAL 384 -- as defined in CMS [11] 385 -- specifies a particular KDC 386 -- certificate if the client 387 -- already has it; 388 -- must be accompanied by 389 -- a single trustedCertifier 390 } 391 392 Usage of SignedData: 393 The SignedData data type is specified in the Cryptographic 394 Message Syntax, a product of the S/MIME working group of the IETF. 395 - The encapContentInfo field must contain the PKAuthenticator 396 and, optionally, the client's Diffie Hellman public value. 397 - The eContentType field shall contain the OID value for 398 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 399 pkcs(1) pkcs7(7) data(1) 400 - The eContent field is data of the type AuthPack (below). 401 - The signerInfos field is a SET of SignerInfo that is required by 402 CMS; however, the set may contain zero elements. When non-empty, 403 this field contains the client's certificate chain. If present, 404 the KDC uses the public key from the client's certificate to 405 verify the signature in the request. Note that the client may 406 pass different certificates that are used for signing or for 407 encrypting. Thus, the KDC may utilize a different client 408 certificate for signature verification than the one it uses to 409 encrypt the reply to the client. 410 411 AuthPack ::= SEQUENCE { 412 pkAuthenticator [0] PKAuthenticator, 413 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 414 -- if client is using Diffie-Hellman 415 } 416 417 PKAuthenticator ::= SEQUENCE { 418 kdcName [0] PrincipalName, 419 kdcRealm [1] Realm, 420 cusec [2] INTEGER, 421 -- for replay prevention 422 ctime [3] KerberosTime, 423 -- for replay prevention 424 nonce [4] INTEGER 425 } 426 427 SubjectPublicKeyInfo ::= SEQUENCE { 428 algorithm AlgorithmIdentifier, 429 -- dhKeyAgreement 430 subjectPublicKey BIT STRING 431 -- for DH, equals 432 -- public exponent (INTEGER encoded 433 -- as payload of BIT STRING) 434 } -- as specified by the X.509 recommendation [9] 435 436 AlgorithmIdentifier ::= SEQUENCE { 437 algorithm ALGORITHM.&id, 438 parameters ALGORITHM.&type 439 } -- as specified by the X.509 recommendation [10] 440 441 If the client passes an issuer and serial number in the request, 442 the KDC is requested to use the referred-to certificate. If none 443 exists, then the KDC returns an error of type 444 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 445 other hand, the client does not pass any trustedCertifiers, 446 believing that it has the KDC's certificate, but the KDC has more 447 than one certificate. The KDC should include information in the 448 KRB-ERROR message that indicates the KDC certificate(s) that a 449 client may utilize. This data is specified in the e-typed-data 450 type as follows: 451 452 ETypedData ::= SEQUENCE { 453 e-data-type [1] INTEGER, 454 e-data-value [2] OCTET STRING, 455 } -- per Kerberos RFC 1510 revisions 456 457 where: 458 e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101 459 e-data-value = CertificateSet // as specified by CMS [11] 460 461 The PKAuthenticator carries information to foil replay attacks, 462 to bind the request and response. The PKAuthenticator is signed 463 with the private key corresponding to the public key in the 464 certificate found in userCert (or cached by the KDC). 465 466 The trustedCertifiers field contains a list of certification 467 authorities trusted by the client, in the case that the client does 468 not possess the KDC's public key certificate. If the KDC has no 469 certificate signed by any of the trustedCertifiers, then it returns 470 an error of type KDC_ERR_KDC_NOT_TRUSTED. 471 472 KDCs should try to (in order of preference): 473 1. Use the KDC certificate identified by the serialNumber included 474 in the client's request. 475 2. Use a certificate issued to the KDC by the client's CA (if in the 476 middle of a CA key roll-over, use the KDC cert issued under same 477 CA key as user cert used to verify request). 478 3. Use a certificate issued to the KDC by one of the client's 479 trustedCertifier(s); 480 If the KDC is unable to comply with any of these options, then the 481 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 482 client. 483 484 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 485 type, the KDC attempts to verify the user's certificate chain 486 (userCert), if one is provided in the request. This is done by 487 verifying the certification path against the KDC's policy of 488 legitimate certifiers. This may be based on a certification 489 hierarchy, or it may be simply a list of recognized certifiers in a 490 system like PGP. 491 492 If verification of the user's certificate fails, the KDC sends back 493 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 494 field contains additional information pertaining to this error, and 495 is formatted as follows: 496 497 METHOD-DATA ::= SEQUENCE { 498 method-type [0] INTEGER, 499 -- 0 = not specified 500 -- 1 = cannot verify public key 501 -- 2 = invalid certificate 502 -- 3 = revoked certificate 503 -- 4 = invalid KDC name 504 -- 5 = client name mismatch 505 method-data [1] OCTET STRING OPTIONAL 506 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 507 508 The values for the method-type and method-data fields are described 509 in Section 3.2.1. 510 511 If a trust relationship exists, the KDC then verifies the client's 512 signature on AuthPack. If that fails, the KDC returns an error 513 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 514 timestamp (ctime and cusec) in the PKAuthenticator to assure that 515 the request is not a replay. The KDC also verifies that its name 516 is specified in the PKAuthenticator. 517 518 If the clientPublicValue field is filled in, indicating that the 519 client wishes to use Diffie-Hellman key agreement, then the KDC 520 checks to see that the parameters satisfy its policy. If they do 521 not (e.g., the prime size is insufficient for the expected 522 encryption type), then the KDC sends back an error message of type 523 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 524 private values for the response. 525 526 The KDC also checks that the timestamp in the PKAuthenticator is 527 within the allowable window and that the principal name and realm 528 are correct. If the local (server) time and the client time in the 529 authenticator differ by more than the allowable clock skew, then the 530 KDC returns an error message of type KRB_AP_ERR_SKEW. If the 531 principal name or realm do not match the KDC, then the KDC returns 532 an error message of type KDC_ERR_NAME_MISMATCH for which the 533 e-typed-data may contain the correct name to use 534 (EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where 535 e-data-value = PrincipalName or Realm as defined by RFC 1510). 536 537 Assuming no errors, the KDC replies as per RFC 1510, except as 538 follows. The user's name in the ticket is determined by the 539 following decision algorithm: 540 541 1. If the KDC has a mapping from the name in the certificate 542 to a Kerberos name, then use that name. 543 Else 544 2. If the certificate contains a Kerberos name in an extension 545 field, and local KDC policy allows, then use that name. 546 Else 547 3. Use the name as represented in the certificate, mapping 548 as necessary (e.g., as per RFC 2253 for X.500 names). In 549 this case the realm in the ticket shall be the name of the 550 certification authority that issued the user's certificate. 551 552 The KDC encrypts the reply not with the user's long-term key, but 553 with a random key generated only for this particular response. This 554 random key is sealed in the preauthentication field: 555 556 PA-PK-AS-REP ::= CHOICE { 557 -- PA TYPE 15 558 dhSignedData [0] SignedData, 559 -- Defined in CMS and used only with 560 -- Diffie-Helman key exchange 561 encKeyPack [1] EnvelopedData, 562 -- Defined in CMS 563 -- The temporary key is encrypted 564 -- using the client public key 565 -- key 566 -- SignedReplyKeyPack, encrypted 567 -- with the temporary key, is also 568 -- included. 569 } 570 571 Usage of SignedData: 572 If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP 573 provides authenticated Diffie-Hellman parameters of the KDC. The 574 reply key used to encrypt part of the KDC reply message is derived 575 from the Diffie-Hellman exchange: 576 - Both the KDC and the client calculate a secret value (g^ab mod p), 577 where a is the client's private exponent and b is the KDC's 578 private exponent. 579 - Both the KDC and the client take the first N bits of this secret 580 value and convert it into a reply key. N depends on the reply key 581 type. 582 - If the reply key is DES, N=64 bits, where some of the bits are 583 replaced with parity bits, according to FIPS PUB 74. 584 - If the reply key is (3-key) 3-DES, N=192 bits, where some of the 585 bits are replaced with parity bits, according to FIPS PUB 74. 586 - The encapContentInfo field must contain the KdcDHKeyInfo as 587 defined below. 588 - The eContentType field shall contain the OID value for 589 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 590 pkcs(1) pkcs7(7) data(1) 591 - The certificates field must contain the certificates necessary 592 for the client to establish trust in the KDC's certificate 593 based on the list of trusted certifiers sent by the client in 594 the PA-PK-AS-REQ. This field may be empty if the client did 595 not send to the KDC a list of trusted certifiers (the 596 trustedCertifiers field was empty, meaning that the client 597 already possesses the KDC's certificate). 598 - The signerInfos field is a SET that must contain at least one 599 member, since it contains the actual signature. 600 601 Usage of EnvelopedData: 602 The EnvelopedData data type is specified in the Cryptographic 603 Message Syntax, a product of the S/MIME working group of the IETF. 604 It contains an temporary key encrypted with the PKINIT 605 client's public key. It also contains a signed and encrypted 606 reply key. 607 - The originatorInfo field is not required, since that information 608 may be presented in the signedData structure that is encrypted 609 within the encryptedContentInfo field. 610 - The optional unprotectedAttrs field is not required for PKINIT. 611 - The recipientInfos field is a SET which must contain exactly one 612 member of the KeyTransRecipientInfo type for encryption 613 with an RSA public key. 614 - The encryptedKey field (in KeyTransRecipientInfo) contains 615 the temporary key which is encrypted with the PKINIT client's 616 public key. 617 - The encryptedContentInfo field contains the signed and encrypted 618 reply key. 619 - The contentType field shall contain the OID value for 620 id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) 621 pkcs(1) pkcs7(7) signedData(2) 622 - The encryptedContent field is encrypted data of the CMS type 623 signedData as specified below. 624 - The encapContentInfo field must contains the ReplyKeyPack. 625 - The eContentType field shall contain the OID value for 626 id-data: iso(1) member-body(2) us(840) rsadsi(113549) 627 pkcs(1) pkcs7(7) data(1) 628 - The eContent field is data of the type ReplyKeyPack (below). 629 - The certificates field must contain the certificates necessary 630 for the client to establish trust in the KDC's certificate 631 based on the list of trusted certifiers sent by the client in 632 the PA-PK-AS-REQ. This field may be empty if the client did 633 not send to the KDC a list of trusted certifiers (the 634 trustedCertifiers field was empty, meaning that the client 635 already possesses the KDC's certificate). 636 - The signerInfos field is a SET that must contain at least one 637 member, since it contains the actual signature. 638 639 KdcDHKeyInfo ::= SEQUENCE { 640 -- used only when utilizing Diffie-Hellman 641 nonce [0] INTEGER, 642 -- binds responce to the request 643 subjectPublicKey [2] BIT STRING 644 -- Equals public exponent (g^a mod p) 645 -- INTEGER encoded as payload of 646 -- BIT STRING 647 } 648 649 ReplyKeyPack ::= SEQUENCE { 650 -- not used for Diffie-Hellman 651 replyKey [0] EncryptionKey, 652 -- used to encrypt main reply 653 -- ENCTYPE is at least as strong as 654 -- ENCTYPE of session key 655 nonce [1] INTEGER, 656 -- binds response to the request 657 -- must be same as the nonce 658 -- passed in the PKAuthenticator 659 } 660 661 662 Since each certifier in the certification path of a user's 663 certificate is essentially a separate realm, the name of each 664 certifier must be added to the transited field of the ticket. The 665 format of these realm names is defined in Section 3.1 of this 666 document. If applicable, the transit-policy-checked flag should be 667 set in the issued ticket. 668 669 The KDC's certificate must bind the public key to a name derivable 670 from the name of the realm for that KDC. X.509 certificates shall 671 contain the principal name of the KDC as the SubjectAltName version 672 3 extension. Below is the definition of this version 3 extension, as 673 specified by the X.509 standard: 674 675 subjectAltName EXTENSION ::= { 676 SYNTAX GeneralNames 677 IDENTIFIED BY id-ce-subjectAltName 678 } 679 680 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 681 682 GeneralName ::= CHOICE { 683 otherName [0] INSTANCE OF OTHER-NAME, 684 ... 685 } 686 687 OTHER-NAME ::= TYPE-IDENTIFIER 688 689 In this definition, otherName is a name of any form defined as an 690 instance of the OTHER-NAME information object class. For the purpose 691 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 692 be replaced by the type KerberosPrincipalName: 693 694 KerberosPrincipalName ::= SEQUENCE { 695 nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), 696 name [1] OTHER-NAME.&type ( { PrincipalNameTypes } 697 { @nameType } ) 698 } 699 700 PrincipalNameTypes OTHER-NAME ::= { 701 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } 702 } 703 704 PrincipalNameSrvInst ::= GeneralString 705 706 where (from the Kerberos specification) we have 707 708 krb5 OBJECT IDENTIFIER ::= { iso (1) 709 org (3) 710 dod (6) 711 internet (1) 712 security (5) 713 kerberosv5 (2) } 714 715 principalName OBJECT IDENTIFIER ::= { krb5 2 } 716 717 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 718 719 (This specification can also be used to specify a Kerberos name 720 within the user's certificate.) 721 722 The client then extracts the random key used to encrypt the main 723 reply. This random key (in encPaReply) is encrypted with either the 724 client's public key or with a key derived from the DH values 725 exchanged between the client and the KDC. 726 7273.2.1. Additional Information for Errors 728 729 This section describes the interpretation of the method-type and 730 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 731 732 If method-type=1, the client's public key certificate chain does not 733 contain a certificate that is signed by a certification authority 734 trusted by the KDC. The format of the method-data field will be an 735 ASN.1 encoding of a list of trusted certifiers, as defined above: 736 737 TrustedCertifiers ::= SEQUENCE OF PrincipalName 738 739 If method-type=2, the signature on one of the certificates in the 740 chain cannot be verified. The format of the method-data field will 741 be an ASN.1 encoding of the integer index of the certificate in 742 question: 743 744 CertificateIndex ::= INTEGER 745 -- 0 = 1st certificate, 746 -- 1 = 2nd certificate, etc 747 748 If method-type=3, one of the certificates in the chain has been 749 revoked. The format of the method-data field will be an ASN.1 750 encoding of the integer index of the certificate in question: 751 752 CertificateIndex ::= INTEGER 753 -- 0 = 1st certificate, 754 -- 1 = 2nd certificate, etc 755 756 If method-type=4, the KDC name or realm in the PKAuthenticator does 757 not match the principal name of the KDC. There is no method-data 758 field in this case. 759 760 If method-type=5, the client name or realm in the certificate does 761 not match the principal name of the client. There is no 762 method-data field in this case. 763 7643.2.2. Required Algorithms 765 766 Not all of the algorithms in the PKINIT protocol specification have 767 to be implemented in order to comply with the proposed standard. 768 Below is a list of the required algorithms: 769 770 - Diffie-Hellman public/private key pairs 771 - SHA1 digest and DSA for signatures 772 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 773 - 3-key triple DES Temporary and Reply keys 774 7754. Logistics and Policy 776 777 This section describes a way to define the policy on the use of 778 PKINIT for each principal and request. 779 780 The KDC is not required to contain a database record for users 781 that use either the Standard Public Key Authentication. However, 782 if these users are registered with the KDC, it is recommended that 783 the database record for these users be modified to an additional 784 flag in the attributes field to indicate that the user should 785 authenticate using PKINIT. If this flag is set and a request 786 message does not contain the PKINIT preauthentication field, then 787 the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED 788 indicating that a preauthentication field of type PA-PK-AS-REQ must 789 be included in the request. 790 7915. Security Considerations 792 793 PKINIT raises a few security considerations, which we will address 794 in this section. 795 796 First of all, PKINIT introduces a new trust model, where KDCs do not 797 (necessarily) certify the identity of those for whom they issue 798 tickets. PKINIT does allow KDCs to act as their own CAs, in order 799 to simplify key management, but one of the additional benefits is to 800 align Kerberos authentication with a global public key 801 infrastructure. Anyone using PKINIT in this way must be aware of 802 how the certification infrastructure they are linking to works. 803 804 Secondly, PKINIT also introduces the possibility of interactions 805 between different cryptosystems, which may be of widely varying 806 strengths. Many systems, for instance, allow the use of 512-bit 807 public keys. Using such keys to wrap data encrypted under strong 808 conventional cryptosystems, such as triple-DES, is inappropriate; 809 it adds a weak link to a strong one at extra cost. Implementors 810 and administrators should take care to avoid such wasteful and 811 deceptive interactions. 812 813 Lastly, PKINIT calls for randomly generated keys for conventional 814 cryptosystems. Many such systems contain systematically "weak" 815 keys. PKINIT implementations MUST avoid use of these keys, either 816 by discarding those keys when they are generated, or by fixing them 817 in some way (e.g., by XORing them with a given mask). These 818 precautions vary from system to system; it is not our intention to 819 give an explicit recipe for them here. 820 8216. Transport Issues 822 823 Certificate chains can potentially grow quite large and span several 824 UDP packets; this in turn increases the probability that a Kerberos 825 message involving PKINIT extensions will be broken in transit. In 826 light of the possibility that the Kerberos specification will 827 require KDCs to accept requests using TCP as a transport mechanism, 828 we make the same recommendation with respect to the PKINIT 829 extensions as well. 830 8317. Bibliography 832 833 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 834 (V5). Request for Comments 1510. 835 836 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 837 for Computer Networks, IEEE Communications, 32(9):33-38. September 838 1994. 839 840 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 841 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 842 Authentication in Kerberos. 843 draft-ietf-cat-kerberos-pk-cross-04.txt 844 845 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 846 Kerberos. 847 draft-ietf-cat-kerberos-anoncred-00.txt 848 849 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 850 Tickets for Application Servers (PKTAPP). 851 draft-ietf-cat-pktapp-00.txt 852 853 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 854 Using Public Key Cryptography. Symposium On Network and Distributed 855 System Security, 1997. 856 857 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 858 Protocol. In Proceedings of the USENIX Workshop on Electronic 859 Commerce, July 1995. 860 861 [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 862 Request for Comments 2246, January 1999. 863 864 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 865 Distributed Systems. In Proceedings of the 13th International 866 Conference on Distributed Computing Systems, May 1993. 867 868 [10] ITU-T (formerly CCITT) Information technology - Open Systems 869 Interconnection - The Directory: Authentication Framework 870 Recommendation X.509 ISO/IEC 9594-8 871 872 [11] R. Housley. Cryptographic Message Syntax. 873 draft-ietf-smime-cms-10.txt, December 1998. 874 875 [12] PKCS #7: Cryptographic Message Syntax Standard, 876 An RSA Laboratories Technical Note Version 1.5 877 Revised November 1, 1993 878 879 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data 880 Security, Inc. A Description of the RC2(r) Encryption Algorithm 881 March 1998. 882 Request for Comments 2268. 883 884 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 885 Protocol (v3): UTF-8 String Representation of Distinguished Names. 886 Request for Comments 2253. 887 8888. Acknowledgements 889 890 Some of the ideas on which this proposal is based arose during 891 discussions over several years between members of the SAAG, the IETF 892 CAT working group, and the PSRG, regarding integration of Kerberos 893 and SPX. Some ideas have also been drawn from the DASS system. 894 These changes are by no means endorsed by these groups. This is an 895 attempt to revive some of the goals of those groups, and this 896 proposal approaches those goals primarily from the Kerberos 897 perspective. Lastly, comments from groups working on similar ideas 898 in DCE have been invaluable. 899 9009. Expiration Date 901 902 This draft expires November 12, 1999. 903 90410. Authors 905 906 Brian Tung 907 Clifford Neuman 908 USC Information Sciences Institute 909 4676 Admiralty Way Suite 1001 910 Marina del Rey CA 90292-6695 911 Phone: +1 310 822 1511 912 E-mail: {brian, bcn}@isi.edu 913 914 Matthew Hur 915 CyberSafe Corporation 916 1605 NW Sammamish Road 917 Issaquah WA 98027-5378 918 Phone: +1 425 391 6000 919 E-mail: matt.hur@cybersafe.com 920 921 Ari Medvinsky 922 Excite 923 555 Broadway 924 Redwood City, CA 94063 925 Phone +1 650 569 2119 926 E-mail: amedvins@excitecorp.com 927 928 Sasha Medvinsky 929 General Instrument 930 6450 Sequence Drive 931 San Diego, CA 92121 932 Phone +1 619 404 2825 933 E-mail: smedvinsky@gi.com 934 935 John Wray 936 Iris Associates, Inc. 937 5 Technology Park Dr. 938 Westford, MA 01886 939 E-mail: John_Wray@iris.com 940 941 Jonathan Trostle 942 170 W. Tasman Dr. 943 San Jose, CA 95134 944 E-mail: jtrostle@cisco.com 945