Internet Draft D. Black Document: draft-black-ips-iscsi-dhchap-00.txt EMC Expires: October 2002 April 2002 DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft describes an authentication mechanism based on enhancing CHAP [RFC 1994] with a Diffie-Hellman Exchange (see Section 22.1 of [Schneier] in order to prevent a passive eavesdropper from acquiring sufficient information to perform an off-line dictionary attack on the CHAP secret. The use of this authentication mechanism with iSCSI [iSCSI] is discussed, along with a brief comparison to the existing CHAP and SRP authentication mechanisms in iSCSI. Caution should be exercised in drawing inferences from the fact that the author of this draft is one of the chairs of the IP Storage Working Group. This draft is an individual submission that the IP Storage Working Group is free to adopt, modify, reject, fold, spindle, and/or mutilate as it sees fit. Table of Contents 1. Overview......................................................2 2. Conventions used in this document.............................3 3. Basic CHAP Protocol...........................................3 Black Expires - October 2002 [Page 1] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 4. Basic Anonymous Diffie-Hellman Key Exchange...................4 5. DH-CHAP, Diffie-Hellman Enhanced CHAP.........................5 5.1 Bi-directional DH-CHAP....................................7 5.2 DH-CHAP additions to DH and CHAP..........................7 5.3 iSCSI text keys and values................................8 6. Brief Security Comparison of DH-CHAP with CHAP and SRP........8 6.1 Passive Eavesdropping.....................................8 6.2 Use of Secret Information to Verify Authentication........9 6.3 Impersonation and Man-in-the-Middle Attacks...............9 6.4 Reflection Attacks.......................................10 6.5 IPsec and DH-CHAP........................................10 7. External Authentication Server Considerations................11 7.1 DH-CHAP and EAP..........................................11 7.1.1 Successful Authentication.............................12 7.2.2 Unsuccessful Authentication............................12 8. Security Considerations......................................12 9. Open Issues..................................................13 References......................................................13 1. Overview DH-CHAP is a new combination of an unauthenticated Diffie-Hellman key exchange (see Section 22.1 of [Schneier] with the existing CHAP algorithm [RFC 1994]. CHAP is vulnerable to an offline dictionary attack in that an eavesdropper who observes the CHAP challenge and response obtains information sufficient to test an unlimited number of candidates for the CHAP secret off-line. This offline attack succeeds far more often than random chance would predict because CHAP secrets are often human-selected passwords, and humans aren't very good at selecting random passwords, such as words that can be found in a dictionary. DH-CHAP strengths CHAP in a fashion that requires an attacker to perform an online attack (which will generally lead to an authentication failure) in order to capture the information required to mount an off-line dictionary attack on each CHAP secret. The three primary design goals of DH-CHAP are: (1) Prevent a passive dictionary attack on CHAP via use of a DH exchange. An active attacker (e.g., impersonator or man-in-the- middle) can still gain sufficient information to mount an off- line dictionary attack. (2) Stay as close to CHAP as possible. The ability to use existing RADIUS servers to verify authentication of DH-CHAP is desirable, although there are security considerations involved in doing so. (3) Invent as little as possible. Every innovation in this sort of security protocol is an opportunity for subtle errors that can have major security consequences. The basic idea behind DH-CHAP is to augment the CHAP challenge with the key that results from the Diffie-Hellman exchange so that the Hain Expires - October 2002 [Page 2] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 CHAP response depends on both of them. Section 3 describes the basic CHAP algorithm, Section 4 describes a basic unauthenticated Diffie-Hellman key exchange, and Section 5 specifies how DH-CHAP combines them. 2. Conventions used in this document I - Initiator R - Responder | - Concatenation operation H[] - One-way hash function CHAP requires the MD5 one-way hash function for interoperability, and there is existing equipment that only supports MD5. SHA-1 is cryptographically preferable for new protocols. In order to use SHA-1, it will need to be registered in the IANA PPP Authentication Algorithms registry (http://www.iana.org/assignments/ppp-numbers, PPP AUTHENTICATION ALGORITHMS section). Additional notation for each protocol is introduced in the section describing that protocol. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 3. Basic CHAP Protocol CHAP is specified in [RFC 1994]. This is an authentication algorithm where the Initiator proves to the Responder that the Initiator knows a secret (e.g., password) that is also known to the responder without passing the secret in the clear to the Responder. The following notation is used here: C_k - CHAP secret, shared by I and R C_i - CHAP identifier, 1 octet C_c - CHAP challenge, 16 octets when MD5 is used, MUST be generated from a source of real randomness C_r - CHAP response, 16 octets when MD5 is used, computed from the above three The CHAP secret, C_k is often a human-selected password, and hence is the source of CHAP's vulnerability to dictionary attacks. The CHAP protocol consists of the following steps: (1) The Initiator requests service from the Responder and sends a list of acceptable CHAP hash algorithms: I ---- algorithm list ----> R Hain Expires - October 2002 [Page 3] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 (2) The responder selects a hash algorithm, generates a random challenge, C_c, chooses an identifier, C_i and replies: I <---- algorithm, C_i, C_c ---- R (3) The Initiator computes the response, C_r = H[C_i|C_k|C_c] and replies: I ---- C_r ----> R (4) The responder independently computes C_r' = H[C_i|C_k|C_c]. Authentication succeeds if C_r == C_r'. I and R both know C_i and C_c, hence this equality demonstrates to R that I knows C_k. The computation of C_r' and the comparison may be outsourced to a RADIUS server or other external server capable of verifying CHAP authentication. R sends the username, C_i, C_c, and C_r to the server and asks if the response is correct. This allows the secret, C_k to be stored in the external server rather than the Responder. RFC 1994 specifies that the CHAP Identifier (C_i) is returned at step (3). iSCSI prohibits this, and C_i is omitted from step 3 in the above description to match the iSCSI specification. 4. Basic Anonymous Diffie-Hellman Key Exchange A description of the anonymous Diffie-Hellman key exchange protocol can be found in Section 22.1 of [Schneier]. This is a key exchange protocol where the Initiator and Responder agree on a secret key whose contents are computationally intractable to determine from the messages they exchange. For brevity, the acronym DH will be used to refer to this protocol. The following notation is used here: x - first random number y - second random number n - field prime g - generator k - generated key The random numbers MUST be generated from sources of real randomness. DH is based on modular (mod n) arithmetic in a finite field, which is often referred to as a group. The security properties of DH depend strongly on the size of the field and numerical properties of both the field prime and generator; see [Schneier] for further discussion. Current practice is to specify Hain Expires - October 2002 [Page 4] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 fixed values that are known to be secure for a small selection of different field sizes. The protocol is shown here with Bob as the Initiator and Alice as the Responder in order to match the structure in which it is used by DH-CHAP. (1) The Initiator requests service from the Responder: I ---- request for service ----> R (2) The Responder generates the first random number, x, computes g^x mod n and replies: I <---- g^x mod n ----> R (3) The Initiator generates the second random number, y, computes g^y mod n and replies: I ---- g^y mod n ----> R (4) Both parties can now calculate the resulting key: - The Initiator generated y and received g^x mod n, and so calculates k = (g^x mod n)^y mod n = g^xy mod n . - The Responder generated x and received g^y mod n, and so calculates k' = (g^y mod n)^x mod n = g^xy mod n . A passive eavesdropper will find it computationally daunting to calculate g^xy mod n from the g^x mod n and g^y mod n that she can observe. In essence this requires calculating x from g^x mod n or y from g^y mod n, and calculation of these sort of discrete logarithms in a finite field is very difficult. The key exchange ends here, but two more things usually happen when the exchanged key is used in practice: (1) k and k' are employed in a fashion where something goes seriously wrong if k != k'. (2) k and k' tend to be large numbers (e.g., kilobits) with low relative entropy, in that they possess randomness equivalent to true random numbers with more than an order of magnitude fewer bits. A one-way hash is a useful tool to produce smaller numbers with higher entropy (e.g., that make good session keys). 5. DH-CHAP, Diffie-Hellman Enhanced CHAP DH-CHAP is specified here. This is an authentication algorithm where the Initiator proves to the Responder that the Initiator knows a secret (e.g., password) that is also known to the responder without passing the secret in the clear to the Responder, or Hain Expires - October 2002 [Page 5] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 passing information between the parties that is sufficient for a passive eavesdropper to mount a dictionary attack against the The basic idea is to augment the CHAP challenge, C_c, with the key, k, that results from the Diffie-Hellman exchange so that the CHAP response, C_r, depends on both of them. The following additional notation is used here: C_ca - the augmented challenge from which the DH-CHAP response is generated. The DH-CHAP protocol proceeds as follows: (1) The Initiator requests service from the Responder and sends a list of acceptable CHAP hash algorithms: I ---- algorithm list ----> R (2) The Responder selects a hash algorithm, generates the initial CHAP challenge, C_c, and the first random number x. The Responder then computes g^x mod n, chooses a CHAP identifier, C_i, and replies: I <---- algorithm, g^x mod n, C_i, C_c ---- R (3) The Initiator generates the second random number, y, computes: g^y mod n C_ca = H[C_c|(g^x mod n)^y mod n] = H[C_c|g^xy mod n] C_r = H[C_i|C_k|C_ca] and replies: I ---- C_r, g^y mod n ----> R (4) The Responder now computes: C_ca' = H[C_c|(g^y mod n)^x mod n] = H[C_c|g^xy mod n] C_r' = H[C_i|C_k|C_ca'] Authentication succeeds if C_r == C_r'. The computation of C_r' and the comparison could be outsourced to a RADIUS server or other external server capable of verifying CHAP authentication. R sends the username, C_i, C_ca', and C_r to the external server and asks if the response is correct. This allows the secret, C_k, to be stored in the external server rather than the Responder. A one-way hash is used to generate C_c in order to make this possible (if C_ca = C_c|g^xy mod n without the hash, it would be much larger than most RADIUS servers expect, and using a subset of g^xy mod n's bits sacrifices much of the strength of the key exchange). Hain Expires - October 2002 [Page 6] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 5.1 Bi-directional DH-CHAP Section 10.5 of draft-ietf-ips-iscsi-11.txt describes the use of two overlapped instances of CHAP to accomplish bi-directional authentication. (NOTE: This is not "mutual" authentication as the authentications in each direction are not cryptographically linked.) Each instance requires a hash on each side, so two instances would require two hash calculations (and in each case, one could be outsourced to a RADIUS server). DH-CHAP adds two exponentiations and an additional hash to each side. A simpleminded application of DH-CHAP to the two CHAP instances in the previous paragraph would result in a total of four exponentiations to perform two Diffie-Hellman exchanges. Exponentiations are sufficiently expensive calculations to be worth optimizing, and the optimization is straightforward. The g^xy mod n generated from a single DH exchange can be used for both DH-CHAP exchanges because in each case, g^xy mod n is concatenated to a different random challenge (C_c) before applying the hash that calculates C_ca and C_ca'. DH-CHAP may qualify as mutual authentication, because both participants "sign" the same key derived from a DH exchange, but mutual authentication was not among DH-CHAP's design goals. 5.2 DH-CHAP additions to DH and CHAP The only addition that DH-CHAP makes to the base DH and CHAP protocols is the calculation of C_ca and C_ca' as a hash of the DH key appended to the transmitted CHAP challenge, specifically: C_ca = H[C_c|(g^x mod n)^y mod n] = H[C_c|g^xy mod n] C_ca' = H[C_c|(g^y mod n)^x mod n] = H[C_c|g^xy mod n] This was added in this form to ensure that DH-CHAP can produce challenges and responses in the forms expected by existing servers that verify CHAP responses (e.g., RADIUS servers). All other computations specified above and quantities sent in DH-CHAP messages are present in the original DH or CHAP algorithms. DH_CHAP retains the challenge, C_c, for similarity to CHAP, and because it avoids having to invent a way to use the same DH exchange for both directions of Bi-Directional authentication. The existence of C_c poses a slight increase of difficulty to an attacker who has somehow defeated the DH exchange, but in practice defeating the DH exchange is primary obstacle facing such an attacker. Hain Expires - October 2002 [Page 7] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 5.3 iSCSI text keys and values DH-CHAP is a different algorithm than CHAP. To negotiate DH-CHAP for iSCSI authentication, a "DHCHAP" value needs to be added to the set of values defined for the AuthMethod key. The following keys need to be defined for DHCHAP's usage: DHCHAP_A - DH-CHAP algorithm list or algorithm, similar to CHAP_A DHCHAP_I - DH-CHAP identifier, similar to CHAP_I DHCHAP_C - DH-CHAP challenge, similar to CHAP_C DHCHAP_N - DH-CHAP name, similar to CHAP_N DHCHAP_R - DH-CHAP response, similar to CHAP_R DHCHAP_GX - g^x mod n sent from Responder to Initiator DHCHAP_GY - g^y mod n sent from Initiator to Responder When the DH-CHAP authentication method is the result of negotiation, the CHAP keys (CHAP_*) MUST NOT be used. When the CHAP authentication method is the result of negotiation, the DH- CHAP keys (DHCHAP_*) MUST NOT be used. In addition, the DH_CHAP field prime and generator MUST be communicated from Initiator to Responder at step (1) (same approach as used for SRP with iSCSI): DHCHAP_DHN - DH field prime, n in Sections 4 and 5 DHCHAP_DHG - DH generator, g in Sections 4 and 5 As is the case for SRP authentication in iSCSI, these are announced values that cannot be negotiated; the Responder MUST either accept them or close the connection. 6. Brief Security Comparison of DH-CHAP with CHAP and SRP This section attempts to summarize important points of comparison among DH-CHAP and the CHAP and SRP authentication methods already specified in iSCSI. This is not intended to be a complete list, but rather a listing of the important points. The author intends to revise this section to reflect important points from discussion on the mailing list as they develop. 6.1 Passive Eavesdropping. CHAP allows a passive eavesdropper to gain information sufficient to mount an off-line dictionary attack on the CHAP secret. DH-CHAP prevents this, but in a fashion that may restrict DH-CHAP usage of existing servers (e.g., RADIUS) that verify CHAP authentication; see Section 7. SRP likewise protects its secret from passive eavesdropping. Hain Expires - October 2002 [Page 8] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 6.2 Use of Secret Information to Verify Authentication SRP does not require secret information to be stored at the Responder if bi-directional authentication is not required; the verifier can be made public without revealing secret information. Both CHAP and DH-CHAP require that the Responder or the system that verifies authentication for the Responder have access to the CHAP or DH-CHAP secret, C_k. 6.3 Impersonation and Man-in-the-Middle Attacks An impersonation attack involves an attacker who does not have the secret impersonating a communicating party. A man-in-the-middle attack involves the attacker inserting himself between the communicating parties to read and modify communication between them. SRP prevents impersonation and man-in-the middle attacks from obtaining the secret or information sufficient to mount a dictionary attack on it. Impersonation and man-in-the-middle attacks on CHAP and DH-CHAP disclose sufficient information to mount an off-line dictionary attack against the secret (C_k). CHAP and DH-CHAP Initiators are vulnerable to both sorts of attacks, but Responders are not because bi-Directional CHAP and DH-CHAP as used in iSCSI require the Initiator to authenticate first, and forbid the Responder from sending its response if that authentication fails. CHAP Responders are vulnerable to man-in-the-middle attacks because the man-in-the- middle need only imitate a passive eavesdropper to succeed. DH- CHAP Responders are not vulnerable to man-in-the-middle attacks because the man-in-the-middle (M) has to conduct two independent Diffie-Hellman exchanges with I and R in order to capture the information required to mount a dictionary attack on DH-CHAP. In this case: I <-- DH-CHAP <1> --> M <-- DH-CHAP <2> --> R k (at I) and k' (at R) will not be the same because they depend on different random numbers whose generation (at I and R) M cannot control. As a result authentication of I will fail because I will have signed k which is different from k', and R will not send its response. The failed authentication of I occurs too late to protect I; M already has its response, but this failure may serve as a warning that an attack may have taken place. Impersonation attacks against one-way authentication are hard to detect because the impersonating attacker is not required to authenticate, and hence can simulate any one of a number of plausible reasons to terminate the connection after obtaining the Hain Expires - October 2002 [Page 9] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 information of interest. For SRP, this is of no consequence, as the attacker obtains no useful information about the secret. Impersonation attacks against bidirectional authentication may simulate failure of Initiator authentication (e.g., by closing the connection instead of responding). iSCSI Initiators MUST treat any login failure that causes bidirectional CHAP or DH-CHAP to fail to complete after the Initiator has sent its response as a potential security issue (e.g., treat the error in the same fashion as an authentication failure). 6.4 Reflection Attacks The topic of reflection attacks was raised on the list, described as "the Target sends you a challenge, the Initiator sends the same challenge back to the Target". As CHAP is used in iSCSI, this particular attack is defeated by the requirement that a Target must not continue if authentication of the Initiator fails. This form of reflection attack is also somewhat pointless as it involves an Initiator who has requested Target authentication sending a challenge that results in no useful Target authentication. Initiators MUST NOT reuse the CHAP or DH-CHAP challenge sent by the Target for the other directions of a bi-directional authentication. Targets MUST check for this condition and close the iSCSI TCP connection if it occurs. 6.5 IPsec and DH-CHAP Neither CHAP nor DH-CHAP defend against active attacks such as impersonation and man-in-the-middle, and CHAP does not defend against a passive eavesdropper. IPsec (IKE and ESP) are the iSCSI defenses against such attacks. The iSCSI requirement for IPsec is "MUST implement," not "MUST use." One can expect that administrators will choose not to use IPsec for a variety of reasons. To deal with such situations, the "MUST implement" iSCSI authentication mechanism needs to have an appropriate level of security on its own - for example, sending passwords in the clear and relying on IPsec to address all security issues would not be acceptable - although this level of security need not defend against all the attacks that IPsec prevents. When IPsec is not in use, an attacker may choose to wait until authentication is complete and attack (e.g., hijack) the TCP connection, but attacking CHAP or DH-CHAP may yield something more valuable - a secret that could be used to authenticate in the future, and hence defending against dictionary attacks is still important when IPsec is not in use. 6.6 Passwords vs. Machine-generated keys Hain Expires - October 2002 [Page 10] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 The dictionary attacks against CHAP and DH-CHAP are based on the assumption that the CHAP and DH-CHAP secrets are human-generated passwords. If these secrets were instead machine-generated keys with sufficient randomness (e.g., 128 bits would suffice), vulnerability to dictionary attack would no longer be a concern (e.g., an off-line exhaustive search attack against a 128-bit CHAP key generated from real randomness is prohibitively expensive to mount). The downside of such keys is that they are difficult for humans to handle and hence require administrative mechanisms to transfer and install keys (e.g., instead of writing the password on a scrap of paper, an administrator could carry a floppy between systems assuming that all systems involved have floppy drives). Systems that use IP Storage (especially iSCSI) may have a circular dependency problem in this area as the IP Storage may be required to boot the system to the point that the mechanism to accept the key required to access the IP Storage becomes operational. 7. External Authentication Server Considerations If a RADIUS or other external server is used to verify DH_CHAP responses, the connection between the Responder and that server may be the weak link because C_ca' and C_r are sent over that connection and provide sufficient information to mount a passive dictionary attack on C_k. If an eavesdropper can observe these values by monitoring this connection, the additional protection against passive attack gained from the Diffie-Hellman exchange is lost. Any such connection to an external server to verify DH-CHAP responses MUST use confidentiality (e.g., IPsec ESP) or be protected from eavesdroppers via other means. Examples of "other means" include use of a separate isolated network for all RADIUS traffic to protect against eavesdroppers, and the use of traffic filters to prevent RADIUS traffic from escaping into areas of the network that are vulnerable to eavesdroppers. For Bi-Directional DH-CHAP, this also applies to any connection from an Initiator to an external response verification server. 7.1 DH-CHAP and EAP The Extensible Authentication Protocol (EAP) (defined in [RFC 2284], being updated in [2284bis]) describes a framework that allows the use of multiple authentication mechanisms. This section (based loosely on section 6 of [EAP-SRP]) shows examples on how DH- CHAP might be used with EAP, but does not give the formal definition that would be needed to actually do so. With the extentions to RADIUS (as defined in [RFC 2869]), the authenticating endpoint can be moved to a RADIUS server, or even beyond to a back end authentication server. This avoids some of the security issues discussed in the previous section on RADIUS by Hain Expires - October 2002 [Page 11] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 not exposing any more information that what is already exposed between the peer systems. Note that a RADIUS server would have to be upgraded though (in some way) to support EAP DH-CHAP, or any new EAP protocol. In the following examples, the named parameters (g, n, C_i, C_c, C_r) are the same as described in the previous sections. DH-CHAP represents the EAP Type that would be assigned for EAP DH-CHAP. The id parameter is used to match EAP-Responses with EAP-Requests. Notethat if DH-CHAP is always used with EAP, the C_i parameter could be removed. 7.1.1 Successful Authentication In the case where the EAP DH-CHAP authentication is successful, the conversation may appear as follows: Authenticatee Authenticator ----------------------------- ------------------------------------- <- EAP-Request id=65 / Identity EAP-Response id=65 / Identity ("Initiator") -> <- EAP-Request id=66 / DH-CHAP (g^x mod n, g, n, C_i, C_c) EAP-Response id=66 / DH-CHAP (g^y mod n, C_r) -> <- EAP-Success id=67 7.2.2 Unsuccessful Authentication In the case where the EAP DH-CHAP authentication is unsuccessful, the conversation may appear as follows: Authenticatee Authenticator ----------------------------- ------------------------------------- <- EAP-Request id=79 / Identity EAP-Response id=79 / Identity ("Initiator") -> <- EAP-Request id=80 / DH-CHAP (g^x mod n, g, n, C_i, C_c) EAP-Response id=80 / DH-CHAP (g^y mod n, C_r) -> <- EAP-Failure id=81 8. Security Considerations This entire draft is about security. Hain Expires - October 2002 [Page 12] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 9. Open Issues Group support. Need a list of Diffie-Hellman groups or group sizes that MUST be supported and a list of g and n values that SHOULD be used for various sizes of groups. This is also the case for SRP, for which Section 7.2 of [iSCSI] says: The strength of the SRP authentication method (specified in Chapter 13) is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) and the generator g is a primitive root of GF(n). In iSCSI authentication, the prime modulus N MUST be at least 768 bits. Upon receiving N and g from the Target, the Initiator MUST verify that they satisfy the above requirements (and otherwise, abort the connection). This verification MAY start by trying to match N and g with a well-known group that satisfies the above requirements. Well-known SRP groups are provided in [SEC-IPS]. A better approach may be to explicitly require support and use of specific groups in order to avoid the need to test for N being a Sophie-German prime and g being a primitive root of GF(n). The current design of bi-directional DH-CHAP protects responders from rogue initiators, but not vice-versa. This could be changed by having the responder (target) authenticate first rather than the initiator. It's not clear that this makes much difference, as a successful dictionary attack against a responder secret can be used to impersonate the responder to the initiator to obtain information sufficient to mount a dictionary attack on its secret. References [2284bis] L. Blunk, J. Vollbrecht, B Aboba, "Extensible Authentication Protocol (EAP)," draft-ietf-pppext-rfc2284bis- 03.txt, Work in Progress, 2 April 2002 [EAP-SRP] J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt, Work in Progress, July 2001 [iSCSI] Satran, J., et. al., "iSCSI", draft-ietf-ips-iscsi-11.txt, Work in Progress, March 2002. [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August, 1996. Hain Expires - October 2002 [Page 13] DH-CHAP: Diffie-Hellman Enhanced CHAP for iSCSI April 2002 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March, 1997. [RFC 2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," RFC 2284, March 1998 [RFC 2869] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC 2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September, 2000. [Schneier] Schneier, B., "Applied Cryptography, Second Edition", New York: John Wiley & Sons, Inc., 1996. Acknowledgements A combination of Diffie-Hellman with CHAP was originally suggested by Steve Bellovin. The augmentation approach of concatenating the DH key to the CHAP challenge was suggested by Uri Blumenthal. Steve Senum contributed the text on EAP in Section 7.1 and its subsections. Improvements have resulted from comments on earlier versions of the draft by a number of people, including Ofer Biran, Steve Senum, Mark Bakke, and David Jablon. Comments on this topic from the IPS WG mailing list have been incorporated in various places. Author's Address David L. Black EMC Corporation 42 South Street Phone: +1 (508) 249-6449 Hopkinton, Mass., 01748, USA Email: black_david@emc.com Hain Expires - October 2002 [Page 14]