1 2INTERNET-DRAFT Clifford Neuman 3draft-ietf-cat-kerberos-pk-init-00.txt Brian Tung 4Updates: RFC 1510 ISI 5expires September 3, 1995 John Wray 6 Digital Equipment Corporation 7 8 9 Public Key Cryptography for Initial Authentication in Kerberos 10 11 120. Status Of this Memo 13 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 18 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other docu- 21 ments at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as ``work in pro- 23 gress.'' 24 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 27 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 30 31 The distribution of this memo is unlimited. It is filed as 32 draft-ietf-cat-kerberos-pk-init-00.txt, and expires August 6, 1995. 33 Please send comments to the authors. 34 35 361. Abstract 37 38 This document defines extensions to the Kerberos protocol specifi- 39 cation (RFC 1510, "The Kerberos Network Authentication Service 40 (V5)", September 1993) to provide a method for using public key 41 cryptography during initial authentication. The method defined 42 specifies the way in which preauthentication data fields and error 43 data fields in Kerberos messages are to be used to transport public 44 key data. 45 462. Motivation 47 48 Public key cryptography provides a means by which a principal may 49 demonstrate possession of a key, without ever having divulged this 50 key to anyone else. In conventional cryptography, the encryption key 51 and decryption key are either identical or can easily be derived from 52 each other. In public key cryptography, however, neither key can be 53 derived easily from the other; hence, the ability to encrypt a message 54 does not imply the ability to decrypt it in turn. Additionally, each 55 key is a full inverse of the other, so that either key can be used 56 for encryption or decryption. 57 58 The advantages provided by public key cryptography have produced a 59 demand for its integration into the Kerberos authentication protocol. 60 There are two important areas where public key cryptography will have 61 immediate use: in the initial authentication of users registered with 62 the KDC or using public key certificates from outside authorities, 63 and to establish inter-realm keys for cross-realm authentication. 64 This memo describes a method by which the first of these can be done. 65 The second case will be the topic for a separate proposal. 66 67 Some of the ideas on which this proposal is based arose during 68 discussions over several years between members of the SAAG, the 69 IETF-CAT working group, and the PSRG, regarding integration of 70 Kerberos and SPX. Some ideas are drawn from the DASS system, and 71 similar extensions have been discussed for use in DCE. These changes 72 are by no means endorsed by these groups. This is an attempt to 73 revive some of the goals of that group, and the proposal approaches 74 those goals primarily from the Kerberos perspective. 75 76 This proposal will allow users with keys already registered for use 77 with X.509, PEM, or PGP, to use those keys to obtain Kerberos 78 credentials which can then be used for authentication with application 79 servers supporting Kerberos. 80 81 Use of public-key will not be a requirement for Kerberos, but if one's 82 organization runs a KDC supporting public key, then users may choose 83 to be registered with public keys instead of the current secret key. 84 The application request and response, between Kerberos clients and 85 application servers, will continue to be based on conventional 86 cryptography, and the application servers will continue to be 87 registered with conventional keys. 88 89 903. Initial authentication of users with public keys 91 92 This section proposes extensions to Version 5 of the Kerberos 93 protocol that will support the use of public key cryptography 94 by users in the initial request for a ticket granting ticket. 95 96 The advantage of registering public keys with the KDC lies in the 97 ease of recovery in case the KDC is compromised. With Kerberos as it 98 currently stands, compromise of the security KDC is disastrous. All 99 keys become known by the attacker and all keys must be changed. 100 101 If users register public keys, compromise of the KDC does not divulge 102 their private key. Compromise of security on the KDC is still 103 disastrous, since the attacker can impersonate any user. An 104 attacker with the private key of the KDC can use it to certify a 105 bogus nonce key, and impersonate a user. Changing this key 106 invalidates all bogus certifications. Legitimate users must 107 re-certify their keys with the new KDC key, but users' public 108 keys do not have to be changed. (Users who store their private 109 keys in an encrypted form on the KDC do have to change their 110 keys, since the encryption key is a symmetric key derived from 111 a password (as described below) and hence vulnerable to dictionary 112 attacks. The difference is that, assuming good password policy, 113 site policy may allow the use of the old password only for the 114 purpose of key change for a time after the compromise, which means 115 that users can change their own passwords, rather than forcing the 116 administrator to re-key everyone.) 117 118 In the event of compromise of the KDC, recovery is simple since only 119 the KDC's key, keys for application servers, and users' private keys 120 stored in the KDC (as described above) must be changed. 121 Since there are usually fewer servers than users, and since an 122 organization usually has better procedures for updating servers, 123 changing these keys is much easier than having to individually 124 contact every user. 125 126 This proposed extension will not require users to register with 127 public keys. It is intended to allow them to do so, but we recognize 128 that there are many reasons, including licensing terms, that users or 129 an organization as a whole will choose not to use the public key 130 option. Users registered will public keys will only be able to 131 perform initial authentication from a client that support public key, 132 and must be registered in a realm that supports public key. But they 133 will be able to use services registered in realms that support only 134 conventional Kerberos. Further, users registered with conventional 135 Kerberos keys will be able to use all clients. 136 137 This proposal specifically does not address the registration of 138 public keys for services. The application request and response, 139 between Kerberos clients and application servers, will continue to be 140 based on conventional cryptography, and the application servers will 141 continue to be registered with conventional keys. There are 142 performance issues and other reasons that servers may be better off 143 using conventional cryptography. There are also reasons that they 144 may want to use public key. For this proposal, however, we feel that 145 80 percent of the benefits of integrating public key with Kerberos 146 can be attained for 20 percent of the effort, by addressing only 147 initial authentication. This proposal does not preclude separate 148 extensions. 149 150 This proposal address two ways in which users may use public key 151 cryptography for initial authentication with Kerberos. In both 152 cases, the end result is that the user obtains a conventional ticket 153 granting ticket, or conventional server ticket, that may be used for 154 subsequent authentication, with such subsequent authentication using 155 only conventional cryptography. 156 157 Users may register keys directly with the KDC, or they may present 158 certificates by outside certification authorities (or certifications 159 by other users) attesting to the association of the public key with 160 the named user. We first consider the case where the user's key is 161 registered with the KDC. 162 163 1643.1 Initial request for user registered with public key on KDC 165 166 In this scenario it is assumed that the user is registered with a public 167 key on the KDC. The user's private key may be known to the user, or 168 may be stored on the KDC, encrypted so that it can not be used by the KDC. 169 170 We consider first the case where the user knows the private key, then 171 add support for retrieving the private key from the KDC. 172 173 The initial request to the KDC for a ticket granting ticket proceeds 174 according to RFC 1510. Typically, preauthentication using a secret 175 key would not be included, but if included it may be ignored by the 176 KDC. (This may introduce a problem: even if the KDC should ignore 177 the preauthentication, an attacker may not, and use an 178 intercepted message to guess the password off-line.) 179 If the private key is known to the client in advance, the 180 response from the KDC would be identical to the response in RFC1510, 181 except that instead of being encrypted in the secret key shared by the 182 client and the KDC, it is encrypted in a random key freshly generated 183 by the KDC. A preauthentication field (specified below) 184 accompanies the response, containing a certificate with the public 185 key for the KDC, and a package containing the secret key in which the 186 rest of the response is encrypted, itself encrypted in the private key 187 of the KDC, and the public key of the user. This package also contains 188 the same nonce used in the rest of the response, in order to prevent 189 replays of this part of the message, accompanied by a reconstructed 190 response. 191 192 PA-PK-AS-REP ::= SEQUENCE { 193 kdc-cert SEQUENCE OF OCTET STRING, 194 encryptPack EncryptedData -- EncPaPkAsRepPart 195 } 196 197 EncPaPkAsRepPart ::= SEQUENCE { 198 enc-sess-key INTEGER, 199 nonce INTEGER 200 } 201 202 Upon receipt of the response from the KDC, the client will verify the 203 public key for the KDC from PA-PK-AS-REP preauthentication data field, 204 The certificate must certify the key as belonging to a principal whose 205 name can be derived from the realm name. We solicit discussion on the 206 form of the kdc-cert. If client systems are expected to know (by 207 being hard-coded, for example) at least one public key, and to verify 208 certificates from that key, then there should be at least some policy 209 about which key that is, or alternatively some way to inform the KDC 210 which key the client possesses. 211 212 If the certificate checks 213 out, the client then extracts the message key for the rest of the 214 response by decrypting the field in the PA-PK-AS-REP with the public 215 key of the KDC and the private key of the user. The client then uses 216 the message key to decrypt the rest of the response, and continues as 217 per RFC1510[1]. 218 219 2203.1.1. Private key held by KDC 221 222 When the user's private key is not carried with the user, the user may 223 encrypt the private key using conventional cryptography, and register 224 the encrypted private key with the KDC. 225 226 When the user's private key is registered with the KDC, the KDC record 227 will also indicate whether preauthentication is required before 228 returning the record (we recommend that it be required). If such 229 preauthentication is required, when the initial request is received 230 the KDC will respond with a KRB_ERROR message of type 231 KDC_ERR_PREAUTH_REQUIRED and with an error data field set to: 232 233 PA-PK-AS-INFO ::= SEQUENCE { 234 kdc-cert OCTET STRING} 235 } 236 237 The kdc-cert field is identical to that in the PA-PK-AS-REP 238 preauthentication data field returned with the KDC response, and must 239 be validated as belonging to the KDC in the same manner. 240 241 Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the 242 client will prompt the user for the password that will be used to 243 decrypt the private key when returned, calculate a one way hash H1 of the 244 key, and send a request to the KDC, including a timestamp and a 245 client-generated nonce secret key that will be used to super-encrypt 246 the encrypted private key before it is returned to the client. This 247 information is sent to the KDC in a subsequent AS_REQ message in a 248 preauthentication data field: 249 250 PA-PK-AS-REQ ::= SEQUENCE { 251 enc-part EncryptedData -- EncPaPkAsReqPart 252 } 253 254 EncPaPkAsReqPart ::= SEQUENCE { 255 tstamp KerberosTime, 256 noncekey INTEGER 257 } 258 259 encrypted first with the hash H1, then the public key of the KDC from 260 the certificate in the PA-PK-AS-INFO field of the error response. 261 262 Upon receipt of the authentication request with the PA-PK-AS-REQ the 263 KDC verifies the hash of the user's DES encryption key by comparing it 264 to the hash stored in the users database record. If valid, it 265 generates the AS response as defined in RFC1510, but additionally 266 includes a preauthentication field of type PA-PK-USER KEY. This 267 response will also be included in response to the initial request 268 without preauthentication if preauthentication is not required for the 269 user and the user's encrypted private key is stored on the KDC. The 270 KDC generates a preauthentication data field of type PA-PK-USER-KEY 271 which will be returned with the KDC reply (together with the 272 PA-PK-AS-REP that is already returned). 273 274 PA-PK-USER-KEY ::= SEQUENCE { 275 enc-priv-key OCTET STRING OPTIONAL 276 } 277 278 This message contains the encrypted private key that has been 279 registered with the KDC by the user, as encrypted by the user, 280 super-encrypted with the noncekey from the PA-PK-AS-REQ message if 281 preauthentication using that method was provided. Note that since 282 H1 is a one-way hash, it is not possible for one to decrypt the 283 message if one possesses H1 but not the noncekey that H1 is derived 284 from. 285 286 2873.2. Clients with a public key certified by an outside authority 288 289 In the case where the client is not registered with the current KDC, 290 the client is responsible for obtaining the private key on its own. 291 The client will request initial tickets from the KDC using the TGS 292 exchange, but instead of performing pre-authentication using a 293 Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used 294 when the public key is known to the KDC, the client performs 295 preauthentication using the preauthentication data field of type 296 PA-PK-AS-EXT-CERT: 297 298 PA-PK-AS-EXT-CERT ::= SEQUENCE { 299 user-cert SEQUENCE OF OCTET STRING, 300 authent EncryptedData -- PKAuthenticator 301 } 302 303 PKAuthenticator ::= SEQUENCE { 304 cksum Checksum OPTIONAL, 305 cusec INTEGER, 306 ctime KerberosTime, 307 } 308 309 The fields in the encrypted authenticator are the same as those 310 in the Kerberos authenticator. The structure is itself signed using 311 the user's private key corresponding to the public key in the 312 certificate. 313 314 The KDC will verify the preauthentication authenticator, and check the 315 certification path against its own policy of legitimate certifiers. 316 This may be based on a certification hierarchy, or simply a list of 317 recognized certifiers in a system like PGP. 318 319 If all checks out, the KDC will issue Kerberos credentials, as in 3.1, 320 but with the names of all the certifiers in the certification path 321 added to the transited field of the ticket, with a principal name 322 taken from the certificate (this might be a long path for X.509, or a 323 string like "John Q. Public <jqpublic@company.com>" if the certificate 324 was a PGP certificate. The realm will identify the kind of 325 certificate and the final certifier (e.g. PGP:<endorser@company.com>)[2]. 326 327 3284. Compatibility with One-Time Passcodes 329 330 We solicit discussion on how the use of public key crytpgraphy for 331 intial authentication will interact with the proposed use of one time 332 passwords discussed in Internet Draft 333 draft-ietf-cat-kerberos-passwords-00.txt 334 3355. Expiration 336 337 This Internet-Draft expires on August 6, 1995. 338 339 3406. Authors' Addresses 341 342 B. Clifford Neuman 343 USC/Information Sciences Institute 344 4676 Admiralty Way #1001 345 Marina del Rey, CA 90292-6695 346 347 Phone: 310-822-1511 348 EMail: bcn@isi.edu 349 350 351 Brian Tung 352 USC/Information Sciences Institute 353 4676 Admiralty Way #1001 354 Marina del Rey, CA 90292-6695 355 356 Phone: 310-822-1511 357 EMail: brian@isi.edu 358 359 360 John Wray 361 Digital Equipment Corporation 362 550 King Street, LKG2-2/Z7 363 Littleton, MA 01460 364 365 Phone: 508-486-5210 366 EMail: wray@tuxedo.enet.dec.com 367 368[1] Note: We have not yet defined the public key encryption method for 369encrypting the enc-sess-key field in the PA-PK-AS-REP. 370 371[2] Note: We are soliciting input on the form of the name. We believe the 372name part must be taken without modification from the certificate, but the 373realm part is open for discussion. 374