1INTERNET-DRAFT Clifford Neuman 2draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung 3Updates: RFC 1510 ISI 4expires September 30, 1997 John Wray 5 Digital Equipment Corporation 6 Ari Medvinsky 7 Matthew Hur 8 CyberSafe Corporation 9 Jonathan Trostle 10 Novell 11 12 13 Public Key Cryptography for Initial Authentication in Kerberos 14 15 160. Status Of this Memo 17 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 28 29 To learn the current status of any Internet-Draft, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 34 35 The distribution of this memo is unlimited. It is filed as 36 draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30, 37 1997. Please send comments to the authors. 38 39 401. Abstract 41 42 This document defines extensions (PKINIT) to the Kerberos protocol 43 specification (RFC 1510 [1]) to provide a method for using public 44 key cryptography during initial authentication. The methods 45 defined specify the ways in which preauthentication data fields and 46 error data fields in Kerberos messages are to be used to transport 47 public key data. 48 49 502. Introduction 51 52 The popularity of public key cryptography has produced a desire for 53 its support in Kerberos [2]. The advantages provided by public key 54 cryptography include simplified key management (from the Kerberos 55 perspective) and the ability to leverage existing and developing 56 public key certification infrastructures. 57 58 Public key cryptography can be integrated into Kerberos in a number 59 of ways. One is to to associate a key pair with each realm, which 60 can then be used to facilitate cross-realm authentication; this is 61 the topic of another draft proposal. Another way is to allow users 62 with public key certificates to use them in initial authentication. 63 This is the concern of the current document. 64 65 One of the guiding principles in the design of PKINIT is that 66 changes should be as minimal as possible. As a result, the basic 67 mechanism of PKINIT is as follows: The user sends a request to the 68 KDC as before, except that if that user is to use public key 69 cryptography in the initial authentication step, his certificate 70 accompanies the initial request, in the preauthentication fields. 71 72 Upon receipt of this request, the KDC verifies the certificate and 73 issues a ticket granting ticket (TGT) as before, except that instead 74 of being encrypted in the user's long-term key (which is derived 75 from a password), it is encrypted in a randomly-generated key. This 76 random key is in turn encrypted using the public key certificate 77 that came with the request and signed using the KDC's signature key, 78 and accompanies the reply, in the preauthentication fields. 79 80 PKINIT also allows for users with only digital signature keys to 81 authenticate using those keys, and for users to store and retrieve 82 private keys on the KDC. 83 84 The PKINIT specification may also be used for direct peer to peer 85 authentication without contacting a central KDC. This application 86 of PKINIT is described in PKTAPP [4] and is based on concepts 87 introduced in [5, 6]. For direct client-to-server authentication, 88 the client uses PKINIT to authenticate to the end server (instead 89 of a central KDC), which then issues a ticket for itself. This 90 approach has an advantage over SSL [7] in that the server does not 91 need to save state (cache session keys). Furthermore, an 92 additional benefit is that Kerberos tickets can facilitate 93 delegation (see [8]). 94 95 963. Proposed Extensions 97 98 This section describes extensions to RFC 1510 for supporting the 99 use of public key cryptography in the initial request for a ticket 100 granting ticket (TGT). 101 102 In summary, the following changes to RFC 1510 are proposed: 103 104 --> Users may authenticate using either a public key pair or a 105 conventional (symmetric) key. If public key cryptography is 106 used, public key data is transported in preauthentication 107 data fields to help establish identity. 108 --> Users may store private keys on the KDC for retrieval during 109 Kerberos initial authentication. 110 111 This proposal addresses two ways that users may use public key 112 cryptography for initial authentication. Users may present public 113 key certificates, or they may generate their own session key, 114 signed by their digital signature key. In either case, the end 115 result is that the user obtains an ordinary TGT that may be used for 116 subsequent authentication, with such authentication using only 117 conventional cryptography. 118 119 Section 3.1 provides definitions to help specify message formats. 120 Section 3.2 and 3.3 describe the extensions for the two initial 121 authentication methods. Section 3.3 describes a way for the user to 122 store and retrieve his private key on the KDC. 123 124 1253.1. Definitions 126 127 Hash and encryption types will be specified using ENCTYPE tags; we 128 propose the addition of the following types: 129 130 #define ENCTYPE_SIGN_DSA_GENERATE 0x0011 131 #define ENCTYPE_SIGN_DSA_VERIFY 0x0012 132 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 133 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 134 135 allowing further signature types to be defined in the range 0x0011 136 through 0x001f, and further encryption types to be defined in the 137 range 0x0021 through 0x002f. 138 139 The extensions involve new preauthentication fields. The 140 preauthentication data types are in the range 17 through 21. 141 These values are also specified along with their corresponding 142 ASN.1 definition. 143 144 #define PA-PK-AS-REQ 17 145 #define PA-PK-AS-REP 18 146 #define PA-PK-AS-SIGN 19 147 #define PA-PK-KEY-REQ 20 148 #define PA-PK-KEY-REP 21 149 150 The extensions also involve new error types. The new error types 151 are in the range 227 through 229. They are: 152 153 #define KDC_ERROR_CLIENT_NOT_TRUSTED 227 154 #define KDC_ERROR_KDC_NOT_TRUSTED 228 155 #define KDC_ERROR_INVALID_SIG 229 156 157 In the exposition below, we use the following terms: encryption key, 158 decryption key, signature key, verification key. It should be 159 understood that encryption and verification keys are essentially 160 public keys, and decryption and signature keys are essentially 161 private keys. The fact that they are logically distinct does 162 not preclude the assignment of bitwise identical keys. 163 164 1653.2. Standard Public Key Authentication 166 167 Implementation of the changes in this section is REQUIRED for 168 compliance with pk-init. 169 170 It is assumed that all public keys are signed by some certification 171 authority (CA). The initial authentication request is sent as per 172 RFC 1510, except that a preauthentication field containing data 173 signed by the user's signature key accompanies the request: 174 175 PA-PK-AS-REQ ::- SEQUENCE { 176 -- PA TYPE 17 177 signedPKAuth [0] SignedPKAuthenticator, 178 userCert [1] SEQUENCE OF Certificate OPTIONAL, 179 -- the user's certificate 180 -- optionally followed by that 181 -- certificate's certifier chain 182 trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL 183 -- CAs that the client trusts 184 } 185 186 SignedPKAuthenticator ::= SEQUENCE { 187 pkAuth [0] PKAuthenticator, 188 pkAuthSig [1] Signature, 189 -- of pkAuth 190 -- using user's signature key 191 } 192 193 PKAuthenticator ::= SEQUENCE { 194 cusec [0] INTEGER, 195 -- for replay prevention 196 ctime [1] KerberosTime, 197 -- for replay prevention 198 nonce [2] INTEGER, 199 -- binds response to this request 200 kdcName [3] PrincipalName, 201 clientPubValue [4] SubjectPublicKeyInfo OPTIONAL, 202 -- for Diffie-Hellman algorithm 203 } 204 205 Signature ::= SEQUENCE { 206 signedHash [0] EncryptedData 207 -- of type Checksum 208 -- encrypted under signature key 209 } 210 211 Checksum ::= SEQUENCE { 212 cksumtype [0] INTEGER, 213 checksum [1] OCTET STRING 214 } -- as specified by RFC 1510 215 216 SubjectPublicKeyInfo ::= SEQUENCE { 217 algorithm [0] algorithmIdentifier, 218 subjectPublicKey [1] BIT STRING 219 } -- as specified by the X.509 recommendation [9] 220 221 Certificate ::= SEQUENCE { 222 CertType [0] INTEGER, 223 -- type of certificate 224 -- 1 = X.509v3 (DER encoding) 225 -- 2 = PGP (per PGP draft) 226 CertData [1] OCTET STRING 227 -- actual certificate 228 -- type determined by CertType 229 } 230 231 Note: If the signature uses RSA keys, then it is to be performed 232 as per PKCS #1. 233 234 The PKAuthenticator carries information to foil replay attacks, 235 to bind the request and response, and to optionally pass the 236 client's Diffie-Hellman public value (i.e. for using DSA in 237 combination with Diffie-Hellman). The PKAuthenticator is signed 238 with the private key corresponding to the public key in the 239 certificate found in userCert (or cached by the KDC). 240 241 In the PKAuthenticator, the client may specify the KDC name in one 242 of two ways: 1) a Kerberos principal name, or 2) the name in the 243 KDC's certificate (e.g., an X.500 name, or a PGP name). Note that 244 case #1 requires that the certificate name and the Kerberos principal 245 name be bound together (e.g., via an X.509v3 extension). 246 247 The userCert field is a sequence of certificates, the first of which 248 must be the user's public key certificate. Any subsequent 249 certificates will be certificates of the certifiers of the user's 250 certificate. These cerificates may be used by the KDC to verify the 251 user's public key. This field is empty if the KDC already has the 252 user's certifcate. 253 254 The trustedCertifiers field contains a list of certification 255 authorities trusted by the client, in the case that the client does 256 not possess the KDC's public key certificate. 257 258 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 259 type, the KDC attempts to verify the user's certificate chain 260 (userCert), if one is provided in the request. This is done by 261 verifying the certification path against the KDC's policy of 262 legitimate certifiers. This may be based on a certification 263 hierarchy, or it may be simply a list of recognized certifiers in a 264 system like PGP. If the certification path does not match one of 265 the KDC's trusted certifiers, the KDC sends back an error message of 266 type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data 267 field a list of its own trusted certifiers, upon which the client 268 resends the request. 269 270 If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC 271 verifies that it has a certificate issued by one of the certifiers 272 trusted by the client. If it does not have a suitable certificate, 273 the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED 274 to the client. 275 276 If a trust relationship exists, the KDC then verifies the client's 277 signature on PKAuthenticator. If that fails, the KDC returns an 278 error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC 279 uses the timestamp in the PKAuthenticator to assure that the request 280 is not a replay. The KDC also verifies that its name is specified 281 in PKAuthenticator. 282 283 Assuming no errors, the KDC replies as per RFC 1510, except that it 284 encrypts the reply not with the user's key, but with a random key 285 generated only for this particular response. This random key 286 is sealed in the preauthentication field: 287 288 PA-PK-AS-REP ::= SEQUENCE { 289 -- PA TYPE 18 290 kdcCert [0] SEQUENCE OF Certificate OPTIONAL, 291 -- the KDC's certificate 292 -- optionally followed by that 293 -- certificate's certifier chain 294 encPaReply [1] EncryptedData, 295 -- of type PaReply 296 -- using either the client public 297 -- key or the Diffie-Hellman key 298 -- specified by SignedDHPublicValue 299 signedDHPublicValue [2] SignedDHPublicValue OPTIONAL 300 } 301 302 303 PaReply ::= SEQUENCE { 304 replyEncKeyPack [0] ReplyEncKeyPack, 305 replyEncKeyPackSig [1] Signature, 306 -- of replyEncKeyPack 307 -- using KDC's signature key 308 } 309 310 ReplyEncKeyPack ::= SEQUENCE { 311 replyEncKey [0] EncryptionKey, 312 -- used to encrypt main reply 313 nonce [1] INTEGER 314 -- binds response to the request 315 -- passed in the PKAuthenticator 316 } 317 318 SignedDHPublicValue ::= SEQUENCE { 319 dhPublicValue [0] SubjectPublicKeyInfo, 320 dhPublicValueSig [1] Signature 321 -- of dhPublicValue 322 -- using KDC's signature key 323 } 324 325 The kdcCert field is a sequence of certificates, the first of which 326 must have as its root certifier one of the certifiers sent to the 327 KDC in the PA-PK-AS-REQ. Any subsequent certificates will be 328 certificates of the certifiers of the KDC's certificate. These 329 cerificates may be used by the client to verify the KDC's public 330 key. This field is empty if the client did not send to the KDC a 331 list of trusted certifiers (the trustedCertifiers field was empty). 332 333 Since each certifier in the certification path of a user's 334 certificate is essentially a separate realm, the name of each 335 certifier shall be added to the transited field of the ticket. The 336 format of these realm names shall follow the naming constraints set 337 forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will 338 require new nametypes to be defined for PGP certifiers and other 339 types of realms as they arise. 340 341 The KDC's certificate must bind the public key to a name derivable 342 from the name of the realm for that KDC. The client then extracts 343 the random key used to encrypt the main reply. This random key (in 344 encPaReply) is encrypted with either the client's public key or 345 with a key derived from the DH values exchanged between the client 346 and the KDC. 347 348 3493.3. Digital Signature 350 351 Implementation of the changes in this section are OPTIONAL for 352 compliance with pk-init. 353 354 We offer this option with the warning that it requires the client to 355 generate a random key; the client may not be able to guarantee the 356 same level of randomness as the KDC. 357 358 If the user registered a digital signature key with the KDC instead 359 of an encryption key, then a separate exchange must be used. The 360 client sends a request for a TGT as usual, except that it (rather 361 than the KDC) generates the random key that will be used to encrypt 362 the KDC response. This key is sent to the KDC along with the 363 request in a preauthentication field: 364 365 PA-PK-AS-SIGN ::= SEQUENCE { 366 -- PA TYPE 19 367 encSignedKeyPack [0] EncryptedData 368 -- of SignedKeyPack 369 -- using the KDC's public key 370 } 371 372 SignedKeyPack ::= SEQUENCE { 373 signedKey [0] KeyPack, 374 signedKeyAuth [1] PKAuthenticator, 375 signedKeySig [2] Signature 376 -- of signedKey.signedKeyAuth 377 -- using user's signature key 378 } 379 380 KeyPack ::= SEQUENCE { 381 randomKey [0] EncryptionKey, 382 -- will be used to encrypt reply 383 nonce [1] INTEGER 384 } 385 386 where the nonce is copied from the request. 387 388 Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies 389 the randomKey. It then replies as per RFC 1510, except that the 390 reply is encrypted not with a password-derived user key, but with 391 the randomKey sent in the request. Since the client already knows 392 this key, there is no need to accompany the reply with an extra 393 preauthentication field. The transited field of the ticket should 394 specify the certification path as described in Section 3.2. 395 396 3973.4. Retrieving the Private Key From the KDC 398 399 Implementation of the changes in this section is RECOMMENDED for 400 compliance with pk-init. 401 402 When the user's private key is not stored local to the user, he may 403 choose to store the private key (normally encrypted using a 404 password-derived key) on the KDC. We provide this option to present 405 the user with an alternative to storing the private key on local 406 disk at each machine where he expects to authenticate himself using 407 pk-init. It should be noted that it replaces the added risk of 408 long-term storage of the private key on possibly many workstations 409 with the added risk of storing the private key on the KDC in a 410 form vulnerable to brute-force attack. 411 412 In order to obtain a private key, the client includes a 413 preauthentication field with the AS-REQ message: 414 415 PA-PK-KEY-REQ ::= SEQUENCE { 416 -- PA TYPE 20 417 patimestamp [0] KerberosTime OPTIONAL, 418 -- used to address replay attacks. 419 pausec [1] INTEGER OPTIONAL, 420 -- used to address replay attacks. 421 nonce [2] INTEGER, 422 -- binds the reply to this request 423 privkeyID [3] SEQUENCE OF KeyID OPTIONAL 424 -- constructed as a hash of 425 -- public key corresponding to 426 -- desired private key 427 } 428 429 KeyID ::= SEQUENCE { 430 KeyIdentifier [0] OCTET STRING 431 } 432 433 The client may request a specific private key by sending the 434 corresponding ID. If this field is left empty, then all 435 private keys are returned. 436 437 If all checks out, the KDC responds as described in the above 438 sections, except that an additional preauthentication field, 439 containing the user's private key, accompanies the reply: 440 441 PA-PK-KEY-REP ::= SEQUENCE { 442 -- PA TYPE 21 443 nonce [0] INTEGER, 444 -- binds the reply to the request 445 KeyData [1] SEQUENCE OF KeyPair 446 } 447 448 KeyPair ::= SEQUENCE { 449 privKeyID [0] OCTET STRING, 450 -- corresponding to encPrivKey 451 encPrivKey [1] OCTET STRING 452 } 453 454 4553.4.1. Additional Protection of Retrieved Private Keys 456 457 We solicit discussion on the following proposal: that the client may 458 optionally include in its request additional data to encrypt the 459 private key, which is currently only protected by the user's 460 password. One possibility is that the client might generate a 461 random string of bits, encrypt it with the public key of the KDC (as 462 in the SignedKeyPack, but with an ordinary OCTET STRING in place of 463 an EncryptionKey), and include this with the request. The KDC then 464 XORs each returned key with this random bit string. (If the bit 465 string is too short, the KDC could either return an error, or XOR 466 the returned key with a repetition of the bit string.) 467 468 In order to make this work, additional means of preauthentication 469 need to be devised in order to prevent attackers from simply 470 inserting their own bit string. One way to do this is to store 471 a hash of the password-derived key (the one used to encrypt the 472 private key). This hash is then used in turn to derive a second 473 key (called the hash-key); the hash-key is used to encrypt an ASN.1 474 structure containing the generated bit string and a nonce value 475 that binds it to the request. 476 477 Since the KDC possesses the hash, it can generate the hash-key and 478 verify this (weaker) preauthentication, and yet cannot reproduce 479 the private key itself, since the hash is a one-way function. 480 481 4824. Logistics and Policy Issues 483 484 We solicit discussion on how clients and KDCs should be configured 485 in order to determine which of the options described above (if any) 486 should be used. One possibility is to set the user's database 487 record to indicate that authentication is to use public key 488 cryptography; this will not work, however, in the event that the 489 client needs to know before making the initial request. 490 4915. Compatibility with One-Time Passcodes 492 493 We solicit discussion on how the protocol changes proposed in this 494 draft will interact with the proposed use of one-time passcodes 495 discussed in draft-ietf-cat-kerberos-passwords-00.txt. 496 497 4986. Strength of Cryptographic Schemes 499 500 In light of recent findings on the strength of MD5 and DES, 501 we solicit discussion on which encryption types to incorporate 502 into the protocol changes. 503 504 5057. Bibliography 506 507 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 508 Service (V5). Request for Comments: 1510 509 510 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 511 for Computer Networks, IEEE Communications, 32(9):33-38. 512 September 1994. 513 514 [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to 515 Transport Layer Security (TLS). 516 draft-ietf-tls-kerb-cipher-suites-00.txt 517 518 [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing 519 Tickets for Application Servers (PKTAPP). 520 draft-ietf-cat-pktapp-00.txt 521 522 [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using 523 Public Key Cryptography. Symposium On Network and Distributed System 524 Security, 1997. 525 526 [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 527 Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, 528 July 1995. 529 530 [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. 531 The SSL Protocol, Version 3.0 - IETF Draft. 532 533 [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 534 Distributed Systems. In Proceedings of the 13th International 535 Conference on Distributed Computing Systems, May 1993 536 537 [9] ITU-T (formerly CCITT) 538 Information technology - Open Systems Interconnection - 539 The Directory: Authentication Framework Recommendation X.509 540 ISO/IEC 9594-8 541 542 5438. Acknowledgements 544 545 Some of the ideas on which this proposal is based arose during 546 discussions over several years between members of the SAAG, the IETF 547 CAT working group, and the PSRG, regarding integration of Kerberos 548 and SPX. Some ideas have also been drawn from the DASS system. 549 These changes are by no means endorsed by these groups. This is an 550 attempt to revive some of the goals of those groups, and this 551 proposal approaches those goals primarily from the Kerberos 552 perspective. Lastly, comments from groups working on similar ideas 553 in DCE have been invaluable. 554 555 5569. Expiration Date 557 558 This draft expires September 30, 1997. 559 560 56110. Authors 562 563 Clifford Neuman 564 Brian Tung 565 USC Information Sciences Institute 566 4676 Admiralty Way Suite 1001 567 Marina del Rey CA 90292-6695 568 Phone: +1 310 822 1511 569 E-mail: {bcn, brian}@isi.edu 570 571 John Wray 572 Digital Equipment Corporation 573 550 King Street, LKG2-2/Z7 574 Littleton, MA 01460 575 Phone: +1 508 486 5210 576 E-mail: wray@tuxedo.enet.dec.com 577 578 Ari Medvinsky 579 Matthew Hur 580 CyberSafe Corporation 581 1605 NW Sammamish Road Suite 310 582 Issaquah WA 98027-5378 583 Phone: +1 206 391 6000 584 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com 585 586 Jonathan Trostle 587 Novell 588 E-mail: jonathan.trostle@novell.com 589