idnits 2.17.1 draft-black-ips-iscsi-dhchap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1994], [Schneier]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 2002) is 8045 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: 'RFC2945' is mentioned on line 630, but not defined == Missing Reference: 'SEC-IPS' is mentioned on line 639, but not defined == Unused Reference: 'RFC 2284' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC 2945' is defined on line 694, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-03 -- Possible downref: Normative reference to a draft: ref. 'EAP-SRP' ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Downref: Normative reference to an Informational RFC: RFC 2869 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Black 3 Document: draft-black-ips-iscsi-dhchap-01.txt EMC 4 Expires: October 2002 April 2002 6 DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This draft describes an authentication mechanism based on enhancing 32 CHAP [RFC 1994] with a Diffie-Hellman Exchange (see Section 22.1 of 33 [Schneier]) in order to prevent a passive eavesdropper from 34 acquiring sufficient information to perform an off-line dictionary 35 attack on the CHAP secret. The use of this authentication 36 mechanism with iSCSI [iSCSI] is discussed, along with a brief 37 comparison to the existing CHAP and SRP authentication mechanisms 38 in iSCSI. 40 Caution should be exercised in drawing inferences from the fact 41 that the author of this draft is one of the chairs of the IP 42 Storage Working Group. This draft is an individual submission that 43 the IP Storage Working Group is free to adopt, modify, reject, 44 fold, spindle, and/or mutilate as it sees fit. 46 Table of Contents 48 1. Overview......................................................2 49 2. Conventions used in this document.............................3 50 3. Basic CHAP Protocol...........................................3 51 4. Basic Anonymous Diffie-Hellman Key Exchange...................4 52 5. DH-CHAP, Diffie-Hellman Enhanced CHAP.........................6 53 5.1 Bi-directional DH-CHAP....................................7 54 5.2 DH-CHAP additions to DH and CHAP..........................7 55 5.3 iSCSI text keys and values................................8 56 6. Brief Security Comparison of DH-CHAP with CHAP and SRP........8 57 6.1 Passive Eavesdropping.....................................9 58 6.2 Use of Secret Information to Verify Authentication........9 59 6.3 Impersonation and Man-in-the-Middle Attacks...............9 60 6.4 Reflection Attacks.......................................10 61 6.5 IPsec and DH-CHAP........................................11 62 6.6 Passwords vs. Machine-generated keys.....................11 63 7. External Authentication Server Considerations................12 64 7.1 DH-CHAP and EAP..........................................12 65 7.1.1 Successful Authentication..............................13 66 7.2.2 Unsuccessful Authentication............................13 67 8. Security Considerations......................................13 68 9. Open Issues..................................................13 69 10. Change Log..................................................14 70 10.1 -00 to -01..............................................14 71 References......................................................14 73 1. Overview 75 DH-CHAP is a new combination of an unauthenticated Diffie-Hellman 76 (DH) key exchange (see Section 22.1 of [Schneier]) with the 77 existing CHAP algorithm [RFC 1994]. CHAP is vulnerable to an 78 offline dictionary attack in that an eavesdropper who observes the 79 CHAP challenge and response obtains information sufficient to test 80 an unlimited number of candidates for the CHAP secret off-line. 81 This offline attack succeeds more often than random chance would 82 predict because CHAP secrets are often human-selected passwords, 83 and humans aren't very good at selecting random passwords. For 84 example, they often use words that can be found in a dictionary. 85 DH-CHAP strengths CHAP in a fashion that requires an attacker to 86 perform an online attack in order to capture the information 87 required to mount an off-line dictionary attack. The three primary 88 design goals of DH-CHAP are: 90 (1) Prevent a passive dictionary attack on CHAP via use of a DH 91 exchange. An active attacker (e.g., impersonator or man-in-the- 92 middle) can still gain sufficient information to mount an off- 93 line dictionary attack. 95 (2) Stay as close to CHAP as possible. The ability to use existing 96 RADIUS servers to verify authentication of DH-CHAP is desirable, 97 although there are security considerations involved in doing so. 98 (3) Invent as little as possible. Every innovation in this sort of 99 security protocol is an opportunity for subtle errors that can 100 have major security consequences. 102 The basic idea behind DH-CHAP is to augment the CHAP challenge with 103 the key that results from the Diffie-Hellman exchange so that the 104 CHAP response depends on both of them. Section 3 describes the 105 basic CHAP algorithm, Section 4 describes a basic unauthenticated 106 Diffie-Hellman key exchange, and Section 5 specifies how DH-CHAP 107 combines them. 109 2. Conventions used in this document 111 I - Initiator 112 R - Responder 113 | - Concatenation operation 114 H[] - One-way hash function 116 CHAP requires the MD5 one-way hash function for interoperability, 117 and there is existing equipment that only supports MD5. SHA-1 is 118 cryptographically preferable for new protocols. In order to use 119 SHA-1, it will need to be registered in the IANA PPP Authentication 120 Algorithms registry (http://www.iana.org/assignments/ppp-numbers, 121 PPP AUTHENTICATION ALGORITHMS section). 123 Additional notation for each protocol is introduced in the section 124 describing that protocol. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 128 this document are to be interpreted as described in [RFC 2119]. 130 3. Basic CHAP Protocol 132 CHAP is specified in [RFC 1994]. This is an authentication 133 algorithm where the Initiator proves to the Responder that the 134 Initiator knows a secret (e.g., password) that is also known to the 135 responder without passing the secret in the clear to the Responder. 136 The following notation is used here: 138 C_k - CHAP secret, shared by I and R 139 C_i - CHAP identifier, 1 octet 140 C_c - CHAP challenge, 16 octets when MD5 is used, MUST be 141 generated from a source of real randomness 142 C_r - CHAP response, 16 octets when MD5 is used, computed 143 from the above three 145 The CHAP secret, C_k is often a human-selected password, and hence 146 is the source of CHAP's vulnerability to dictionary attacks. The 147 CHAP protocol consists of the following steps: 149 (1) The Initiator requests service from the Responder and sends a 150 list of acceptable CHAP hash algorithms: 152 I ---- algorithm list ----> R 154 (2) The responder selects a hash algorithm, generates a random 155 challenge, C_c, chooses an identifier, C_i and replies: 157 I <---- algorithm, C_i, C_c ---- R 159 (3) The Initiator computes the response, C_r = H[C_i|C_k|C_c] and 160 replies: 162 I ---- C_r ----> R 164 (4) The responder independently computes C_r' = H[C_i|C_k|C_c]. 165 Authentication succeeds if C_r == C_r'. I and R both know C_i 166 and C_c, hence this equality demonstrates to R that I knows C_k. 168 The computation of C_r' and the comparison may be outsourced to a 169 RADIUS server or other external server capable of verifying CHAP 170 authentication. R sends the username, C_i, C_c, and C_r to the 171 server and asks if the response is correct. This allows the 172 secret, C_k to be stored in the external server rather than the 173 Responder. 175 RFC 1994 specifies that the CHAP Identifier (C_i) is returned at 176 step (3). iSCSI prohibits this, and C_i is omitted from step 3 in 177 the above description to match the iSCSI specification. 179 4. Basic Anonymous Diffie-Hellman Key Exchange 181 A description of the anonymous Diffie-Hellman key exchange protocol 182 can be found in Section 22.1 of [Schneier]. This is a key exchange 183 protocol where the Initiator and Responder agree on a secret key 184 whose contents are computationally intractable to determine from 185 the messages they exchange. For brevity, the acronym DH will be 186 used to refer to this protocol. The following notation is used 187 here: 189 x - first random number 190 y - second random number 191 n - field prime 192 g - generator 193 k - generated key 195 The random numbers MUST be generated from sources of real 196 randomness. DH is based on modular (mod n) arithmetic in a finite 197 field, which is often referred to as a group. The security 198 properties of DH depend strongly on the size of the field and 199 numerical properties of both the field prime and generator; see 200 [Schneier] for further discussion. Current practice is to specify 201 fixed values that are known to be secure for a small selection of 202 different field sizes. 204 The protocol is shown here with Bob as the Initiator and Alice as 205 the Responder in order to match the structure in which it is used 206 by DH-CHAP. 208 (1) The Initiator requests service from the Responder: 210 I ---- request for service ----> R 212 (2) The Responder generates the first random number, x, computes 213 g^x mod n and replies: 215 I <---- g^x mod n ----> R 217 (3) The Initiator generates the second random number, y, computes 218 g^y mod n and replies: 220 I ---- g^y mod n ----> R 222 (4) Both parties can now calculate the resulting key: 223 - The Initiator generated y and received g^x mod n, and so 224 calculates k = (g^x mod n)^y mod n = g^xy mod n . 225 - The Responder generated x and received g^y mod n, and so 226 calculates k' = (g^y mod n)^x mod n = g^xy mod n . 228 A passive eavesdropper will find it computationally daunting to 229 calculate g^xy mod n from the g^x mod n and g^y mod n that she 230 can observe. In essence this requires calculating x from g^x mod n 231 or y from g^y mod n, and calculation of these sort of discrete 232 logarithms in a finite field is very difficult. 234 The key exchange ends here, but two more things usually happen when 235 the exchanged key is used in practice: 236 (1) k and k' are employed in a fashion where something goes 237 seriously wrong if k != k'. 238 (2) k and k' tend to be large numbers (e.g., kilobits) with low 239 relative entropy, in that they possess randomness equivalent to 240 true random numbers with far fewer bits. A one-way hash is a 241 useful tool to produce smaller numbers with higher entropy 242 (e.g., that make good session keys). 244 5. DH-CHAP, Diffie-Hellman Enhanced CHAP 246 DH-CHAP is specified here. This is an authentication algorithm 247 where the Initiator proves to the Responder that the Initiator 248 knows a secret (e.g., password) that is also known to the responder 249 without passing the secret in the clear to the Responder, or 250 passing information between the parties that is sufficient for a 251 passive eavesdropper to mount a dictionary attack against the 252 secret. 254 The basic idea is to augment the CHAP challenge, C_c, with the key, 255 k, that results from the Diffie-Hellman exchange so that the CHAP 256 response, C_r, depends on both of them. The following additional 257 notation is used here: 259 C_ca - the augmented challenge from which the DH-CHAP 260 response is generated. 262 The DH-CHAP protocol proceeds as follows: 264 (1) The Initiator requests service from the Responder and sends a 265 list of acceptable CHAP hash algorithms: 267 I ---- algorithm list ----> R 269 (2) The Responder selects a hash algorithm, generates the initial 270 CHAP challenge, C_c, and the first random number x. The 271 Responder then computes g^x mod n, chooses a CHAP identifier, 272 C_i, and replies: 274 I <---- algorithm, g^x mod n, C_i, C_c ---- R 276 (3) The Initiator generates the second random number, y, computes: 277 g^y mod n 278 C_ca = H[C_c|(g^x mod n)^y mod n] = H[C_c|g^xy mod n] 279 C_r = H[C_i|C_k|C_ca] 281 and replies: 283 I ---- C_r, g^y mod n ----> R 285 (4) The Responder now computes: 286 C_ca' = H[C_c|(g^y mod n)^x mod n] = H[C_c|g^xy mod n] 287 C_r' = H[C_i|C_k|C_ca'] 289 Authentication succeeds if C_r == C_r'. 291 The computation of C_r' and the comparison could be outsourced to a 292 RADIUS server or other external server capable of verifying CHAP 293 authentication. R sends the username, C_i, C_ca', and C_r to the 294 external server and asks if the response is correct. This allows 295 the secret, C_k, to be stored in the external server rather than 296 the Responder. A one-way hash is used to generate C_ca in order to 297 make this possible (if C_ca were just C_c|g^xy mod n without the 298 hash, it would be much larger than these servers expect, and using 299 a subset of g^xy mod n's bits would sacrifice much of the strength 300 of the key exchange). Outsourcing this verification has security 301 implications that are discussed in Section 7. 303 5.1 Bi-directional DH-CHAP 305 Section 10.5 of [iSCSI] describes the use of two overlapped 306 instances of CHAP to accomplish bi-directional authentication. 307 (NOTE: This is not "mutual" authentication as the authentications 308 in each direction are not cryptographically linked.) Each instance 309 requires a hash on each side, so two instances would require two 310 hash calculations (and in each case, one could be outsourced to a 311 RADIUS server). 313 DH-CHAP adds two exponentiations and an additional hash calculation 314 to each side. A simpleminded application of DH-CHAP to the two 315 CHAP instances in the previous paragraph would result in a total of 316 four exponentiations on each side to perform two Diffie-Hellman 317 exchanges. Exponentiations are sufficiently expensive calculations 318 to merit optimizing, and the optimization is straightforward. The 319 g^xy mod n generated from a single DH exchange can be used for both 320 DH-CHAP exchanges because in each case, g^xy mod n is concatenated 321 to a different random challenge (C_c) before applying the hash that 322 calculates C_ca and C_ca'. DH-CHAP may qualify as mutual 323 authentication, because both participants "sign" the same key 324 derived from a DH exchange, but mutual authentication was not among 325 DH-CHAP's design goals. 327 5.2 DH-CHAP additions to DH and CHAP 329 The only addition that DH-CHAP makes to the base DH and CHAP 330 protocols is the calculation of C_ca and C_ca' as a hash of the DH 331 key appended to the transmitted CHAP challenge, specifically: 333 C_ca = H[C_c|(g^x mod n)^y mod n] = H[C_c|g^xy mod n] 334 C_ca' = H[C_c|(g^y mod n)^x mod n] = H[C_c|g^xy mod n] 336 This was added in this form to ensure that DH-CHAP can produce 337 challenges and responses in the forms expected by existing servers 338 that verify CHAP responses (e.g., RADIUS servers). All other 339 computations specified above and quantities sent in DH-CHAP 340 messages are present in the original DH or CHAP algorithms. 342 DH_CHAP retains the challenge, C_c, for similarity to CHAP, and 343 because it avoids having to invent a way to use the same DH 344 exchange for both directions of bi-directional authentication. The 345 existence of C_c poses a slight increase of difficulty to an 346 attacker who has somehow defeated the DH exchange, but in practice 347 defeating the DH exchange is primary obstacle facing such an 348 attacker. 350 5.3 iSCSI text keys and values 352 DH-CHAP is a different algorithm from CHAP. To negotiate DH-CHAP 353 for iSCSI authentication, a "DHCHAP" value needs to be added to the 354 set of values defined for the AuthMethod key. The following keys 355 need to be defined for DHCHAP's usage: 357 DHCHAP_A - DH-CHAP algorithm list or algorithm, similar to 358 CHAP_A 359 DHCHAP_I - DH-CHAP identifier, similar to CHAP_I 360 DHCHAP_C - DH-CHAP challenge, similar to CHAP_C 361 DHCHAP_N - DH-CHAP name, similar to CHAP_N 362 DHCHAP_R - DH-CHAP response, similar to CHAP_R 363 DHCHAP_GX - g^x mod n sent from Responder to Initiator 364 DHCHAP_GY - g^y mod n sent from Initiator to Responder 366 When the DH-CHAP authentication method is the result of AuthMethod 367 negotiation, the CHAP keys (CHAP_*) MUST NOT be used. When the 368 CHAP authentication method is the result of AuthMethod negotiation, 369 the DH-CHAP keys (DHCHAP_*) MUST NOT be used. 371 In addition, the DH_CHAP field prime and generator MUST be 372 communicated from Initiator to Responder at step (1) (same approach 373 as used for SRP with iSCSI): 375 DHCHAP_DHN - DH field prime, n in Sections 4 and 5 376 DHCHAP_DHG - DH generator, g in Sections 4 and 5 378 As is the case for SRP authentication in iSCSI, these are announced 379 values that cannot be negotiated; the Responder MUST either accept 380 them or close the connection. There is an open issue in this area; 381 see Section 9. 383 6. Brief Security Comparison of DH-CHAP with CHAP and SRP 385 This section attempts to summarize important points of comparison 386 among DH-CHAP and the CHAP and SRP authentication methods already 387 specified in iSCSI. This is not intended to be a complete list, 388 but rather a listing of the important points. The author intends 389 to revise this section to reflect important points from discussion 390 on the mailing list as they develop. 392 6.1 Passive Eavesdropping. 394 CHAP allows a passive eavesdropper to gain information sufficient 395 to mount an off-line dictionary attack on the CHAP secret. DH-CHAP 396 prevents this, but in a fashion that may restrict DH-CHAP usage of 397 existing servers (e.g., RADIUS) that verify CHAP authentication; 398 see Section 7. SRP protects its secret from passive eavesdropping. 400 6.2 Use of Secret Information to Verify Authentication 402 SRP does not require secret information to be stored at the 403 Responder if bi-directional authentication is not required; the SRP 404 verifier can be made public without revealing secret information. 405 Both CHAP and DH-CHAP require that the Responder or the system that 406 verifies authentication for the Responder have access to the CHAP 407 or DH-CHAP secret, C_k. 409 6.3 Impersonation and Man-in-the-Middle Attacks 411 An impersonation attack involves an attacker who does not know the 412 secret impersonating a communicating party. A man-in-the-middle 413 attack involves the attacker inserting himself between the 414 communicating parties to read and modify communication between 415 them. SRP prevents impersonation and man-in-the middle attacks 416 from obtaining the secret or information sufficient to mount a 417 dictionary attack on it. 419 Impersonation and man-in-the-middle attacks on CHAP and DH-CHAP 420 disclose sufficient information to mount an off-line dictionary 421 attack against the secret (C_k). CHAP and DH-CHAP Initiators are 422 vulnerable to both sorts of attacks. CHAP and DH-CHAP Responders 423 are not vulnerable to impersonation attacks because bi-directional 424 CHAP and DH-CHAP as used in iSCSI require the Initiator to 425 authenticate first, and forbid the Responder from sending its 426 response if that authentication fails (see Section 6.4). CHAP 427 Responders are vulnerable to man-in-the-middle attacks because the 428 man-in-the-middle need only imitate a passive eavesdropper to 429 succeed. DH-CHAP Responders are not vulnerable to man-in-the- 430 middle attacks because the man-in-the-middle (M) has to conduct two 431 independent Diffie-Hellman exchanges with I and R in order to 432 capture the information required to mount a dictionary attack on 433 DH-CHAP. In this case: 435 I <-- DH-CHAP <1> --> M <-- DH-CHAP <2> --> R 437 k (at I) and k' (at R) will not be the same because they depend on 438 different random numbers whose generation (at I and R) M cannot 439 control. As a result, authentication of I will fail because I will 440 have sent a response (C_r) based on k which is different from k'; 441 thus failure causes R to not send its response. The failed 442 authentication of I occurs too late to protect I; M already has I's 443 response, but this failure may serve as a warning that an attack 444 may have taken place. 446 Impersonation attacks against one-way authentication are hard to 447 detect because the impersonating attacker is not required to 448 authenticate, and hence can simulate any one of a number of 449 plausible reasons to terminate the connection after obtaining the 450 information of interest. For SRP, this is of no consequence, as 451 the attacker obtains no useful information about the secret, but 452 this is a risk for both CHAP and DH-CHAP. 454 Impersonation attacks against bidirectional authentication may 455 simulate failure of Initiator authentication (e.g., by closing the 456 connection instead of responding). iSCSI Initiators MUST treat any 457 login failure that causes bi-directional CHAP or DH-CHAP to fail to 458 complete after the Initiator has sent its response as a potential 459 security issue (e.g., treat the error in the same fashion as an 460 authentication failure). 462 6.4 Reflection Attacks 464 The topic of reflection attacks was raised on the list, described 465 as "the Target sends you a challenge, the Initiator sends the same 466 challenge back to the Target". If the same CHAP or DH-CHAP secret 467 (C_k) is being used for both directions of a bi-directional 468 authentication, the Initiator and Target responses (C_r) are 469 identical if the identifier (C_i) is also reflected. In this 470 situation, if the Target responds to the challenge, it provides a 471 rogue Initiator with the exact response (C_r) that is required to 472 authenticate the Initiator to the Target. Needless to say, this 473 must not be permitted to occur. 475 As CHAP and DH-CHAP are used in iSCSI, this reflection attack is 476 almost prevented by the requirement that a Target MUST NOT continue 477 if authentication of the Initiator fails. That requirement needs 478 to be strengthened to require that a Target MUST NOT send its CHAP 479 or DH-CHAP response if the Initiator has not successfully 480 authenticated. 482 For example, the following exchange: 484 I->R CHAP_A(A1,A2,...) 485 R->I CHAP_A, CHAP_C, CHAP_I 486 I->R CHAP_A, CHAP_C, CHAP_I 488 MUST result in the Responder (Target) closing the iSCSI TCP 489 connection because the Initiator has failed to authenticate (there 490 is no CHAP_R in the third message). In addition Initiators MUST 491 NOT reuse the CHAP or DH-CHAP challenge sent by the Target for the 492 other direction of a bi-directional authentication. Targets MUST 493 check for this condition and close the iSCSI TCP connection if it 494 occurs. 496 6.5 IPsec and DH-CHAP 498 Neither CHAP nor DH-CHAP defend against all active attacks such as 499 impersonation and man-in-the-middle, and CHAP does not defend 500 against a passive eavesdropper. In environments where these or 501 other active attacks are a concern, DH-CHAP SHOULD NOT be used 502 without additional protection. IPsec (IKE and ESP) provides the 503 iSCSI defenses against these classes of attacks. 505 The iSCSI requirement for IPsec is "MUST implement," not "MUST 506 use," and one can expect that administrators will choose not to use 507 IPsec for a variety of reasons. To deal with such situations, the 508 "MUST implement" iSCSI authentication mechanism needs to have an 509 appropriate level of security on its own, although this level of 510 security need not defend against all the attacks that IPsec 511 prevents. For example, sending passwords in the clear and relying 512 on IPsec to address all security issues would not be acceptable. 514 When IPsec is not in use, an attacker may choose to wait until 515 authentication is complete and attack (e.g., hijack) the TCP 516 connection, but attacking CHAP or DH-CHAP may yield something more 517 valuable - a secret that could be used to authenticate in the 518 future. Hence defending against dictionary attacks can still be 519 important when IPsec is not in use. 521 6.6 Passwords vs. Machine-generated keys 523 The dictionary attacks against CHAP and DH-CHAP are based on the 524 assumption that the CHAP and DH-CHAP secrets are human-generated 525 passwords. If these secrets were instead machine-generated keys 526 with sufficient randomness (e.g., 128 bits would suffice), 527 vulnerability to dictionary attack would no longer be a concern 528 (e.g., an off-line exhaustive search attack against a 128-bit CHAP 529 key generated from real randomness is prohibitively expensive to 530 mount). The downside of such keys is that they are difficult for 531 humans to handle and hence require administrative mechanisms to 532 transfer and install keys (e.g., instead of writing the password on 533 a scrap of paper, an administrator could carry a floppy between 534 systems assuming that all systems involved have floppy drives). 535 Systems that use IP Storage (especially iSCSI) may have a circular 536 dependency if the IP Storage may be required to boot the system to 537 the point that the mechanism to accept the key required to access 538 the IP Storage becomes operational. 540 7. External Authentication Server Considerations 542 If a RADIUS or some other external server is used to verify DH_CHAP 543 responses, the connection between the Responder and that server may 544 be the weak link because the C_ca' and C_r sent over that 545 connection provide sufficient information to mount a passive 546 dictionary attack on C_k. If an eavesdropper can observe these 547 values by monitoring that connection, DH-CHAP's additional 548 protection against passive attack gained from the Diffie-Hellman 549 exchange is lost. Any such connection to an external server to 550 verify DH-CHAP responses MUST use confidentiality (e.g., IPsec ESP) 551 or be protected from eavesdroppers via other means. Examples of 552 "other means" include use of a separate isolated network for all 553 RADIUS traffic to protect against eavesdroppers, and the use of 554 traffic filters to prevent RADIUS traffic from escaping into areas 555 of the network that are vulnerable to eavesdroppers. For bi- 556 directional usage of DH-CHAP, this requirement also applies to any 557 connection from an Initiator to an external response verification 558 server. 560 7.1 DH-CHAP and EAP 562 The Extensible Authentication Protocol (EAP) (defined in [RFC 563 2284], being updated in [2284bis]) describes a framework that 564 allows the use of multiple authentication mechanisms. This section 565 (based loosely on section 6 of [EAP-SRP]) shows examples on how DH- 566 CHAP might be used with EAP, but does not give the formal 567 definition that would be needed to actually do so. 569 With the extensions to RADIUS (as defined in [RFC 2869]), the 570 authenticating endpoint can be moved to a RADIUS server, or even 571 beyond to a back end authentication server. This avoids some of 572 the security issues discussed in the previous section on RADIUS by 573 not exposing any more information that what is already exposed 574 between the peer systems. Note that a RADIUS server would have to 575 be upgraded though (in some way) to support EAP DH-CHAP, or any new 576 EAP protocol. 578 In the following examples, the named parameters (g, n, C_i, C_c, 579 C_r) are the same as described in the previous sections. DH-CHAP 580 represents the EAP Type that would be assigned for EAP DH-CHAP. 581 The id parameter is used to match EAP-Responses with EAP-Requests. 582 Note that if DH-CHAP is always used with EAP, the C_i parameter 583 could be removed. 585 7.1.1 Successful Authentication 587 In the case where the EAP DH-CHAP authentication is successful, 588 the conversation may appear as follows: 590 Authenticatee Authenticator 591 ----------------------------- ------------------------------------- 592 <- EAP-Request id=65 / Identity 593 EAP-Response id=65 / Identity 594 ("Initiator") -> 595 <- EAP-Request id=66 / DH-CHAP 596 (g^x mod n, g, n, C_i, C_c) 597 EAP-Response id=66 / DH-CHAP 598 (g^y mod n, C_r) -> 599 <- EAP-Success id=67 600 7.2.2 Unsuccessful Authentication 602 In the case where the EAP DH-CHAP authentication is unsuccessful, 603 the conversation may appear as follows: 605 Authenticatee Authenticator 606 ----------------------------- ------------------------------------- 607 <- EAP-Request id=79 / Identity 608 EAP-Response id=79 / Identity 609 ("Initiator") -> 610 <- EAP-Request id=80 / DH-CHAP 611 (g^x mod n, g, n, C_i, C_c) 612 EAP-Response id=80 / DH-CHAP 613 (g^y mod n, C_r) -> 614 <- EAP-Failure id=81 616 8. Security Considerations 618 This entire draft is about security. 620 9. Open Issues 622 Group support. Need a list of Diffie-Hellman groups or group sizes 623 that MUST be supported and a list of g and n values that SHOULD be 624 used for various sizes of groups. This is also the case for SRP, 625 for which Section 7.2 of [iSCSI] says: 627 The strength of the SRP authentication method (specified in 628 Chapter 13) is dependent on the characteristics of the group 629 being used (i.e., the prime modulus N and generator g). As 630 described in [RFC2945], N is required to be a Sophie-German prime 631 (of the form N = 2q + 1, where q is also prime) and the generator 632 g is a primitive root of GF(n). In iSCSI authentication, the 633 prime modulus N MUST be at least 768 bits. 635 Upon receiving N and g from the Target, the Initiator MUST verify 636 that they satisfy the above requirements (and otherwise, abort 637 the connection). This verification MAY start by trying to match N 638 and g with a well-known group that satisfies the above 639 requirements. Well-known SRP groups are provided in [SEC-IPS]. 641 A better approach may be to explicitly require support and use of 642 specific groups in order to avoid the need to test for N being a 643 Sophie-German prime and g being a primitive root of GF(n). 645 The current design of bi-directional DH-CHAP protects responders 646 from rogue initiators, but not vice-versa. This could be changed 647 by having the responder (target) authenticate first rather than the 648 initiator. It's not clear that this makes a significant 649 difference, as a successful dictionary attack against a responder 650 secret can be used to impersonate the responder to the initiator to 651 attack the initiator directly or obtain information to mount a 652 dictionary attack on the initiator's secret. 654 10. Change Log 656 10.1 -00 to -01 658 - Changed author from "Hain" to "Black" in pp.2+ footers. 660 - Rewrote section 6.4 to incorporate explanation and example of 661 reflection attack from Paul Koning. 662 - Removed "(which will generally lead to an authentication 663 failure)" from the Overview, as it is not true of impersonation 664 attacks on one-way authentication. 665 - Strengthened the warning in Section 6.5 that IPsec needs to be 666 used when active attacks against DH-CHAP are a concern. 667 - Lots of editorial changes. 669 References 671 [2284bis] L. Blunk, J. Vollbrecht, B Aboba, "Extensible 672 Authentication Protocol (EAP)," draft-ietf-pppext-rfc2284bis- 673 03.txt, Work in Progress, 2 April 2002. 675 [EAP-SRP] J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1 676 Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt, 677 Work in Progress, July 2001. 679 [iSCSI] Satran, J., et. al., "iSCSI", draft-ietf-ips-iscsi-12.txt, 680 Work in Progress, March 2002. 682 [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication 683 Protocol (CHAP)", RFC 1994, August, 1996. 685 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", RFC 2119, BCP 14, March, 1997. 688 [RFC 2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 689 Protocol (EAP)," RFC 2284, March 1998. 691 [RFC 2869] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", 692 RFC 2869, June 2000. 694 [RFC 2945] Wu, T., "The SRP Authentication and Key Exchange 695 System", RFC 2945, September, 2000. 697 [Schneier] Schneier, B., "Applied Cryptography, Second Edition", 698 New York: John Wiley & Sons, Inc., 1996. 700 Acknowledgements 702 A combination of Diffie-Hellman with CHAP was originally suggested 703 by Steve Bellovin. The augmentation approach of concatenating the 704 DH key to the CHAP challenge was suggested by Uri Blumenthal. 705 Steve Senum contributed the text on EAP in Section 7.1 and its 706 subsections. The explanation of reflection attacks and the example 707 in Section 6.4 are largely based on Paul Koning's discussion of 708 this topic on the IPS mailing list. Improvements have resulted 709 from comments on earlier versions of this draft by a number of 710 people, including Ofer Biran and Mark Bakke. Additional comments 711 on various topics from the IPS WG mailing list have been 712 incorporated. 714 Author's Address 716 David L. Black 717 EMC Corporation 718 42 South Street Phone: +1 (508) 249-6449 719 Hopkinton, Mass., 01748, USA Email: black_david@emc.com