1INTERNET-DRAFT Clifford Neuman 2draft-ietf-cat-kerberos-pk-init-02.txt Brian Tung 3Updates: RFC 1510 ISI 4expires April 19, 1997 John Wray 5 Digital Equipment Corporation 6 Jonathan Trostle 7 CyberSafe Corporation 8 9 10 Public Key Cryptography for Initial Authentication in Kerberos 11 12 130. Status Of this Memo 14 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other docu- 22 ments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as ``work in pro- 24 gress.'' 25 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 28 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 31 32 The distribution of this memo is unlimited. It is filed as 33 draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997. 34 Please send comments to the authors. 35 36 371. Abstract 38 39 This document defines extensions to the Kerberos protocol 40 specification (RFC 1510, "The Kerberos Network Authentication 41 Service (V5)", September 1993) to provide a method for using public 42 key cryptography during initial authentication. The method defined 43 specifies the way in which preauthentication data fields and error 44 data fields in Kerberos messages are to be used to transport public 45 key data. 46 472. Motivation 48 49 Public key cryptography presents a means by which a principal may 50 demonstrate possession of a key, without ever having divulged this 51 key to anyone else. In conventional cryptography, the encryption 52 key and decryption key are either identical or can easily be 53 derived from one another. In public key cryptography, however, 54 neither the public key nor the private key can be derived from the 55 other (although the private key RECORD may include the information 56 required to generate BOTH keys). Hence, a message encrypted with a 57 public key is private, since only the person possessing the private 58 key can decrypt it; similarly, someone possessing the private key 59 can also encrypt a message, thus providing a digital signature. 60 61 Furthermore, conventional keys are often derived from passwords, so 62 messages encrypted with these keys are susceptible to dictionary 63 attacks, whereas public key pairs are generated from a 64 pseudo-random number sequence. While it is true that messages 65 encrypted using public key cryptography are actually encrypted with 66 a conventional secret key, which is in turn encrypted using the 67 public key pair, the secret key is also randomly generated and is 68 hence not vulnerable to a dictionary attack. 69 70 The advantages provided by public key cryptography have produced a 71 demand for its integration into the Kerberos authentication 72 protocol. The public key integration into Kerberos described in 73 this document has three goals. 74 75 First, by allowing users to register public keys with the KDC, the 76 KDC can be recovered much more easily in the event it is 77 compromised. With Kerberos as it currently stands, compromise of 78 the KDC is disastrous. All keys become known by the attacker and 79 all keys must be changed. Second, we allow users that have public 80 key certificates signed by outside authorities to obtain Kerberos 81 credentials for access to Kerberized services. Third, we obtain the 82 above benefits while maintaining the performance advantages of 83 Kerberos over protocols that use only public key authentication. 84 85 If users register public keys, compromise of the KDC does not 86 divulge their private key. Compromise of security on the KDC is 87 still a problem, since an attacker can impersonate any user by 88 creating a ticket granting ticket for the user. When the compromise 89 is detected, the KDC can be cleaned up and restored from backup 90 media and loaded with a backup private/public key pair. Keys for 91 application servers are conventional symmetric keys and must be 92 changed. 93 94 Note: If a user stores his private key, in an encrypted form, on 95 the KDC, then it may be desirable to change the key pair, since the 96 private key is encrypted using a symmetric key derived from a 97 password (as described below), and can therefore be vulnerable to 98 dictionary attack if a good password policy is not used. 99 Alternatively, if the encrypting symmetric key has 56 bits, then it 100 may also be desirable to change the key pair after a short period 101 due to the short key length. The KDC does not have access to the 102 user's unencrypted private key. 103 104 There are two important areas where public key cryptography will 105 have immediate use: in the initial authentication of users 106 registered with the KDC or using public key certificates from 107 outside authorities, and to establish inter-realm keys for 108 cross-realm authentication. This memo describes a method by which 109 the first of these can be done. The second case will be the topic 110 for a separate proposal. 111 112 Some of the ideas on which this proposal is based arose during 113 discussions over several years between members of the SAAG, the 114 IETF-CAT working group, and the PSRG, regarding integration of 115 Kerberos and SPX. Some ideas are drawn from the DASS system, and 116 similar extensions have been discussed for use in DCE. These 117 changes are by no means endorsed by these groups. This is an 118 attempt to revive some of the goals of that group, and the 119 proposal approaches those goals primarily from the Kerberos 120 perspective. 121 1223. Initial authentication of users with public keys 123 124 This section describes the extensions to Version 5 of the Kerberos 125 protocol that will support the use of public key cryptography by 126 users in the initial request for a ticket granting ticket. 127 128 Roughly speaking, the following changes to RFC 1510 are proposed: 129 Users can initially authenticate using public key or conventional 130 (symmetric key) cryptography. After a KDC compromise, the KDC 131 replies with an error message that informs the client of the new 132 KDC public backup key. Users must authenticate using public key 133 cryptography in response to the error message. If applicable, the 134 client generates the new user secret key at this point as well. 135 136 Public key initial authentication is performed using either the 137 RSA encryption or Diffie Hellman public key algorithms. There is 138 also an option to allow the user to store his/her private key 139 encrypted in the user password in the KDC database; this option 140 solves the problem of transporting the user private key to 141 different workstations. The combination of this option and the 142 provision for conventional symmetric key authentication allows 143 organizations to smoothly migrate to public key cryptography. 144 145 This proposal will allow users either to use keys registered 146 directly with the KDC, or to use keys already registered for use 147 with X.509, PEM, or PGP, to obtain Kerberos credentials. These 148 credentials can then be used, as before, with application servers 149 supporting Kerberos. Use of public key cryptography will not be a 150 requirement for Kerberos, but if one's organization runs a KDC 151 supporting public key, then users may choose to be registered with 152 a public key pair, instead of or in addition to the current secret 153 key. 154 155 The application request and response between Kerberos clients and 156 application servers will continue to be based on conventional 157 cryptography, or will be converted to use user-to-user 158 authentication. There are performance issues and other reasons 159 that servers may be better off using conventional cryptography. 160 For this proposal, we feel that 80 percent of the benefits of 161 integrating public key with Kerberos can be attained for 20 percent 162 of the effort, by addressing only initial authentication. This 163 proposal does not preclude separate extensions. 164 165 With these changes, users will be able to register public keys, 166 only in realms that support public key, but they will still be able 167 to perform initial authentication from a client that does not 168 support public key. They will be able to use services registered in 169 any realm. Furthermore, users registered with conventional keys 170 will be able to use any client. 171 172 This proposal addresses three ways in which users may use public 173 key cryptography for initial authentication with Kerberos, with 174 minimal change to the existing protocol. Users may register keys 175 directly with the KDC, or they may present certificates by outside 176 certification authorities (or certifications by other users) 177 attesting to the association of the public key with the named user. 178 In both cases, the end result is that the user obtains a 179 conventional ticket granting ticket or conventional server ticket 180 that may be used for subsequent authentication, with such 181 subsequent authentication using only conventional cryptography. 182 183 Additionally, users may also register a digital signature 184 verification key with the KDC. We provide this option for the 185 licensing benefits, as well as a simpler variant of the initial 186 authentication exchange. However, this option relies on the client 187 to generate random keys. 188 189 We first consider the case where the user's key is registered with 190 the KDC. 191 1923.1 Definitions 193 194 Before we proceed, we will lay some groundwork definitions for 195 encryption and signatures. We propose the following definitions 196 of signature and encryption modes (and their corresponding values 197 on the wire): 198 199 #define ENCTYPE_SIGN_MD5_RSA 0x0011 200 201 #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 202 #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 203 204 allowing further modes to be defined accordingly. 205 206 In the exposition below, we will use the notation E (T, K) to 207 denote the encryption of data T, with key (or parameters) K. 208 209 If E is ENCTYPE_SIGN_MD5_RSA, then 210 211 E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)} 212 213 If E is ENCTYPE_ENCRYPT_RSA_PRIV, then 214 215 E (T, K) = RSAEncryptPrivate (T, K) 216 217 Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then 218 219 E (T, K) = RSAEncryptPublic (T, K) 220 221 2223.2 Initial request for user registered with public key on KDC 223 224 In this scenario it is assumed that the user is registered with a 225 public key on the KDC. The user's private key may be held by the 226 user, or it may be stored on the KDC, encrypted so that it cannot 227 be used by the KDC. 228 2293.2.1 User's private key is stored locally 230 231 Implementation of the changes in this section is REQUIRED. 232 233 In this section, we present the basic Kerberos V5 pk-init protocol 234 that all conforming implementations must support. The key features 235 of the protocol are: (1) easy, automatic (for the clients) recovery 236 after a KDC compromise, (2) the ability for a realm to support a 237 mix of old and new Kerberos V5 clients with the new clients being a 238 mix of both public key and symmetric key configured clients, and 239 (3) support for Diffie-Hellman (DH) key exchange as well as RSA 240 public key encryption. The benefit of having new clients being able 241 to use either symmetric key or public key initial authentication is 242 that it allows an organization to roll out the new clients as 243 rapidly as possible without having to be concerned about the need 244 to purchase additional hardware to support the CPU intensive public 245 key cryptographic operations. 246 247 In order to give a brief overview of the four protocols in this 248 section, we now give diagrams of the protocols. We denote 249 encryption of message M with key K by {M}K and the signature of 250 message M with key K by [M]K. All messages from the KDC to the 251 client are AS_REP messages unless denoted otherwise; similarly, all 252 messages from the client to the KDC are AS_REQ messages unless 253 denoted otherwise. Since only the padata fields are affected by 254 this specification in the AS_REQ and AS_REP messages, we do not 255 show the other fields. We first show the RSA encryption option in 256 normal mode: 257 258 certifier list, [cksum, time, nonce, kdcRealm, 259 kdcName]User PrivateKey 260 C ------------------------------------------------------> KDC 261 262 list of cert's, {[encReplyKey, nonce]KDC privkey} 263 EncReplyTmpKey, {EncReplyTmpKey}Userpubkey 264 C <------------------------------------------------------ KDC 265 266 267 We now show RSA encryption in recovery mode: 268 269 certifier list, [cksum, time, nonce, kdcRealm, 270 kdcName]User PrivateKey 271 C ------------------------------------------------------> KDC 272 273 274 KRB_ERROR (error code KDC_RECOVERY_NEEDED) 275 error data: [nonce, algID (RSA), 276 KDC PublicKey Kvno and PublicKey, KDC Salt] 277 Signed with KDC PrivateKey 278 C <------------------------------------------------------ KDC 279 280 281 certifier list, [cksum, time, nonce, kdcRealm, kdcName, 282 {newUserSymmKey, nonce}KDC public key]User PrivateKey 283 C ------------------------------------------------------> KDC 284 285 286 list of cert's, {[encReplyKey, nonce]KDC privkey} 287 EncReplyTmpKey, {EncReplyTmpKey}Userpubkey 288 C <------------------------------------------------------ KDC 289 290 Next, we show Diffie Hellman in normal mode: 291 292 certifier list, [cksum, time, nonce, kdcRealm, kdcName, 293 User DH public parameter]User PrivateKey 294 C ------------------------------------------------------> KDC 295 296 297 list of cert's, {encReplyKey, nonce}DH shared symmetric 298 key, [KDC DH public parameter]KDC Private Key 299 C <------------------------------------------------------ KDC 300 301 302 Finally, we show Diffie Hellman in recovery mode: 303 304 certifier list, [cksum, time, nonce, kdcRealm, kdcName, 305 User DH public parameter]User PrivateKey 306 C ------------------------------------------------------> KDC 307 308 309 KRB_ERROR (error code KDC_RECOVERY_NEEDED) 310 error data: [nonce, algID (DH), KDC DH public 311 parameter, KDC DH ID, KDC PublicKey 312 Kvno and PublicKey, KDC Salt] 313 Signed with KDC PrivateKey 314 C <------------------------------------------------------ KDC 315 316 317 certifier list, [cksum, time, nonce, kdcRealm, 318 kdcName, User DH public parameter, {newUserSymmKey, 319 nonce}DH shared key, KDC DH ID]User PrivateKey 320 C ------------------------------------------------------> KDC 321 322 323 list of cert's, {encReplyKey, nonce}DH shared 324 symmetric key 325 C <------------------------------------------------------ KDC 326 327 328 329 If the user stores his private key locally, the initial request 330 to the KDC for a ticket granting ticket proceeds according to 331 RFC 1510, except that a preauthentication field containing a 332 nonce signed by the user's private key is included. The 333 preauthentication field may also include a list of the root 334 certifiers trusted by the user. 335 336 PA-PK-AS-ROOT ::= SEQUENCE { 337 rootCert[0] SEQUENCE OF OCTET STRING, 338 signedAuth[1] SignedPKAuthenticator 339 } 340 341 SignedPKAuthenticator ::= SEQUENCE { 342 authent[0] PKAuthenticator, 343 authentSig[1] Signature 344 } 345 346 PKAuthenticator ::= SEQUENCE { 347 cksum[0] Checksum OPTIONAL, 348 cusec[1] INTEGER, 349 ctime[2] KerberosTime, 350 nonce[3] INTEGER, 351 kdcRealm[4] Realm, 352 kdcName[5] PrincipalName, 353 clientPubValue[6] SubjectPublicKeyInfo OPTIONAL, 354 -- DH algorithm 355 recoveryData[7] RecoveryData OPTIONAL 356 -- Recovery Alg. 357 } 358 359 RecoveryData ::= SEQUENCE { 360 clientRecovData[0] ClientRecovData, 361 kdcPubValueId[1] INTEGER OPTIONAL 362 -- DH algorithm, copied 363 -- from KDC response 364 } 365 366 ClientRecovData ::= CHOICE { 367 newPrincKey[0] EncryptedData, -- EncPaPkAsRoot 368 -- encrypted with 369 -- either KDC 370 -- public key or 371 -- DH shared key 372 recovDoneFlag[1] INTEGER -- let KDC know that 373 -- recovery is done 374 -- when user uses a 375 -- mix of clients or 376 -- does not want to 377 -- keep a symmetric 378 -- key in the database 379 } 380 381 EncPaPkAsRoot ::= SEQUENCE { 382 newSymmKey[0] EncryptionKey -- the principal's new 383 -- symmetric key 384 nonce[1] INTEGER -- the same nonce as 385 -- the one in the 386 -- PKAuthenticator 387 } 388 389 Signature ::= SEQUENCE { 390 sigType[0] INTEGER, 391 kvno[1] INTEGER OPTIONAL, 392 sigHash[2] OCTET STRING 393 } 394 395 Notationally, sigHash is then 396 397 sigType (authent, userPrivateKey) 398 399 where userPrivateKey is the user's private key (corresponding to the 400 public key held in the user's database record). Valid sigTypes are 401 thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect 402 that other types may be listed (and given on-the-wire values between 403 0x0011 and 0x001f). 404 405 The format of each certificate depends on the particular service 406 used. (Alternatively, the KDC could send, with its reply, a 407 sequence of certifications (see below), but since the KDC is likely 408 to have more certifications than users have trusted root certifiers, 409 we have chosen the first method.) In the event that the client 410 believes it already possesses the current public key of the KDC, a 411 zero-length root-cert field is sent. 412 413 The fields in the signed authenticator are the same as those in the 414 Kerberos authenticator; in addition, we include a client-generated 415 nonce, and the name of the KDC. The structure is itself signed 416 using the user's private key corresponding to the public key 417 registered with the KDC. We include the newSymmKey field so clients 418 can generate a new symmetric key (for users, this key is based on 419 a password and a salt value generated by the KDC) and 420 confidentially send this key to the KDC during the recovery phase. 421 422 We now describe the recovery phase of the protocol. There is a bit 423 associated with each principal in the database indicating whether 424 recovery for that principal is necessary. After a KDC compromise, 425 the KDC software is reloaded from backup media and a new backup 426 KDC public/private pair is generated. The public half of this pair 427 is then either made available to the KDC, or given to the 428 appropriate certification authorities for certification. The private 429 half is not made available to the KDC until after the next 430 compromise clean-up. If clients are maintaining a copy of the KDC 431 public key, they also have a copy of the backup public key. 432 433 After the reload of KDC software, the bits associated with 434 recovery of each principal are all set. The KDC clears the bit 435 for each principal that undergoes the recovery phase. In addition, 436 there is a bit associated with each principal to indicate whether 437 there is a valid symmetric key in the database for the principal. 438 These bits are all cleared after the reload of the KDC software 439 (the old symmetric keys are no longer valid). Finally, there is a 440 bit associated with each principal indicating whether that 441 principal still uses non-public key capable clients. If a user 442 principal falls into this category, a public key capable client 443 cannot transparently re-establish a symmetric key for that user, 444 since the older clients would not be able to compute the new 445 symmetric key that includes hashing the password with a KDC 446 supplied salt value. The re-establishment of the symmetric key 447 in this case is outside the scope of this protocol. 448 449 One method of re-establishing a symmetric key for public key 450 capable clients is to generate a hash of the user password and a 451 KDC supplied salt value. The KDC salt is changed after every 452 compromise of the KDC. In the recovery protocol, if the principal 453 does not still use old clients, the KDC supplied salt is sent to 454 the client principal in a KRB_ERROR message with error code 455 KDC_RECOVERY_NEEDED. The error data field of the message contains 456 the following structure which is encoded into an octet string. 457 458 PA-PK-KDC-ERR ::= CHOICE { 459 recoveryDhErr SignedDHError, -- Used during recovery 460 -- when algorithm is DH 461 -- based 462 recoveryPKEncErr SignedPKEncError -- Used during recovery 463 -- for PK encryption 464 -- (RSA,...) 465 } 466 467 SignedDHError ::= SEQUENCE { 468 dhErr DHError, 469 dhErrSig Signature 470 } 471 472 SignedPKEncError ::= SEQUENCE { 473 pkEncErr PKEncryptError, 474 pkEncErrSig Signature 475 } 476 477 DHError ::= SEQUENCE { 478 nonce INTEGER, -- From AS_REQ 479 algorithmId INTEGER, -- DH algorithm 480 kdcPubValue SubjectPublicKeyInfo, -- DH algorithm 481 kdcPubValueId INTEGER, -- DH algorithm 482 kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public 483 -- key kvno 484 kdcPublicKey OCTET STRING OPTIONAL, -- New KDC pubkey 485 kdcSalt OCTET STRING OPTIONAL -- If user uses 486 -- only new 487 -- clients 488 } 489 490 PKEncryptError ::= SEQUENCE { 491 nonce INTEGER, -- From AS_REQ 492 algorithmId INTEGER, -- Public Key 493 -- encryption alg 494 kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public 495 -- key kvno 496 kdcPublicKey OCTET STRING OPTIONAL, -- New KDC public 497 -- key 498 kdcSalt OCTET STRING OPTIONAL -- If user uses 499 -- only new 500 -- clients 501 } 502 503 The KDC_RECOVERY_NEEDED error message is sent in response to a 504 client AS_REQ message if the client principal needs to be 505 recovered, unless the client AS_REQ contains the PKAuthenticator 506 with a nonempty RecoveryData field (in this case the client has 507 already received the KDC_RECOVERY_NEEDED error message. We will 508 also see in section 3.2.2 that a different error response is 509 sent by the KDC if the encrypted user private key is stored in 510 the KDC database.) If the client principal uses only new clients, 511 then the kdcSalt field is returned; otherwise, the kdcSalt field 512 is absent. 513 514 If the client uses the Diffie Hellman algorithm during the recovery 515 phase then the DHError field contains the public Diffie Hellman 516 parameter (kdcPubValue) for the KDC along with an identifier 517 (kdcPubValueID). The client will then send this identifier to 518 the KDC in an AS_REQ message; the identifier allows the KDC to 519 look up the Diffie Hellman private value corresponding to the 520 identifier. Depending on how often the KDC updates its private 521 Diffie Hellman parameters, it will have to store anywhere between a 522 handful and several dozen of these identifiers and their parameters. 523 The KDC must send its Diffie Hellman public value to the client 524 first so the client can encrypt its new symmetric key. 525 526 In the case where the user principal does not need to be recovered 527 and the user still uses old clients as well as new clients, the 528 KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ 529 messages when there is no valid symmetric key in the KDC database. 530 This situation can occur if the user principal has been recovered 531 but no new symmetric key has been established in the database. 532 533 In addition, the two error messages with error codes 534 KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified 535 so the error data contains the kdcSalt encoded as an OCTET STRING. 536 The reason for the modification is to allow principals that use 537 new clients only to have their symmetric key transparently updated 538 by the client software during the recovery phase. The kdcSalt is 539 used to create the new symmetric key. As a performance optimization, 540 the kdcSalt is stored in the /krb5/salt file along with the realm. 541 Thus the /krb5/salt file consists of realm-salt pairs. If the file 542 is missing, or the salt is not correct, the above error messages 543 allow the client to find out the correct salt. New clients which 544 are configured for symmetric key authentication attempt to 545 preauthenticate with the salt from the /krb5/salt file as an 546 input into their key, and if the file is not present, the new client 547 does not use preauthentication. The error messages above return 548 either the correct salt to use, or no salt at all which indicates 549 that the principal is still using old clients (the client software 550 should use the existing mapping from the user password to the 551 symmetric key). 552 553 In order to assure interoperability between clients from different 554 vendors and organizations, a standard algorithm is needed for 555 creating the symmetric key from the principal password and kdcSalt. 556 The algorithm for creating the symmetric key is as follows: take the 557 SHA-1 hash of the kdcSalt concatenated with the principal password 558 and use the 20 byte output as the input into the existing key 559 generation process (string to key function). After a compromise, the 560 KDC changes the kdcSalt; thus, the recovery algorithm allows users 561 to obtain a new symmetric key without actually changing their 562 password. 563 564 The response from the KDC would be identical to the response in RFC 565 1510, except that instead of being encrypted in the secret key 566 shared by the client and the KDC, it is encrypted in a random key 567 freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A 568 preauthentication field (specified below) accompanies the response, 569 optionally containing a certificate with the public key for the KDC 570 (since we do not assume that the client knows this public key), and 571 a package containing the secret key in which the rest of the 572 response is encrypted, along with the same nonce used in the rest 573 of the response, in order to prevent replays. This package is itself 574 signed with the private key of the KDC, then encrypted with the 575 symmetric key that is returned encrypted in the public key of the 576 user (or for Diffie Hellman, encrypted in the shared secret Diffie 577 Hellman symmetric key). 578 579 Pictorially, in the public key encryption case we have: 580 581 kdcCert, {[encReplyKey, nonce] Sig w/KDC 582 privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey 583 584 Pictorially, in the Diffie Hellman case we have: 585 586 kdcCert, {encReplyKey, nonce}DH shared symmetric key, 587 [DH public value]Sig w/KDC privkey 588 589 PA-PK-AS-REP ::= SEQUENCE { 590 kdcCert[0] SEQUENCE OF Certificate, 591 encryptShell[1] EncryptedData, 592 -- EncPaPkAsRepPartShell 593 -- encrypted by 594 -- encReplyTmpKey or DH 595 -- shared symmetric key 596 pubKeyExchange[2] PubKeyExchange OPTIONAL, 597 -- a choice between 598 -- a KDC signed DH 599 -- value and a public 600 -- key encrypted 601 -- symmetric key. 602 -- Not needed after 603 -- recovery when 604 -- DH is used. 605 } 606 607 PubKeyExchange ::= CHOICE { 608 signedDHPubVal SignedDHPublicValue, 609 encryptKey EncryptedData 610 -- EncPaPkAsRepTmpKey 611 -- encrypted by 612 -- userPublicKey 613 } 614 615 SignedDHPublicValue ::= SEQUENCE { 616 dhPublic[0] SubjectPublicKeyInfo, 617 dhPublicSig[1] Signature 618 } 619 620 EncPaPkAsRepPartShell ::= SEQUENCE { 621 encReplyPart[0] EncPaPkAsRepPart, 622 encReplyPartSig[1] Signature OPTIONAL 623 -- encReplyPart 624 -- signed by kdcPrivateKey 625 -- except not present in 626 -- DH case 627 } 628 629 EncPaPkAsRepPart ::= SEQUENCE { 630 encReplyKey[0] EncryptionKey, 631 nonce[1] INTEGER, 632 } 633 634 EncPaPkAsRepTmpKey ::= SEQUENCE { 635 encReplyTmpKey[0] EncryptionKey 636 } 637 638 The kdc-cert specification is lifted, with slight modifications, 639 from v3 of the X.509 certificate specification: 640 641 Certificate ::= SEQUENCE { 642 version[0] Version DEFAULT v1 (1), 643 serialNumber[1] CertificateSerialNumber, 644 signature[2] AlgorithmIdentifier, 645 issuer[3] PrincipalName, 646 validity[4] Validity, 647 subjectRealm[5] Realm, 648 subject[6] PrincipalName, 649 subjectPublicKeyInfo[7] SubjectPublicKeyInfo, 650 issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, 651 subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, 652 authentSig[10] Signature 653 } 654 655 The kdc-cert must have as its root certification one of the 656 certifiers sent to the KDC with the original request. If the KDC 657 has no such certification, then it will instead reply with a 658 KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED. If a zero-length 659 root-cert was sent by the client as part of the PA-PK-AS-ROOT, then 660 a correspondingly zero-length kdc-cert may be absent, in which case 661 the client uses its copy of the KDC's public key. In the case of 662 recovery, the client uses its copy of the backup KDC public key. 663 664 Upon receipt of the response from the KDC, the client will verify 665 the public key for the KDC from PA-PK-AS-REP preauthentication data 666 field. The certificate must certify the key as belonging to a 667 principal whose name can be derived from the realm name. If the 668 certificate checks out, the client then decrypts the EncPaPkAsRepPart 669 and verifies the signature of the KDC. It then uses the random key 670 contained therein to decrypt the rest of the response, and continues 671 as per RFC 1510. Because there is direct trust between the user and 672 the KDC, the transited field of the ticket returned by the KDC should 673 remain empty. (Cf. Section 3.3.) 674 675 Examples 676 677 We now give several examples illustrating the protocols in this 678 section. Encryption of message M with key K is denoted {M}K and 679 the signature of message M with key K is denoted [M]K. 680 681 Example 1: The requesting user principal needs to be recovered and 682 uses only new clients. The recovery algorithm is Diffie Hellman (DH). 683 Then the exchange sequence between the user principal and the KDC is: 684 685 686 Client --------> AS_REQ (with or without preauth) --------> KDC 687 688 Client <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC 689 error data: [nonce, algID (DH), KDC DH public parameter, 690 KDC DH ID, KDC PublicKey Kvno and PublicKey, 691 KDC Salt]Signed with KDC PrivateKey 692 693 At this point, the client validates the KDC signature, checks to 694 see if the nonce is the same as the one in the AS_REQ, and stores 695 the new KDC public key and public key version number. The client 696 then generates a Diffie Hellman private parameter and computes 697 the corresponding Diffie Hellman public parameter; the client 698 also computes the shared Diffie Hellman symmetric key using the 699 KDC Diffie Hellman public parameter and its own Diffie Hellman 700 private parameter. Next, the client prompts the user for his/her 701 password (if it does not already have the password). The password 702 is concatenated with the KDC Salt and then SHA1 hashed; the 703 result is fed into the string to key function to obtain the new 704 user DES key. 705 706 The new user DES key will be encrypted (along with the AS_REQ 707 nonce) using the Diffie Hellman symmetric key and sent to the 708 KDC in the new AS_REQ message: 709 710 Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with 711 user DH public parameter, {newUser DES key, nonce}DH 712 symmetric key, KDC DH ID]Signed with User PrivateKey 713 -> KDC 714 715 The KDC DH ID is copied by the client from the KDC_ERROR message 716 received above. Upon receipt and validation of this message, the 717 KDC first uses the KDC DH ID as an index to locate its 718 private Diffie Hellman parameter; it uses this parameter in 719 combination with the user public Diffie Hellman parameter 720 to compute the symmetric Diffie Hellman key. The KDC checks 721 if the encrypted nonce is the same as the one in the 722 PKAuthenticator and the AS_REQ part. The KDC then enters 723 the new user DES key into the database, resets the recovery 724 needed bit, and sets the valid symmetric key in database 725 bit. The KDC then creates the AS_REP message: 726 727 Client <-- AS_REP with preauth: kdcCert, {encReplyKey, 728 nonce}DH symmetric key <-------------------- KDC 729 730 731 The AS_REP encrypted part is encrypted with the encReplyKey 732 that is generated on the KDC. The nonces are copied from the 733 client AS_REQ. The kdcCert is a sequence of certificates 734 that have been certified by certifiers listed in the client 735 rootCert field, unless a zero length rootCert field was sent. 736 In the last case, the kdcCert will also have zero length. 737 7383.2.2. Private key held by KDC 739 740 Implementation of the changes in this section is RECOMMENDED. 741 742 When the user's private key is not carried with the user, the 743 user may encrypt the private key using conventional cryptography, 744 and register the encrypted private key with the KDC. As 745 described in the previous section, the SHA1 hash of the password 746 concatenated with the kdcSalt is also stored in the KDC database 747 if the user only uses new clients. We restrict users of this 748 protocol to using new clients only. The reason for this restriction 749 is that it is not secure to store both the user private key 750 encrypted in the user's password and the user password on the KDC 751 simultaneously. 752 753 There are several options for storing private keys. If the 754 user stores their private key on a removable disk, it is 755 less convenient since they need to always carry the disk 756 around with them; in addition, the procedures for extracting 757 the key may vary between different operating systems. 758 Alternatively, the user can store a private key on the hard 759 disks of systems that he/she uses; besides limiting the 760 systems that the user can login from there is also a 761 greater security risk to the private key. If smart card 762 readers or slots are deployed in an organization, then the 763 user can store his/her private key on a smart card. Finally, 764 the user can store his/her private key encrypted in a password 765 on the KDC. This last option is probably the most practical 766 option currently; it is important that a good password policy 767 be used. 768 769 When the user's private key is stored on the KDC, 770 preauthentication is required. There are two cases depending on 771 whether the requesting user principal needs to be recovered. 772 773 In order to obtain its private key, a user principal includes the 774 padata type PA-PK-AS-REQ in the preauthentication data 775 field of the AS_REQ message. The accompanying pa-data field is: 776 777 PA-PK-AS-REQ ::= SEQUENCE { 778 algorithmId[0] INTEGER, -- Public Key Alg. 779 encClientPubVal[1] EncryptedData -- EncPaPkAsReqDH 780 -- (encrypted with key 781 -- K1) 782 } 783 784 EncPaPkAsReqDH ::= SEQUENCE { 785 clientPubValue[0] SubjectPublicKeyInfo 786 } 787 788 Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1. 789 790 The user principal sends its Diffie-Hellman public value encrypted 791 in the key K1. The key K1 is derived by performing string to key on 792 the SHA1 hash of the user password concatenated with the kdcSalt 793 which is stored in the /krb5/salt file. If the file is absent, 794 the concatenation step is skipped in the above algorithm. The 795 Diffie Hellman parameters g and p are implied by the algorithmID 796 field. By choosing g and p correctly, dictionary attacks against 797 the key K1 can be made more difficult [Jaspan]. 798 799 If the requesting user principal needs recovery, the encrypted 800 user private key is stored in the KDC database, and the AS_REQ 801 RecoveryData field is not present in the PKAuthenticator, then 802 the KDC replies with a KRB_ERROR message, with msg-type set to 803 KDC_ERR_PREAUTH_REQUIRED, and e-data set to: 804 805 PA-PK-AS-INFO ::= SEQUENCE { 806 signedDHErr SignedDHError, -- signed by KDC 807 encUserKey OCTET STRING OPTIONAL -- encrypted by 808 -- user password 809 -- key; (recovery 810 -- response) 811 812 } 813 814 The user principal should then continue with the section 3.2.1.1 815 protocol using the Diffie Hellman algorithm. 816 817 We now assume that the requesting user principal does not need 818 recovery. 819 820 Upon receipt of the authentication request with the PA-PK-AS-REQ, 821 the KDC generates the AS response as defined in RFC 1510, but 822 additionally includes a preauthentication field of type 823 PA-PK-USER-KEY. 824 825 PA-PK-USER-KEY ::= SEQUENCE { 826 kdcCert SEQUENCE OF Certificate, 827 encUserKeyPart EncryptedData, -- EncPaPkUserKeyPart 828 kdcPrivKey KDCPrivKey, 829 kdcPrivKeySig Signature 830 } 831 832 The kdc-cert field is identical to that in the PA-PK-AS-REP 833 preauthentication data field returned with the KDC response, and 834 must be validated as belonging to the KDC in the same manner. 835 836 KDCPrivKey ::= SEQUENCE { 837 nonce INTEGER, -- From AS_REQ 838 algorithmId INTEGER, -- DH algorithm 839 kdcPubValue SubjectPublicKeyInfo, -- DH algorithm 840 kdcSalt OCTET STRING -- Since user 841 -- uses only new 842 -- clients 843 } 844 845 The KDCPrivKey field is signed using the KDC private key. 846 The encrypted part of the AS_REP message is encrypted using the 847 Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart. 848 849 EncPaPkUserKeyPart ::= SEQUENCE { 850 encUserKey OCTET STRING, 851 nonce INTEGER -- From AS_REQ 852 } 853 854 Notationally, if encryption algorithm A is used, then enc-key-part 855 is 856 857 A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key). 858 859 If the client has used an incorrect kdcSalt to compute the 860 key K1, then the client needs to resubmit the above AS_REQ 861 message using the correct kdcSalt field from the KDCPrivKey 862 field. 863 864 This message contains the encrypted private key that has been 865 registered with the KDC by the user, as encrypted by the user, 866 super-encrypted with the Diffie Hellman derived symmetric key. 867 Because there is direct trust between the user and the KDC, the 868 transited field of the ticket returned by the KDC should remain 869 empty. (Cf. Section 3.3.) 870 871 Examples 872 873 We now give several examples illustrating the protocols in this 874 section. 875 876 Example 1: The requesting user principal needs to be recovered 877 and stores his/her encrypted private key on the KDC. Then the 878 exchange sequence between the user principal and the KDC is: 879 880 Client --------> AS_REQ (with or without preauth) -----> KDC 881 882 Client <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED) 883 error data: [nonce, algID (DH), KDC DH public 884 parameter, KDC DH ID, KDC PublicKey 885 Kvno and PublicKey, KDC Salt]Signed 886 with KDC PrivateKey, {user private 887 key}user password <------------- KDC 888 889 The protocol now continues with the second AS_REQ as in Example 890 1 of section 3.2.1.1. 891 892 Example 2: The requesting user principal does not need to be 893 recovered and stores his/her encrypted private key on the KDC. 894 Then the exchange sequence between the user principal and the KDC 895 when the user principal wants to obtain his/her private key is: 896 897 Client -> AS_REQ with preauth: algID, 898 {DH public parameter}K1 -> KDC 899 900 The key K1 is generated by using the string to key function 901 on the SHA1 hash of the password concatenated with the kdcSalt 902 from the /krb5/salt file. If the file is absent, then 903 the concatenation step is skipped, and the client will learn 904 the correct kdcSalt in the following AS_REP message from the 905 KDC. The algID should indicate some type of Diffie Hellman 906 algorithm. 907 908 The KDC replies with the AS_REP message with a preauthentication 909 data field: 910 911 Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC 912 nonce}DH symmetric key, [nonce, algID, DH 913 public parameter, kdcSalt]KDC privateKey 914 915 The client validates the KDC's signature and checks that 916 the nonce matches the nonce in its AS_REQ message. 917 If the kdcSalt does not match what the client used, it 918 starts the protocol over. The client then uses the KDC 919 Diffie Hellman public parameter along with its own Diffie 920 Hellman private parameter to compute the Diffie Hellman 921 symmetric key. This key is used to decrypt the encUserKey 922 field; the client checks if the nonce matches its AS_REQ 923 nonce. At this point, the initial authentication protocol 924 is complete. 925 926 Example 3: The requesting user principal does not need to be 927 recovered and stores his/her encrypted private key on the KDC. 928 In this example, the user principal uses the conventional 929 symmetric key Kerberos V5 initial authentication protocol 930 exchange. 931 932 We note that the conventional protocol exposes the user 933 password to dictionary attacks; therefore, the user password 934 must be changed more often. An example of when this protocol 935 would be used is when new clients have been installed but an 936 organization has not phased in public key authentication for 937 all clients due to performance concerns. 938 939 Client ----> AS_REQ with preauthentication: {time}K1 --> KDC 940 941 Client <-------------------- AS_REP <------------------ KDC 942 943 The key K1 is derived as in the preceding two examples. 944 945 9463.3. Clients with a public key certified by an outside authority 947 948 Implementation of the changes in this section is OPTIONAL. 949 950 In the case where the client is not registered with the current 951 KDC, the client is responsible for obtaining the private key on 952 its own. The client will request initial tickets from the KDC 953 using the TGS exchange, but instead of performing 954 preauthentication using a Kerberos ticket granting ticket, or 955 with the PA-PK-AS-REQ that is used when the public key is known 956 to the KDC, the client performs preauthentication using the 957 preauthentication data field of type PA-PK-AS-EXT-CERT: 958 959 PA-PK-AS-EXT-CERT ::= SEQUENCE { 960 userCert[0] SEQUENCE OF OCTET STRING, 961 signedAuth[1] SignedPKAuthenticator 962 } 963 964 where the user-cert specification depends on the type of 965 certificate that the user possesses. In cases where the service 966 has separate key pairs for digital signature and for encryption, 967 we recommend that the signature keys be used for the purposes of 968 sending the preauthentication (and deciphering the response). 969 970 The authenticator is the one used from the exchange in section 971 3.2.1, except that it is signed using the private key corresponding 972 to the public key in the user-cert. 973 974 The KDC will verify the preauthentication authenticator, and check the 975 certification path against its own policy of legitimate certifiers. 976 This may be based on a certification hierarchy, or simply a list of 977 recognized certifiers in a system like PGP. 978 979 If all checks out, the KDC will issue Kerberos credentials, as in 3.2, 980 but with the names of all the certifiers in the certification path 981 added to the transited field of the ticket, with a principal name 982 taken from the certificate (this might be a long path for X.509, or a 983 string like "John Q. Public <jqpublic@company.com>" if the certificate 984 was a PGP certificate. The realm will identify the kind of 985 certificate and the final certifier as follows: 986 987 cert_type/final_certifier 988 989 as in PGP/<endorser@company.com>. 990 991 9923.4. Digital Signature 993 994 Implementation of the changes in this section is OPTIONAL. 995 996 We offer this option with the warning that it requires the client 997 process to generate a random DES key; this generation may not 998 be able to guarantee the same level of randomness as the KDC. 999 1000 If a user registered a digital signature key pair with the KDC, 1001 a separate exchange may be used. The client sends a KRB_AS_REQ 1002 as described in section 3.2.2. If the user's database record 1003 indicates that a digital signature key is to be used, then the 1004 KDC sends back a KRB_ERROR as in section 3.2.2. 1005 1006 It is assumed here that the signature key is stored on local disk. 1007 The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, 1008 signs it using the signature key (otherwise the signature is 1009 performed as described in section 3.2.1), then encrypts the whole 1010 with the public key of the KDC. This is returned with a separate 1011 KRB_AS_REQ in a preauthentication of type 1012 1013 PA-PK-AS-SIGNED ::= SEQUENCE { 1014 signedKey[0] EncryptedData -- PaPkAsSignedData 1015 } 1016 1017 PaPkAsSignedData ::= SEQUENCE { 1018 signedKeyPart[0] SignedKeyPart, 1019 signedKeyAuth[1] PKAuthenticator, 1020 sig[2] Signature 1021 } 1022 1023 SignedKeyPart ::= SEQUENCE { 1024 encSignedKey[0] EncryptionKey, 1025 nonce[1] INTEGER 1026 } 1027 1028 where the nonce is the one from the request. Upon receipt of the 1029 request, the KDC decrypts, then verifies the random key. It then 1030 replies as per RFC 1510, except that instead of being encrypted 1031 with the password-derived DES key, the reply is encrypted using 1032 the randomKey sent by the client. Since the client already knows 1033 this key, there is no need to accompany the reply with an extra 1034 preauthentication field. Because there is direct trust between 1035 the user and the KDC, the transited field of the ticket returned 1036 by the KDC should remain empty. (Cf. Section 3.3.) 1037 1038 In the event that the KDC database indicates that the user 1039 principal must be recovered, and the PKAuthenticator does not 1040 contain the RecoveryData field, the KDC will reply with the 1041 KDC_RECOVERY_NEEDED error. The user principal then sends 1042 another AS_REQ message that includes the RecoveryData field 1043 in the PKAuthenticator. The AS_REP message is the same as 1044 in the basic Kerberos V5 protocol. 1045 1046 10474. Preauthentication Data Types 1048 1049 We propose that the following preauthentication types be allocated 1050 for the preauthentication data packages described in this draft: 1051 1052 #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ 1053 #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ 1054 #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ 1055 #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ 1056 #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ 1057 #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ 1058 1059 10605. Encryption Information 1061 1062 For the public key cryptography used in direct registration, we 1063 used (in our implementation) the RSAREF library supplied with the 1064 PGP 2.6.2 release. Encryption and decryption functions were 1065 implemented directly on top of the primitives made available 1066 therein, rather than the fully sealing operations in the API. 1067 1068 10696. Compatibility with One-Time Passcodes 1070 1071 We solicit discussion on how the use of public key cryptography 1072 for initial authentication will interact with the proposed use of 1073 one time passwords discussed in Internet Draft 1074 <draft-ietf-cat-kerberos-passwords-00.txt>. 1075 10767. Strength of Encryption and Signature Mechanisms 1077 1078 In light of recent findings on the strengths of MD5 and various DES 1079 modes, we solicit discussion on which modes to incorporate into the 1080 protocol changes. 1081 1082 10838. Expiration 1084 1085 This Internet-Draft expires on April 19, 1997. 1086 1087 10889. Authors' Addresses 1089 1090 B. Clifford Neuman 1091 USC/Information Sciences Institute 1092 4676 Admiralty Way Suite 1001 1093 Marina del Rey, CA 90292-6695 1094 1095 Phone: 310-822-1511 1096 EMail: bcn@isi.edu 1097 1098 Brian Tung 1099 USC/Information Sciences Institute 1100 4676 Admiralty Way Suite 1001 1101 Marina del Rey, CA 90292-6695 1102 1103 Phone: 310-822-1511 1104 EMail: brian@isi.edu 1105 1106 John Wray 1107 Digital Equipment Corporation 1108 550 King Street, LKG2-2/Z7 1109 Littleton, MA 01460 1110 1111 Phone: 508-486-5210 1112 EMail: wray@tuxedo.enet.dec.com 1113 1114 Jonathan Trostle 1115 CyberSafe Corporation 1116 1605 NW Sammamish Rd., Suite 310 1117 Issaquah, WA 98027-5378 1118 1119 Phone: 206-391-6000 1120 EMail: jonathan.trostle@cybersafe.com 1121