idnits 2.17.1 draft-ietf-cat-kerberos-pk-recovery-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 20 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '... nonce [2] INTEGER OPTIONAL, -- Only if in...' RFC 2119 keyword, line 239: '... newKDCPubKey [3] KDCPubKey OPTIONAL...' RFC 2119 keyword, line 302: '... kdcPublicKeyKvno [1] INTEGER OPTIONAL -- New KDC public...' RFC 2119 keyword, line 308: '... OPTIONAL --...' RFC 2119 keyword, line 358: '... nonce [3] INTEGER OPTIONAL, -- copy nonce...' (2 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...-Drafts are ...' == Line 16 has weird spacing: '... months and ...' == Line 17 has weird spacing: '...-Drafts as...' == Line 18 has weird spacing: '...ference mater...' == Line 27 has weird spacing: '...tion of this ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2, 1998) is 9398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 446 looks like a reference -- Missing reference section? '0' on line 352 looks like a reference -- Missing reference section? '1' on line 443 looks like a reference -- Missing reference section? '3' on line 358 looks like a reference -- Missing reference section? '4' on line 362 looks like a reference -- Missing reference section? '5' on line 370 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jonathan Trostle 2 draft-ietf-cat-kerberos-pk-recovery-00.txt 3 Updates: RFC 1510 4 expires August 2, 1998 6 Public Key Cryptography for KDC Recovery in Kerberos V5 8 0. Status Of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other docu- 17 ments at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as ``work in pro- 19 gress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- 23 dow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 The distribution of this memo is unlimited. It is filed as 28 draft-ietf-cat-kerberos-pk-recovery-00.txt, and expires August 2, 29 1998. Please send comments to the authors. 31 1. Abstract 33 This document defines extensions to the Kerberos protocol 34 specification (RFC 1510, ''The Kerberos Network Authentication 35 Service (V5)'', September 1993) to enable the recovery of a 36 compromised Kerberos V5 KDC using public key cryptography. 37 The document specifies the recovery protocol which uses 38 preauthentication data fields and error data fields in Kerberos 39 messages to transport recovery data. 41 2. Motivation 43 For both secret key based systems and public key based systems, 44 compromise of the security server (KDC in the secret key system and 45 CA or certificate authority in the public key system) leads to a 46 complete breakdown of the authentication service. The difference 47 between the two systems comes when the compromise is detected. 48 Assuming that a root key is intact in the public key system, new 49 high-level certificates can be signed, any suspicious certificates 50 can be revoked, and the system can eventually return to normal 51 operation without excessive administrator involvement. For a pure 52 secret key based system such as Kerberos V5, the recovery 53 operation is very difficult from an administrative point of view, 54 since all users must receive new passwords out of band. 56 This document describes an extension to Kerberos V5 that can be 57 used in conjunction with the protocol in [2] 58 (draft-ietf-cat-kerberos-pkinit-05.txt) to allow a KDC to be 59 automatically recovered once the administrator has reinstalled 60 the operating system and loaded (and certified) the new KDC public 61 key. Although the protocols in [2] are a step towards making the KDC 62 recovery problem easier, they do not go far enough since there are 63 still potentially many secret keys stored on the KDC. For example, 64 when the user private key is stored on the KDC, the user and the 65 KDC share a secret key that is used for authentication. The two main 66 issues for recovery are updating the KDC public key with all clients 67 (which will happen automatically if the KDC public keys are signed 68 as part of a public key infrastructure with a revocation 69 capability), and updating the shared secret keys that are stored on 70 the KDC. 72 We now describe the requirements for the recovery extension: 73 (1) Users that use password based keys to authenticate to the KDC 74 (as in section 3.4 of [2] will have those keys automatically changed 75 by the recovery protocol; the users will not have to change their 76 passwords. We will satisfy this requirement by obtaining the secret 77 key K2 of section 3.4 of [2] by hashing the key K1 with a salt value 78 supplied by the KDC. The update operation during recovery consists 79 of changing the salt value. 80 (2) The recovery extension should work either in the case where 81 the KDC public keys are signed as keys in a public key infrastructure 82 or in the case where the KDC public keys are self-signed (i.e., root 83 keys). The second case will be satisfied by downloading multiple 84 KDC public keys into clients and keeping the later version KDC 85 private keys offline. The second case is useful in an environment 86 without a deployed public key infrastructure that includes a 87 revocation mechanism. 89 We will use the definitions and ASN.1 structures from [2]; we assume 90 familiarity on the part of the reader. 92 3. The Recovery Extension Protocol 94 We now briefly overview the proposed recovery extension. When the 95 recovery operation is launched, the KDC host operating system along 96 with the database is reloaded from backup media. The new KDC public 97 key certificate is placed into the appropriate certificate database 98 (if needed), and the old certificate is revoked if the the KDC 99 certificate was signed by another authority. In the case the KDC 100 certificate is self-signed, the KDC contacts the clients that need 101 to receive the new certificate (using the 102 KDC_ERR_RECOVERY_HOST_NEEDED error code in a KRB_ERROR message). 103 This message allows the new self-signed certificates to be 104 downloaded. Also, any secret keys will be updated. The 105 sequence of messages between the KDC and the client is as follows: 107 KDC <-------- AS_REQ (optional) -------- client 109 KDC -------- KRB_ERROR message -------> client 110 (error code KDC_ERR_RECOVERY_HOST_NEEDED) 111 error data: KDC DH parameters, optional self-signed 112 certs, all signed with new KDC private key 114 KDC <-------- AS_REQ message ---------- client 115 (with PA-PK-AS-REQ and PA-PK-RECOVERY-DATA 116 preauthentication fields) 118 KDC -------- AS_REP message ---------> client 119 (with PA-PK-AS-REP preauthentication field) 121 After these exchanges, the recovery operation is complete except for 122 the updating of the kdcSalt value to clients and the creation of new 123 user shared secrets in the KDC database. This last task is completed 124 by the following sequence of messages: 126 KDC <-------- AS_REQ message ----------- client 128 KDC -------- KRB_ERROR message -------> client 129 (error code KDC_ERR_RECOVERY_USER_NEEDED) 130 error data: KDC DH parameters, kdcSalt value, 131 optional PA-PK-KEY-REP (encrypted user private keys)) 133 KDC <-------- AS_REQ message ---------- client 134 (with PA-PK-AS-REQ and PA-PK-RECOVERY-DATA (with new user 135 secret key K2 encrypted in Diffie-Hellman shared secret 136 key) preauthentication fields) 138 KDC -------- AS_REP message ---------> client 139 (with PA-PK-AS-REP preauthentication field) 141 This exchange of messages is only necessary between the KDC and each 142 user principal that has a shared secret key stored in the KDC 143 database. 145 3.1 Definitions 147 The proposed extension includes a new algorithm for computing the 148 shared key between a user and the KDC. The new algorithm involves 149 computing the SHA1 hash of a string (kdcSalt) supplied by the KDC 150 concatenated with the RFC 1510 shared key (the key K1 from section 151 3.4 of [2]) to obtain a new DES key K2 that is shared between the 152 user and the KDC. We propose etype and keytype 16 for this 153 algorithm: 155 DES-recoverable-key 16 157 If the KDC expects the client to preauthenticate using the key K2 158 with keytype DES-recoverable-key, and the client does not 159 preauthenticate, then the e-data for the error 160 KDC_ERR_PREAUTH_REQUIRED will be present containing the kdcSalt 161 value encoded as an OCTET STRING. If the client preauthenticates 162 with the key K2 having keytype DES-recoverable-key, the 163 preauthentication fails, and the KDC has a key of the same keytype 164 in the database, then the e-data for the error KDC_ERR_PREAUTH_FAILED 165 will be present containing the kdcSalt value encoded as an OCTET 166 STRING. 168 As a performance optimization, the kdcSalt is stored in the 169 /krb5/salt file along with the realm. Thus the /krb5/salt file 170 consists of realm-salt pairs. If the file is missing, or the salt is 171 not correct, the above error messages allow the client to find out 172 the correct salt. Clients which are configured for symmetric key 173 authentication with the keytype DES-recoverable-key attempt to 174 preauthenticate with the salt from the /krb5/salt file as an input 175 into their key, and if the file is not present, the client does not 176 use preauthentication. 178 The following new preauthentication types are proposed: 180 PA-PK-RECOVERY-SUPPORTED 19 181 PA-PK-RECOVERY-DATA 20 183 The following new error codes are proposed: 185 KDC_ERR_RECOVER_HOST_NEEDED 67 186 KDC_ERR_RECOVER_USER_NEEDED 68 188 We propose the following additional KDC database bits. The first new 189 KDC database bit applies to all clients (non-human principals) and 190 indicates whether a client supports recovery. The second database bit 191 applies to all principals to indicate whether a principal should have 192 a valid symmetric key in the database. The third bit applies to all 193 principals to indicate if the principal symmetric key in the KDC 194 database is valid. The fourth bit applies to all clients and 195 indicates whether the recovery capable client (this bit is only set 196 if the client is recovery capable) needs to receive self-signed KDC 197 certificates from the KDC. The fifth bit applies to all clients and 198 tells whether the recovery capable client that needs self-signed KDC 199 certificates has received them as part of the most recent recovery 200 operation. 202 The third and fifth database bits are cleared when the KDC undergoes 203 a recovery operation. 205 3.2 Protocol Specification 207 We now describe the recovery protocol. The recovery operation can be 208 set into motion either because a compromise is detected, or as part of 209 a periodic preventative operation. The KDC host operating system and 210 KDC executable is restored from backup media, and the KDC is loaded 211 with a backup private/public key pair. The KDC database is also 212 reloaded, and any secret keys are zeroized. The clients already have 213 the public half of this backup key pair in the form of a self-signed 214 certificate, or the new KDC public key is signed by the appropriate 215 authority and placed in the appropriate location and any necessary 216 revocation steps are taken for the old certificate. 218 Any clients that hold the KDC public keys in the form of self-signed 219 certificates must be notified by the KDC and sent any new self-signed 220 certificates. These clients can now discard the current KDC self 221 -signed certificate (if it has not already been discarded due to an 222 expired validity date). We propose ports 10001/TCP and 10001/UDP as 223 the ports for these clients to listen on. 225 The KDC will notify the clients that need new self-signed certificates 226 and/or to update their secret keys with a KRB_ERROR message with error 227 code KDC_ERR_RECOVERY_HOST_NEEDED. The following ASN.1 structure is 228 encoded and placed into the error message e-data field (an OCTET 229 STRING): 231 HostRecoveryError ::= SEQUENCE { 232 kdcPublicValue [0] SubjectPublicKeyInfo, 233 -- DH algorithm 234 kdcPubValueId [1] INTEGER, -- DH algorithm 235 -- index for KDC 236 nonce [2] INTEGER OPTIONAL, -- Only if in 237 -- response to AS_REQ 238 -- (copy nonce) 239 newKDCPubKey [3] KDCPubKey OPTIONAL 240 -- only if KDC sends 241 -- new self-signed 242 -- certs or kdcCert 243 } 245 KDCPubKey ::= CHOICE { 246 kdcCert [0] SEQUENCE OF Certificates 247 -- KDC cert chain 248 -- from [2] 249 newKDCCertInfo [1] KDCCertInfo 250 } 252 KDCCertInfo ::= SEQUENCE { 253 kdcPublicKeys [0] SEQUENCE OF Certificate 254 -- New KDC self-signed 255 -- certificates 256 kdcPublicKeyKvno [1] INTEGER -- New KDC public 257 -- key kvno 258 } 260 The e-cksum field of the error message is not optional for this error 261 code; it will contain the signature of the entire error message (as 262 described in [1]: the signature is computed over the ASN.1 encoded 263 error message without the e-cksum field, and then the signature is 264 placed into the e-cksum field and the message is re-encoded.) The KDC 265 will sign using the private half of its new active key pair. The key 266 version number for the signing key must correspond to the new 267 KDC certificate. 269 The purpose of the kdcPubValueId identifier in the error message is 270 to enable the KDC to offload state to the client; the client will then 271 send this identifier to the KDC in an AS_REQ message; the identifier 272 allows the KDC to look up the Diffie Hellman private value corresponding 273 to the identifier. Depending on how often the KDC updates its private 274 Diffie Hellman parameters, it will have to store anywhere between a 275 handful and several dozen of these identifiers and their parameters. 277 The newKDCCertInfo field is only present if the KDC sends new self 278 -signed certificates to the client. 280 Note: The non-PKI protocol for recovery depends on the downloading of 281 new public key certificates into the client as a notification mechanism 282 that the old KDC public key certificate is revoked. In the case where 283 some clients are intermitently connected to the network (e.g., laptops 284 and dial-in clients), then the non-PKI protocol for recovery may leave 285 these intermitently connected clients open to server spoofing attacks. 286 One way to solve this problem is to shorten the validity period of the 287 KDC public key certificates. Another solution to the problem is to 288 integrate PKI functionality (a revocation mechanism) into the 289 Kerberos V5 public key clients. 291 If the KRB_ERROR message passes the security checks (the nonce should 292 match the client AS_REQ nonce if the error message is a reply, the KDC 293 signature validates and the signing key has the proper key version 294 number (kvno), and the KDC self-signed certificates are valid), the 295 client replies to the KDC with an AS_REQ message containing the 296 PA-PK-RECOVERY-DATA padata-type preauthentication field along with a 297 PA-PK-AS-REQ preauthentication field (see [2]): 299 PA-PK-RECOVERY-DATA ::= SEQUENCE { 300 kdcPubValueId [0] INTEGER, -- Copied from error 301 -- message 302 kdcPublicKeyKvno [1] INTEGER OPTIONAL -- New KDC public 303 -- key kvno if 304 -- KDCCertInfo was 305 -- present in error 306 -- (copied) 307 newUserKey [2] EncryptedData -- only present in 308 OPTIONAL -- reply to 309 -- KDC_ERR_RECOVERY_ 310 -- USER_NEEDED error; 311 -- uses DH shared 312 -- key to encrypt the 313 -- new key K2. 314 sigAll [3] Signature -- uses shared DH key 315 -- computed over 316 -- entire encoded 317 -- AS_REQ without 318 -- this field, then 319 -- re-encode message 320 -- with this field 321 } 323 The clientPublicValue field in the AuthPack structure must be filled 324 in by the client (in the PA-PK-AS-REQ preauthentication field, since 325 Diffie-Hellman is required). 327 Upon receiving this message from the client, the KDC then makes the 328 normal PA-PK-AS-REQ validation and also checks that the sigAll seal 329 is valid after computing the shared Diffie-Hellman key. We note that 330 the KDC should use the ctime and cusec fields in the PA-PK-AS-REQ 331 message to ensure that the client AS_REQ message is not a replay. 333 (The KDC also checks that the kdcPublicKeyKvno is correct (that it 334 is the current version), and uses the kdcPubValueId to look up its 335 own Diffie-Hellman parameters). 337 The KDC now sends an AS_REP message with the PA-PK-AS-REP 338 preauthentication fields. 339 The client should validate this message (including the normal 340 PA-PK-AS-REP checks) before updating any secret keys or KDC 341 self-signed certificates. 343 To complete the recovery process, the KDC will also notify users 344 that need to update any shared secrets that are stored in the KDC 345 database; a KRB_ERROR message with the error code 346 KDC_ERR_RECOVERY_USER_NEEDED is sent in response to these user's 347 AS_REQ messages that do not contain the PA-PK-RECOVERY-DATA 348 preauthentication types. The following ASN.1 structure is encoded 349 and placed into the error message e-data field (an OCTET STRING): 351 UserRecoveryError ::= SEQUENCE { 352 kdcSalt [0] OCTET STRING, -- to be hashed 353 -- with password 354 -- key K1 355 kdcPublicValue [1] SubjectPublicKeyInfo, 356 -- DH algorithm 357 kdcPubValueId [2] INTEGER, -- DH algorithm 358 nonce [3] INTEGER OPTIONAL, -- copy nonce 359 -- from AS_REQ 360 -- if paPkKeyRep 361 -- is not below 362 paPkKeyRep [4] OCTET STRING OPTIONAL 363 -- ASN.1 encoded 364 -- PA-PK-KEY-REP 365 -- from section 366 -- 3.4 of [2] 367 -- (encrypted 368 -- user private 369 -- keys) 370 kdcCert [5] SEQUENCE OF Certificate, OPTIONAL 371 -- cert chain 372 } 374 The e-cksum field of the error message is not optional for this error 375 code; it will contain the signature of the entire error message (as 376 described in [1]: the signature is computed over the ASN.1 encoded 377 error message without the e-cksum field, and then the signature is 378 placed into the e-cksum field and the message is re-encoded.) The 379 KDC will sign using the private half of its new active key pair. 381 Upon checking the KRB_ERROR message, the client obtains the user 382 password and uses the kdcSalt to compute the new key K2 which is 383 computed by SHA1 hashing the concatenation of the kdcSalt and the 384 key K1 obtained from the user password. The result of the hash is 385 converted into a DES key by truncating the last 12 bytes and fixing 386 the parity on each of the first 8 bytes. The client then responds 387 with a new AS_REQ message that includes both a PA-PK-RECOVERY-DATA 388 padata-type preauthentication field along with a PA-PK-AS-REQ 389 preauthentication field (see [2]). The PA-PK-RECOVERY-DATA must 390 contain the newUserKey field. If the user's AS_REQ message passes 391 the security checks, the KDC will reply with an AS_REP message 392 that contains a PA-PK-AS-REP preauthentication field. The client 393 will validate this message as described in [2]. 395 We also define the PA-PK-RECOVERY-SUPPORTED preauthentication 396 field; it will accompany all AS_REQ messages from clients that 397 support the recovery protocol. It serves as an optimization to 398 allow the KDC to quickly identify whether the requesting client 399 supports recovery. The padata-value for this padata-type is an 400 empty octet string. 402 4. Encryption of User Private Key on KDC 404 We now discuss recovery issues that arise when the user stores his 405 private key on the KDC in a key derived from a password. As in 406 conventional Kerberos V5, it is important that a good password 407 policy be used. This password policy will prevent dictionary 408 attacks against the user private key by an attacker that 409 compromises the KDC. 411 A weakness of using the DES algorithm to encrypt the user private 412 key is that the keyspace is only 56 bits. Thus the attacker that 413 compromises the KDC can perform an offline brute force attack 414 against the encrypted user private key. We list three approaches 415 to improving security with respect to such attacks; we solicit 416 input on these and other approaches. 418 (1) Use a new encryption algorithm for encrypting private keys: a 419 strawman is the following DESX-like algorithm. The password is 420 required to be at least 10 characters and the first 64 bits of it 421 are used as a pre-xor key and as a post-xor key before and after 422 the normal DES encryption step is completed. Perhaps another 423 variable length cipher would be appropriate here. 425 (2) Change the recovery protocol to allow the password derived key 426 K1 that encrypts the user private key to be automatically changed 427 (by hashing it with a KDC supplied value) after a compromise. 429 (3) Force users to change their passwords and private keys after a 430 compromise, or just change passwords and private keys for users that 431 have a lot of access rights. Perhaps an extra bit in the database 432 could be used to indicate which users need to change their password 433 as part of the recovery operation. 435 5. Acknowledgement 437 This work was previously published as part of draft-ietf-cat- 438 kerberos-pkinit-02.txt while the author was employed at Cybersafe 439 Corporation, 1605 NW Sammamish Rd., Suite 310, Issaquah, WA 98027. 441 6. Bibliography 443 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 444 Service (V5). Request for Comments 1510. 446 [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle. 447 Public Key Cryptography for Initial Authentication in Kerberos. 448 ftp://ds.internic.net/internet-drafts/ 449 draft-ietf-cat-kerberos-pkinit-05.txt 451 7. Expiration Date 453 This draft expires on August 2, 1998. 455 8. Authors' Addresses 457 Jonathan Trostle 458 150 Woodside Dr. 459 Provo, UT 84604 461 Email: jtrostle@world.std.com, jtt@aa.net