1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-init-07.txt Clifford Neuman 3Updates: RFC 1510 ISI 4expires May 15, 1999 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 Sasha Medvinsky 9 CyberSafe Corporation 10 Jonathan Trostle 11 Cisco 12 13 14 Public Key Cryptography for Initial Authentication in Kerberos 15 16 170. Status Of This Memo 18 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 23 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 29 30 To learn the current status of any Internet-Draft, please check 31 the "1id-abstracts.txt" listing contained in the Internet-Drafts 32 Shadow Directories on ftp.ietf.org (US East Coast), 33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 34 munnari.oz.au (Pacific Rim). 35 36 The distribution of this memo is unlimited. It is filed as 37 draft-ietf-cat-kerberos-pk-init-07.txt, and expires May 15, 1999. 38 Please send comments to the authors. 39 40 411. Abstract 42 43 This document defines extensions (PKINIT) to the Kerberos protocol 44 specification (RFC 1510 [1]) to provide a method for using public 45 key cryptography during initial authentication. The methods 46 defined specify the ways in which preauthentication data fields and 47 error data fields in Kerberos messages are to be used to transport 48 public key data. 49 50 512. Introduction 52 53 The popularity of public key cryptography has produced a desire for 54 its support in Kerberos [2]. The advantages provided by public key 55 cryptography include simplified key management (from the Kerberos 56 perspective) and the ability to leverage existing and developing 57 public key certification infrastructures. 58 59 Public key cryptography can be integrated into Kerberos in a number 60 of ways. One is to associate a key pair with each realm, which can 61 then be used to facilitate cross-realm authentication; this is the 62 topic of another draft proposal. Another way is to allow users with 63 public key certificates to use them in initial authentication. This 64 is the concern of the current document. 65 66 One of the guiding principles in the design of PKINIT is that 67 changes should be as minimal as possible. As a result, the basic 68 mechanism of PKINIT is as follows: The user sends a request to the 69 KDC as before, except that if that user is to use public key 70 cryptography in the initial authentication step, his certificate 71 accompanies the initial request, in the preauthentication fields. 72 73 Upon receipt of this request, the KDC verifies the certificate and 74 issues a ticket granting ticket (TGT) as before, except that 75 the encPart from the AS-REP message carrying the TGT is now 76 encrypted in a randomly-generated key, instead of the user's 77 long-term key (which is derived from a password). This 78 random key is in turn encrypted using the public key from the 79 certificate that came with the request and signed using the KDC's 80 private key, and accompanies the reply, in the preauthentication 81 fields. 82 83 PKINIT also allows for users with only digital signature keys to 84 authenticate using those keys, and for users to store and retrieve 85 private keys on the KDC. 86 87 The PKINIT specification may also be used as a building block for 88 other specifications. PKCROSS [3] utilizes PKINIT for establishing 89 the inter-realm key and associated inter-realm policy to be applied 90 in issuing cross realm service tickets. As specified in [4], anonymous 91 Kerberos tickets can be issued by applying a NULL signature in 92 combination with Diffie-Hellman in the PKINIT exchange. Additionally, 93 The PKINIT specification may be used for direct peer to peer 94 authentication without contacting a central KDC. This application 95 of PKINIT is described in PKTAPP [5] and is based on concepts 96 introduced in [6, 7]. For direct client-to-server authentication, 97 the client uses PKINIT to authenticate to the end server (instead 98 of a central KDC), which then issues a ticket for itself. This 99 approach has an advantage over SSL [8] in that the server does not 100 need to save state (cache session keys). Furthermore, an 101 additional benefit is that Kerberos tickets can facilitate 102 delegation (see [9]). 103 104 1053. Proposed Extensions 106 107 This section describes extensions to RFC 1510 for supporting the 108 use of public key cryptography in the initial request for a ticket 109 granting ticket (TGT). 110 111 In summary, the following changes to RFC 1510 are proposed: 112 113 * Users may authenticate using either a public key pair or a 114 conventional (symmetric) key. If public key cryptography is 115 used, public key data is transported in preauthentication 116 data fields to help establish identity. 117 * Users may store private keys on the KDC for retrieval during 118 Kerberos initial authentication. 119 120 This proposal addresses two ways that users may use public key 121 cryptography for initial authentication. Users may present public 122 key certificates, or they may generate their own session key, 123 signed by their digital signature key. In either case, the end 124 result is that the user obtains an ordinary TGT that may be used for 125 subsequent authentication, with such authentication using only 126 conventional cryptography. 127 128 Section 3.1 provides definitions to help specify message formats. 129 Section 3.2 and 3.3 describe the extensions for the two initial 130 authentication methods. Section 3.4 describes a way for the user to 131 store and retrieve his private key on the KDC, as an adjunct to the 132 initial authentication. 133 134 1353.1. Definitions 136 137 The extensions involve new preauthentication fields; we propose the 138 addition of the following types: 139 140 PA-PK-AS-REQ 14 141 PA-PK-AS-REP 15 142 PA-PK-AS-SIGN 16 143 PA-PK-KEY-REQ 17 144 PA-PK-KEY-REP 18 145 146 The extensions also involve new error types; we propose the addition 147 of the following types: 148 149 KDC_ERR_CLIENT_NOT_TRUSTED 62 150 KDC_ERR_KDC_NOT_TRUSTED 63 151 KDC_ERR_INVALID_SIG 64 152 KDC_ERR_KEY_TOO_WEAK 65 153 KDC_ERR_CERTIFICATE_MISMATCH 66 154 155 In many cases, PKINIT requires the encoding of an X.500 name as a 156 Realm. In these cases, the realm will be represented using a 157 different style, specified in RFC 1510 with the following example: 158 159 NAMETYPE:rest/of.name=without-restrictions 160 161 For a realm derived from an X.500 name, NAMETYPE will have the value 162 X500-RFC2253. The full realm name will appear as follows: 163 164 X500-RFC2253:RFC2253Encode(DistinguishedName) 165 166 where DistinguishedName is an X.500 name, and RFC2253Encode is a 167 readable ASCII encoding of an X.500 name, as defined by 168 RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which 169 is not supported by this version of PKINIT.) 170 171 To ensure that this encoding is unique, we add the following rule 172 to those specified by RFC 2253: 173 174 The order in which the attributes appear in the RFC 2253 175 encoding must be the reverse of the order in the ASN.1 176 encoding of the X.500 name that appears in the public key 177 certificate. The order of the relative distinguished names 178 (RDNs), as well as the order of the AttributeTypeAndValues 179 within each RDN, will be reversed. (This is despite the fact 180 that an RDN is defined as a SET of AttributeTypeAndValues, where 181 an order is normally not important.) 182 183 Similarly, PKINIT may require the encoding of an X.500 name as a 184 PrincipalName. In these cases, the name-type of the principal name 185 shall be set to NT-X500-PRINCIPAL. This new name type is defined 186 as: 187 188 #define CSFC5c_NT_X500_PRINCIPAL 6 189 190 The name-string shall be set as follows: 191 192 RFC2253Encode(DistinguishedName) 193 194 as described above. 195 196 1973.1.1. Encryption and Key Formats 198 199 In the exposition below, we use the terms public key and private 200 key generically. It should be understood that the term "public 201 key" may be used to refer to either a public encryption key or a 202 signature verification key, and that the term "private key" may be 203 used to refer to either a private decryption key or a signature 204 generation key. The fact that these are logically distinct does 205 not preclude the assignment of bitwise identical keys. 206 207 All additional symmetric keys specified in this draft shall use the 208 same encryption type as the session key in the response from the 209 KDC. These include the temporary keys used to encrypt the signed 210 random key encrypting the response, as well as the key derived from 211 Diffie-Hellman agreement. In the case of Diffie-Hellman, the key 212 shall be produced from the agreed bit string as follows: 213 214 * Truncate the bit string to the appropriate length. 215 * Rectify parity in each byte (if necessary) to obtain the key. 216 217 For instance, in the case of a DES key, we take the first eight 218 bytes of the bit stream, and then adjust the least significant bit 219 of each byte to ensure that each byte has odd parity. 220 221 2223.1.2. Algorithm Identifiers 223 224 PKINIT does not define, but does permit, the algorithm identifiers 225 listed below. 226 2273.1.2.1. Signature Algorithm Identifiers 228 229 These are the algorithm identifiers for use in the Signature data 230 structure: 231 232 sha-1WithRSAEncryption ALGORITHM PARAMETER NULL 233 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 234 pkcs-1(1) 5 } 235 236 dsaWithSHA1 ALGORITHM PARAMETER NULL 237 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 238 oIWSecAlgorithm(2) dsaWithSHA1(27) } 239 240 md4WithRsaEncryption ALGORITHM PARAMETER NULL 241 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 242 oIWSecAlgorithm(2) md4WithRSAEncryption(4) } 243 244 md5WithRSAEncryption ALGORITHM PARAMETER NULL 245 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 246 pkcs-1(1) md5WithRSAEncryption(4) } 247 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 266 2673.1.2.3. Algorithm Identifiers for RSA Encryption 268 269 These algorithm identifiers are used inside the EnvelopedData data 270 structure, for encrypting the temporary key with a public key: 271 272 rsaEncryption ALGORITHM PARAMETER NULL 273 ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 274 pkcs-1(1) rsaEncryption(1) 275 276 2773.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 278 279 These algorithm identifiers are used inside the EnvelopedData data 280 structure, for encrypting the temporary key with a Diffie-Hellman- 281 derived key, or for encrypting the reply key: 282 283 desCBC ALGORITHM PARAMETER IV8 284 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) 285 oIWSecAlgorithm(2) desCBC(7) } 286 287 DES-EDE3-CBC ALGORITHM PARAMETER IV8 288 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 289 encryptionAlgorithm(3) desEDE3(7) } 290 291 IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector 292 293 rc2CBC ALGORITHM PARAMETER RC2-CBCParameter 294 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 295 encryptionAlgorithm(3) rc2CBC(2) } 296 297 The rc2CBC algorithm parameters (RC2-CBCParameter) are defined 298 in the following section. 299 300 rc4 ALGORITHM PARAMETER NULL 301 ::= { iso(1) member-body(2) US(840) rsadsi(113549) 302 encryptionAlgorithm(3) rc4(4) } 303 304 The rc4 algorithm cannot be used with the Diffie-Hellman-derived 305 keys, because its parameters do not specify the size of the key. 306 307 3083.1.2.5. rc2CBC Algorithm Parameters 309 310 This definition of the RC2 parameters is taken from a paper by 311 Ron Rivest [13]. Refer to [13] for the complete description of the 312 RC2 algorithm. 313 314 RC2-CBCParameter ::= CHOICE { 315 iv IV, 316 params SEQUENCE { 317 version RC2Version, 318 iv IV 319 } 320 } 321 322 where 323 324 IV ::= OCTET STRING -- 8 octets 325 RC2Version ::= INTEGER -- 1-1024 326 327 RC2 in CBC mode has two parameters: an 8-byte initialization 328 vector (IV) and a version number in the range 1-1024 which 329 specifies in a roundabout manner the number of effective key bits 330 to be used for the RC2 encryption/decryption. 331 332 The correspondence between effective key bits and version number 333 is as follows: 334 335 1. If the number EKB of effective key bits is in the range 1-255, 336 then the version number is given by Table[EKB], where the 337 256-byte translation table is specified below. It specifies a 338 permutation on the numbers 0-255. 339 340 2. If the number EKB of effective key bits is in the range 341 256-1024, then the version number is simply EKB. 342 343 The default number of effective key bits for RC2 is 32. 344 If RC2-CBC is being performed with 32 effective key bits, the 345 parameters should be supplied as a simple IV, rather than as a 346 SEQUENCE containing a version and an IV. 347 348 0 1 2 3 4 5 6 7 8 9 a b c d e f 349 350 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 351 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a 352 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 353 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c 354 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 355 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa 356 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e 357 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf 358 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 359 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 360 a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c 361 b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 362 c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 363 d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 364 e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f 365 f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab 366 367 3683.2. Standard Public Key Authentication 369 370 Implementation of the changes in this section is REQUIRED for 371 compliance with PKINIT. 372 373 It is assumed that all public keys are signed by some certification 374 authority (CA). The initial authentication request is sent as per 375 RFC 1510, except that a preauthentication field containing data 376 signed by the user's private key accompanies the request: 377 378 PA-PK-AS-REQ ::= SEQUENCE { 379 -- PA TYPE 14 380 signedAuthPack [0] SignedAuthPack 381 userCert [1] SEQUENCE OF Certificate OPTIONAL, 382 -- the user's certificate chain; 383 -- if present, the KDC must use 384 -- the public key from this 385 -- particular certificate chain to 386 -- verify the signature in the 387 -- request 388 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, 389 -- CAs that the client trusts 390 serialNumber [3] CertificateSerialNumber OPTIONAL 391 -- specifying a particular KDC 392 -- certificate if the client 393 -- already has it; 394 -- must be accompanied by 395 -- a single trustedCertifier 396 } 397 398 CertificateSerialNumber ::= INTEGER 399 -- as specified by PKCS #6 [15] 400 401 SignedAuthPack ::= SEQUENCE { 402 authPack [0] AuthPack, 403 authPackSig [1] Signature, 404 -- of authPack 405 -- using user's private key 406 } 407 408 AuthPack ::= SEQUENCE { 409 pkAuthenticator [0] PKAuthenticator, 410 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 411 -- if client is using Diffie-Hellman 412 } 413 414 PKAuthenticator ::= SEQUENCE { 415 kdcName [0] PrincipalName, 416 kdcRealm [1] Realm, 417 cusec [2] INTEGER, 418 -- for replay prevention 419 ctime [3] KerberosTime, 420 -- for replay prevention 421 nonce [4] INTEGER 422 } 423 424 Signature ::= SEQUENCE { 425 signatureAlgorithm [0] SignatureAlgorithmIdentifier, 426 pkcsSignature [1] BIT STRING 427 -- octet-aligned big-endian bit 428 -- string (encrypted with signer's 429 -- private key) 430 } 431 432 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 433 434 AlgorithmIdentifier ::= SEQUENCE { 435 algorithm ALGORITHM.&id, 436 parameters ALGORITHM.&type 437 } -- as specified by the X.509 recommendation [10] 438 439 SubjectPublicKeyInfo ::= SEQUENCE { 440 algorithm AlgorithmIdentifier, 441 -- dhKeyAgreement 442 subjectPublicKey BIT STRING 443 -- for DH, equals 444 -- public exponent (INTEGER encoded 445 -- as payload of BIT STRING) 446 } -- as specified by the X.509 recommendation [9] 447 448 Certificate ::= SEQUENCE { 449 certType [0] INTEGER, 450 -- type of certificate 451 -- 1 = X.509v3 (DER encoding) 452 -- 2 = PGP (per PGP specification) 453 -- 3 = PKIX (per PKCS #6 [15]) 454 certData [1] OCTET STRING 455 -- actual certificate 456 -- type determined by certType 457 } 458 459 If the client passes a certificate serial number in the request, 460 the KDC is requested to use the referred-to certificate. If none 461 exists, then the KDC returns an error of type 462 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 463 other hand, the client does not pass any trustedCertifiers, 464 believing that it has the KDC's certificate, but the KDC has more 465 than one certificate. 466 467 The PKAuthenticator carries information to foil replay attacks, 468 to bind the request and response, and to optionally pass the 469 client's Diffie-Hellman public value (i.e. for using DSA in 470 combination with Diffie-Hellman). The PKAuthenticator is signed 471 with the private key corresponding to the public key in the 472 certificate found in userCert (or cached by the KDC). 473 474 The userCert field is a sequence of certificates, the first of which 475 must be the user's public key certificate. Any subsequent 476 certificates will be certificates of the certifiers of the user's 477 certificate. These cerificates may be used by the KDC to verify the 478 user's public key. This field may be left empty if the KDC already 479 has the user's certificate. 480 481 The trustedCertifiers field contains a list of certification 482 authorities trusted by the client, in the case that the client does 483 not possess the KDC's public key certificate. If the KDC has no 484 certificate signed by any of the trustedCertifiers, then it returns 485 an error of type KDC_ERR_CERTIFICATE_MISMATCH. 486 487 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 488 type, the KDC attempts to verify the user's certificate chain 489 (userCert), if one is provided in the request. This is done by 490 verifying the certification path against the KDC's policy of 491 legitimate certifiers. This may be based on a certification 492 hierarchy, or it may be simply a list of recognized certifiers in a 493 system like PGP. 494 495 If verification of the user's certificate fails, the KDC sends back 496 an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data 497 field contains additional information pertaining to this error, and 498 is formatted as follows: 499 500 METHOD-DATA ::= SEQUENCE { 501 method-type [0] INTEGER, 502 -- 1 = cannot verify public key 503 -- 2 = invalid certificate 504 -- 3 = revoked certificate 505 -- 4 = invalid KDC name 506 -- 5 = client name mismatch 507 method-data [1] OCTET STRING OPTIONAL 508 } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) 509 510 The values for the method-type and method-data fields are described 511 in Section 3.2.1. 512 513 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 514 verifies that it has a certificate issued by one of the certifiers 515 trusted by the client. If it does not have a suitable certificate, 516 the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to 517 the client. 518 519 If a trust relationship exists, the KDC then verifies the client's 520 signature on AuthPack. If that fails, the KDC returns an error 521 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 522 timestamp in the PKAuthenticator to assure that the request is not a 523 replay. The KDC also verifies that its name is specified in the 524 PKAuthenticator. 525 526 If the clientPublicValue field is filled in, indicating that the 527 client wishes to use Diffie-Hellman key agreement, then the KDC 528 checks to see that the parameters satisfy its policy. If they do 529 not (e.g., the prime size is insufficient for the expected 530 encryption type), then the KDC sends back an error message of type 531 KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and 532 private values for the response. 533 534 The KDC also checks that the timestamp in the PKAuthenticator is 535 within the allowable window. If the local (server) time and the 536 client time in the authenticator differ by more than the allowable 537 clock skew, then the KDC returns an error message of type 538 KRB_AP_ERR_SKEW. 539 540 Assuming no errors, the KDC replies as per RFC 1510, except as 541 follows. The user's name in the ticket is determined by the 542 following decision algorithm: 543 544 1. If the KDC has a mapping from the name in the certificate 545 to a Kerberos name, then use that name. Else 546 2. If the certificate contains a Kerberos name in an extension 547 field, and local KDC policy allows, then use that name. 548 Else 549 3. Use the name as represented in the certificate, mapping 550 as necessary (e.g., as per RFC 2253 for X.500 names). In 551 this case the realm in the ticket shall be the name of the 552 certification authority that issued the user's certificate. 553 554 The KDC encrypts the reply not with the user's long-term key, but 555 with a random key generated only for this particular response. This 556 random key is sealed in the preauthentication field: 557 558 PA-PK-AS-REP ::= SEQUENCE { 559 -- PA TYPE 15 560 encKeyPack [1] EnvelopedKeyPack, 561 -- temporary key is encrypted 562 -- using either the client public 563 -- key or the Diffie-Hellman key 564 -- specified by SignedKDCPublicValue. 565 -- SignedReplyKeyPack, encrypted 566 -- with the temporary key, is also 567 -- included. 568 signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL, 569 -- if one was passed in the request 570 kdcCert [3] SEQUENCE OF Certificate OPTIONAL 571 -- the KDC's certificate chain 572 } 573 574 575 The EnvelopedKeyPack data type below contains an encrypted 576 temporary key (either with the PKINIT client's public key or with a 577 symmetric key, resulting from the Diffie-Hellman exchange). It also 578 contains a signed and encrypted reply key. This data structure is 579 similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12]. 580 581 EnvelopedKeyPack ::= SEQUENCE { 582 version Version, 583 -- Always set to 0. 584 recipientInfos RecipientInfos, 585 -- This is a SET, which must contain 586 -- exactly one member. Contains a 587 -- temporary key, encrypted with the 588 -- client's public key. This 589 -- temporary key is used to encrypt 590 -- the reply key. 591 encryptedContentInfo EncryptedContentInfo 592 -- contains the signed and encrypted 593 -- reply key 594 } 595 596 Version ::= INTEGER 597 598 RecipientInfos ::= SET OF RecipientInfo 599 600 RecipientInfo ::= SEQUENCE { 601 version Version, 602 -- shall be 0 603 rid RecipientIdentifier, 604 -- Since this is an optional field, 605 -- it supports both CMS and PKCS #7 606 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 607 EncryptedKey OCTET STRING 608 -- the temporary key, encrypted with 609 -- the PKINIT client's public key 610 } 611 612 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 613 614 RecipientIdentifier ::= IssuerAndSerialNumber 615 -- Corresponds to the X.509 V3 extension 616 -- SubjectKeyIdentifier. 617 618 IssuerAndSerialNumber ::= SEQUENCE { 619 issuer Name, 620 -- a distinguished name, as defined 621 -- by X.509 622 serialNumber CertificateSerialNumber 623 } 624 625 CertificateSerialNumber ::= INTEGER 626 627 EncryptedContentInfo ::= SEQUENCE { 628 contentType ContentType, 629 -- shall be: 630 -- iso(1) member-body(2) us(840) 631 -- rsadsi(113549) pkcs(1) pkcs7(7) 632 -- EnvelopedData(3) 633 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier 634 -- Algorithm used to encrypt the 635 -- SignedReplyKeyPack. 636 encryptedContent OCTET STRING 637 -- The encrypted data is of the type 638 -- SignedReplyKeyPack. 639 } 640 641 ContentType ::= OBJECT IDENTIFIER 642 643 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 644 645 SignedReplyKeyPack ::= SEQUENCE { 646 replyKeyPack [0] ReplyKeyPack, 647 replyKeyPackSig [1] Signature, 648 -- of replyKeyPack 649 -- using KDC's private key 650 } 651 652 ReplyKeyPack ::= SEQUENCE { 653 replyKey [0] EncryptionKey, 654 -- used to encrypt main reply 655 -- of same ENCTYPE as session key 656 nonce [1] INTEGER 657 -- binds response to the request 658 -- must be same as the nonce 659 -- passed in the PKAuthenticator 660 } 661 662 SignedKDCPublicValue ::= SEQUENCE { 663 kdcPublicValue [0] SubjectPublicKeyInfo, 664 -- as described above 665 kdcPublicValueSig [1] Signature 666 -- of kdcPublicValue 667 -- using KDC's private key 668 } 669 670 671 The kdcCert field is a sequence of certificates, the first of which 672 must be the KDC's public key certificate. Any subsequent 673 certificates will be certificates of the certifiers of the KDC's 674 certificate. The last of these must have as its certifier one of 675 the certifiers sent to the KDC in the PA-PK-AS-REQ. These 676 cerificates may be used by the client to verify the KDC's public 677 key. This field is empty if the client did not send to the KDC a 678 list of trusted certifiers (the trustedCertifiers field was empty). 679 680 Since each certifier in the certification path of a user's 681 certificate is essentially a separate realm, the name of each 682 certifier shall be added to the transited field of the ticket. The 683 format of these realm names is defined in Section 3.1 of this 684 document. If applicable, the transit-policy-checked flag should be 685 set in the issued ticket. 686 687 The KDC's certificate must bind the public key to a name derivable 688 from the name of the realm for that KDC. X.509 certificates shall 689 contain the principal name of the KDC as the SubjectAltName version 690 3 extension. Below is the definition of this version 3 extension, as 691 specified by the X.509 standard: 692 693 subjectAltName EXTENSION ::= { 694 SYNTAX GeneralNames 695 IDENTIFIED BY id-ce-subjectAltName 696 } 697 698 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 699 700 GeneralName ::= CHOICE { 701 otherName [0] INSTANCE OF OTHER-NAME, 702 ... 703 } 704 705 OTHER-NAME ::= TYPE-IDENTIFIER 706 707 In this definition, otherName is a name of any form defined as an 708 instance of the OTHER-NAME information object class. For the purpose 709 of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will 710 be replaced by the type KerberosPrincipalName: 711 712 KerberosPrincipalName ::= SEQUENCE { 713 nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), 714 name [1] OTHER-NAME.&type ( { PrincipalNameTypes } 715 { @nameType } ) 716 } 717 718 PrincipalNameTypes OTHER-NAME ::= { 719 { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } 720 } 721 722 PrincipalNameSrvInst ::= GeneralString 723 724 where (from the Kerberos specification) we have 725 726 krb5 OBJECT IDENTIFIER ::= { iso (1) 727 org (3) 728 dod (6) 729 internet (1) 730 security (5) 731 kerberosv5 (2) } 732 733 principalName OBJECT IDENTIFIER ::= { krb5 2 } 734 735 principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 736 737 (This specification can also be used to specify a Kerberos name 738 within the user's certificate.) 739 740 The client then extracts the random key used to encrypt the main 741 reply. This random key (in encPaReply) is encrypted with either the 742 client's public key or with a key derived from the DH values 743 exchanged between the client and the KDC. 744 745 7463.2.1. Additional Information for Errors 747 748 This section describes the interpretation of the method-type and 749 method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. 750 751 If method-type=1, the client's public key certificate chain does not 752 contain a certificate that is signed by a certification authority 753 trusted by the KDC. The format of the method-data field will be an 754 ASN.1 encoding of a list of trusted certifiers, as defined above: 755 756 TrustedCertifiers ::= SEQUENCE OF PrincipalName 757 758 If method-type=2, the signature on one of the certificates in the 759 chain cannot be verified. The format of the method-data field will 760 be an ASN.1 encoding of the integer index of the certificate in 761 question: 762 763 CertificateIndex ::= INTEGER 764 -- 0 = 1st certificate, 765 -- 1 = 2nd certificate, etc 766 767 If method-type=3, one of the certificates in the chain has been 768 revoked. The format of the method-data field will be an ASN.1 769 encoding of the integer index of the certificate in question: 770 771 CertificateIndex ::= INTEGER 772 -- 0 = 1st certificate, 773 -- 1 = 2nd certificate, etc 774 775 If method-type=4, the KDC name or realm in the PKAuthenticator does 776 not match the principal name of the KDC. There is no method-data 777 field in this case. 778 779 If method-type=5, the client name or realm in the certificate does 780 not match the principal name of the client. There is no 781 method-data field in this case. 782 783 7843.2.2. Required Algorithms and Data Formats 785 786 Not all of the algorithms in the PKINIT protocol specification have 787 to be implemented in order to comply with the proposed standard. 788 Below is a list of the required algorithms and data formats: 789 790 - Diffie-Hellman public/private key pairs 791 - SHA1 digest and DSA for signatures 792 - X.509 version 3 certificates 793 - 3-key triple DES keys derived from the Diffie-Hellman Exchange 794 - 3-key triple DES Temporary and Reply keys 795 796 7973.3. Digital Signature 798 799 Implementation of the changes in this section are OPTIONAL for 800 compliance with PKINIT. 801 802 We offer this option with the warning that it requires the client to 803 generate a random key; the client may not be able to guarantee the 804 same level of randomness as the KDC. 805 806 If the user registered, or presents a certificate for, a digital 807 signature key with the KDC instead of an encryption key, then a 808 separate exchange must be used. The client sends a request for a 809 TGT as usual, except that it (rather than the KDC) generates the 810 random key that will be used to encrypt the KDC response. This key 811 is sent to the KDC along with the request in a preauthentication 812 field, encrypted with the KDC's public key: 813 814 PA-PK-AS-SIGN ::= SEQUENCE { 815 -- PA TYPE 16 816 encKeyPack [1] EnvelopedKeyPack, 817 -- temporary key is encrypted 818 -- using the KDC public 819 -- key. 820 -- SignedRandomKeyPack, encrypted 821 -- with the temporary key, is also 822 -- included. 823 userCert [2] SEQUENCE OF Certificate OPTIONAL 824 -- the user's certificate chain; 825 -- if present, the KDC must use 826 -- the public key from this 827 -- particular certificate chain to 828 -- verify the signature in the 829 -- request 830 } 831 832 In the above message, the content of the encKeyPack is similar to 833 the content of the encKeyPack field in the PA-PK-AS-REP message, 834 except that it is the KDC's public key and not the client's public 835 key that is used to encrypt the temporary key. And, the 836 encryptedContentInfo field inside the EnvelopedKeyPack contains 837 encrypted data of the type SignedRandomKeyPack instead of the 838 SignedReplyKeyPack. 839 840 SignedRandomKeyPack ::= SEQUENCE { 841 randomkeyPack [0] RandomKeyPack, 842 randomkeyPackSig [1] Signature 843 -- of keyPack 844 -- using user's private key 845 } 846 847 RandomKeyPack ::= SEQUENCE { 848 randomKey [0] EncryptionKey, 849 -- will be used to encrypt reply 850 randomKeyAuth [1] PKAuthenticator 851 } 852 853 If the KDC does not accept client-generated random keys as a matter 854 of policy, then it sends back an error message of type 855 KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as 856 follows. 857 858 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 859 the randomKey. It then replies as per RFC 1510, except that the 860 reply is encrypted not with a password-derived user key, but with 861 the randomKey sent in the request. Since the client already knows 862 this key, there is no need to accompany the reply with an extra 863 preauthentication field. The transited field of the ticket should 864 specify the certification path as described in Section 3.2. 865 866 8673.4. Retrieving the User's Private Key from the KDC 868 869 Implementation of the changes described in this section are OPTIONAL 870 for compliance with PKINIT. (This section may or may not fall under 871 the purview of a patent for private key storage; please see Section 872 8 for more information.) 873 874 When the user's private key is not stored local to the user, he may 875 choose to store the private key (normally encrypted using a 876 password-derived key) on the KDC. In this case, the client makes a 877 request as described above, except that instead of preauthenticating 878 with his private key, he uses a symmetric key shared with the KDC. 879 880 For simplicity's sake, this shared key is derived from the password- 881 derived key used to encrypt the private key, in such a way that the 882 KDC can authenticate the user with the shared key without being able 883 to extract the private key. 884 885 We provide this option to present the user with an alternative to 886 storing the private key on local disk at each machine where he 887 expects to authenticate himself using PKINIT. It should be noted 888 that it replaces the added risk of long-term storage of the private 889 key on possibly many workstations with the added risk of storing the 890 private key on the KDC in a form vulnerable to brute-force attack. 891 892 Denote by K1 the symmetric key used to encrypt the private key. 893 Then construct symmetric key K2 as follows: 894 895 * Perform a hash on K1. 896 * Truncate the digest to Length(K1) bytes. 897 * Rectify parity in each byte (if necessary) to obtain K2. 898 899 The KDC stores K2, the public key, and the encrypted private key. 900 This key pair is designated as the "primary" key pair for that user. 901 This primary key pair is the one used to perform initial 902 authentication using the PA-PK-AS-REP preauthentication field. If 903 he desires, he may also store additional key pairs on the KDC; these 904 may be requested in addition to the primary. When the client 905 requests initial authentication using public key cryptography, it 906 must then include in its request, instead of a PA-PK-AS-REQ, the 907 following preauthentication sequence: 908 909 PA-PK-KEY-REQ ::= SEQUENCE { 910 -- PA TYPE 17 911 signedPKAuth [0] SignedPKAuth, 912 trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, 913 -- CAs that the client trusts 914 keyIDList [2] SEQUENCE OF Checksum OPTIONAL 915 -- payload is hash of public key 916 -- corresponding to desired 917 -- private key 918 -- if absent, KDC will return all 919 -- stored private keys 920 } 921 922 Checksum ::= SEQUENCE { 923 cksumtype [0] INTEGER, 924 checksum [1] OCTET STRING 925 } -- as specified by RFC 1510 926 927 SignedPKAuth ::= SEQUENCE { 928 pkAuth [0] PKAuthenticator, 929 pkAuthSig [1] Signature 930 -- of pkAuth 931 -- using the symmetric key K2 932 } 933 934 If a keyIDList is present, the first identifier should indicate 935 the primary private key. No public key certificate is required, 936 since the KDC stores the public key along with the private key. 937 If there is no keyIDList, all the user's private keys are returned. 938 939 Upon receipt, the KDC verifies the signature using K2. If the 940 verification fails, the KDC sends back an error of type 941 KDC_ERR_INVALID_SIG. If the signature verifies, but the requested 942 keys are not found on the KDC, then the KDC sends back an error of 943 type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as 944 described in Section 3.2, except that in addition, the KDC appends 945 the following preauthentication sequence: 946 947 PA-PK-KEY-REP ::= SEQUENCE { 948 -- PA TYPE 18 949 encKeyRep [0] EncryptedData 950 -- of type EncKeyReply 951 -- using the symmetric key K2 952 } 953 954 EncKeyReply ::= SEQUENCE { 955 keyPackList [0] SEQUENCE OF KeyPack, 956 -- the first KeyPair is 957 -- the primary key pair 958 nonce [1] INTEGER 959 -- binds reply to request 960 -- must be identical to the nonce 961 -- sent in the SignedAuthPack 962 } 963 964 KeyPack ::= SEQUENCE { 965 keyID [0] Checksum, 966 encPrivKey [1] OCTET STRING 967 } 968 969 Upon receipt of the reply, the client extracts the encrypted private 970 keys (and may store them, at the client's option). The primary 971 private key, which must be the first private key in the keyPack 972 SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; 973 this key in turn is used to decrypt the main reply as described in 974 Section 3.2. 975 976 9774. Logistics and Policy 978 979 This section describes a way to define the policy on the use of 980 PKINIT for each principal and request. 981 982 The KDC is not required to contain a database record for users 983 that use either the Standard Public Key Authentication or Public Key 984 Authentication with a Digital Signature. However, if these users 985 are registered with the KDC, it is recommended that the database 986 record for these users be modified to include three additional flags 987 in the attributes field. 988 989 The first flag, use_standard_pk_init, indicates that the user should 990 authenticate using standard PKINIT as described in Section 3.2. The 991 second flag, use_digital_signature, indicates that the user should 992 authenticate using digital signature PKINIT as described in Section 993 3.3. The third flag, store_private_key, indicates that the user 994 has stored his private key on the KDC and should retrieve it using 995 the exchange described in Section 3.4. 996 997 If one of the preauthentication fields defined above is included in 998 the request, then the KDC shall respond as described in Sections 3.2 999 through 3.4, ignoring the aforementioned database flags. If more 1000 than one of the preauthentication fields is present, the KDC shall 1001 respond with an error of type KDC_ERR_PREAUTH_FAILED. 1002 1003 In the event that none of the preauthentication fields defined above 1004 are included in the request, the KDC checks to see if any of the 1005 above flags are set. If the first flag is set, then it sends back 1006 an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a 1007 preauthentication field of type PA-PK-AS-REQ must be included in the 1008 request. 1009 1010 Otherwise, if the first flag is clear, but the second flag is set, 1011 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 1012 indicating that a preauthentication field of type PA-PK-AS-SIGN must 1013 be included in the request. 1014 1015 Lastly, if the first two flags are clear, but the third flag is set, 1016 then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED 1017 indicating that a preauthentication field of type PA-PK-KEY-REQ must 1018 be included in the request. 1019 1020 10215. Security Considerations 1022 1023 PKINIT raises a few security considerations, which we will address 1024 in this section. 1025 1026 First of all, PKINIT introduces a new trust model, where KDCs do not 1027 (necessarily) certify the identity of those for whom they issue 1028 tickets. PKINIT does allow KDCs to act as their own CAs, in order 1029 to simplify key management, but one of the additional benefits is to 1030 align Kerberos authentication with a global public key 1031 infrastructure. Anyone using PKINIT in this way must be aware of 1032 how the certification infrastructure they are linking to works. 1033 1034 Secondly, PKINIT also introduces the possibility of interactions 1035 between different cryptosystems, which may be of widely varying 1036 strengths. Many systems, for instance, allow the use of 512-bit 1037 public keys. Using such keys to wrap data encrypted under strong 1038 conventional cryptosystems, such as triple-DES, is inappropriate; 1039 it adds a weak link to a strong one at extra cost. Implementors 1040 and administrators should take care to avoid such wasteful and 1041 deceptive interactions. 1042 1043 Lastly, PKINIT calls for randomly generated keys for conventional 1044 cryptosystems. Many such systems contain systematically "weak" 1045 keys. PKINIT implementations MUST avoid use of these keys, either 1046 by discarding those keys when they are generated, or by fixing them 1047 in some way (e.g., by XORing them with a given mask). These 1048 precautions vary from system to system; it is not our intention to 1049 give an explicit recipe for them here. 1050 1051 10525. Transport Issues 1053 1054 Certificate chains can potentially grow quite large and span several 1055 UDP packets; this in turn increases the probability that a Kerberos 1056 message involving PKINIT extensions will be broken in transit. In 1057 light of the possibility that the Kerberos specification will 1058 require KDCs to accept requests using TCP as a transport mechanism, 1059 we make the same recommendation with respect to the PKINIT 1060 extensions as well. 1061 1062 10636. Bibliography 1064 1065 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 1066 (V5). Request for Comments 1510. 1067 1068 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 1069 for Computer Networks, IEEE Communications, 32(9):33-38. September 1070 1994. 1071 1072 [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, 1073 A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm 1074 Authentication in Kerberos. 1075 draft-ietf-cat-kerberos-pk-cross-04.txt 1076 1077 [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in 1078 Kerberos. 1079 draft-ietf-cat-kerberos-anoncred-00.txt 1080 1081 [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 1082 Tickets for Application Servers (PKTAPP). 1083 draft-ietf-cat-pktapp-00.txt 1084 1085 [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 1086 Using Public Key Cryptography. Symposium On Network and Distributed 1087 System Security, 1997. 1088 1089 [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 1090 Protocol. In Proceedings of the USENIX Workshop on Electronic 1091 Commerce, July 1995. 1092 1093 [8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL 1094 Protocol, Version 3.0 - IETF Draft. 1095 1096 [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 1097 Distributed Systems. In Proceedings of the 13th International 1098 Conference on Distributed Computing Systems, May 1993. 1099 1100 [10] ITU-T (formerly CCITT) Information technology - Open Systems 1101 Interconnection - The Directory: Authentication Framework 1102 Recommendation X.509 ISO/IEC 9594-8 1103 1104 [11] R. Hously. Cryptographic Message Syntax. 1105 draft-ietf-smime-cms-04.txt, March 1998. 1106 1107 [12] PKCS #7: Cryptographic Message Syntax Standard, 1108 An RSA Laboratories Technical Note Version 1.5 1109 Revised November 1, 1993 1110 1111 [13] Ron Rivest, MIT Laboratory for Computer Science and 1112 RSA Data Security, Inc. A Description of the RC2(r) Encryption 1113 Algorithm, November 1997. 1114 1115 [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 1116 Protocol (v3): UTF-8 String Representation of Distinguished Names. 1117 Request for Comments 2253. 1118 1119 [15] PKCS #6: Cryptographic Message Syntax Standard, 1120 An RSA Laboratories Technical Note Version 1.5 1121 Revised November 1, 1993 1122 1123 11247. Patent Issues 1125 1126 The private key storage and retrieval process described in Section 1127 3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie 1128 Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of 1129 Digital Corporation). At this time, inquiries into this patent are 1130 inconclusive. We solicit discussion from any party who can illuminate 1131 the coverage of this particular patent. 1132 1133 11348. Acknowledgements 1135 1136 Some of the ideas on which this proposal is based arose during 1137 discussions over several years between members of the SAAG, the IETF 1138 CAT working group, and the PSRG, regarding integration of Kerberos 1139 and SPX. Some ideas have also been drawn from the DASS system. 1140 These changes are by no means endorsed by these groups. This is an 1141 attempt to revive some of the goals of those groups, and this 1142 proposal approaches those goals primarily from the Kerberos 1143 perspective. Lastly, comments from groups working on similar ideas 1144 in DCE have been invaluable. 1145 1146 11479. Expiration Date 1148 1149 This draft expires May 15, 1999. 1150 1151 115210. Authors 1153 1154 Brian Tung 1155 Clifford Neuman 1156 USC Information Sciences Institute 1157 4676 Admiralty Way Suite 1001 1158 Marina del Rey CA 90292-6695 1159 Phone: +1 310 822 1511 1160 E-mail: {brian, bcn}@isi.edu 1161 1162 John Wray 1163 Digital Equipment Corporation 1164 550 King Street, LKG2-2/Z7 1165 Littleton, MA 01460 1166 Phone: +1 508 486 5210 1167 E-mail: wray@tuxedo.enet.dec.com 1168 1169 Ari Medvinsky 1170 Matthew Hur 1171 Sasha Medvinsky 1172 CyberSafe Corporation 1173 1605 NW Sammamish Road Suite 310 1174 Issaquah WA 98027-5378 1175 Phone: +1 206 391 6000 1176 E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com 1177 1178 Jonathan Trostle 1179 170 W. Tasman Dr. 1180 San Jose, CA 95134 1181 E-mail: jtrostle@cisco.com 1182