JARI: Comments marked with "JARI:" JARI: Overall comments: This draft is a good start at describing the problem, but it still needs more work. This includes: - Discussion of the different requirements which lead to the PIC, PEAP, etc. protocols so that we can later evaluate whether the possible limitations caused by the solutions are compatible with those requirements. - Details of the problem description. - Discussion of different "scenarios" before we start talking about solutions. For instance, the impacts of the attacks may be different for strong and weak methods. And different depending on whether or not the same credentials are used for multiple purposes. - Discussion of the "delta" caused to the level of security introduced by (a) the tunneling methods, and (b) the different solutions to fix the binding problem. - Details of achieving a binding: the PRFs used, whether negotiation is needed, exactly when to use the new keys, etc. Some of these issues have been discussed previously as well, and I have understood that the authors are preparing a new version -- so the above may be getting fixed already. EAP Working Group Jose Puthenkulam INTERNET-DRAFT Victor Lortz Category: Informational Intel Corporation Ashwin Palekar 28 October 2002 Dan Simon Bernard Aboba Microsoft The Compound Authentication Binding Problem This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes man-in-the-middle attacks possible when compound authentication methods are used without cryptographically binding the methods together. Several protocols currently being proposed within the JARI: Some are already RFCs, see below. Also, XAUTH, I believe, isn't being proposed to the IETF at this time. Better say "Several protocols are vulnerable ..." IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS, and PEAP. This document reviews potential JARI: And HTTP Digest over TLS! solutions to the problem, including solutions which can be implemented as extensions to the EAP protocol. JARI: I thought we agreed that we wouldn't be reviewing specific solutions yet. It is OK to include a discussion of the potential approaches to solutions, but not necessarily detailed protocol discussions. Table of Contents 1. Introduction .......................................... 3 1.1 Specification of Requirements ................... 3 1.2 Terminology ..................................... 4 2. Overview .............................................. 4 3. Attack scenarios ...................................... 7 4. Potential solutions ................................... 9 4.1 Solution requirements ........................... 9 4.2 Solution mechanisms ............................. 10 4.3 Solution approaches ............................. 13 4.4 Solution scope .................................. 14 5. Normative references .................................. 15 6. Informative references ................................ 17 ACKNOWLEDGMENTS .............................................. 18 AUTHORS' ADDRESSES ........................................... 18 Full Copyright Statement ..................................... 19 1. Introduction This document describes man-in-the-middle attacks against protocols supporting compound authentication methods. Compound authentication methods can occur in sequence, or more commonly, when authentication method(s) are encapsulated within a tunnel which is itself authenticated. JARI: I agree that there's the sequence and the tunnel case. I'm not sure if this is a related third case: Two PPP/RFC 2284 style non-mutual authentications can occur "in parallel" to provide "mutual" authentication. If this has similar problems compared to the sequence case, it may deserve to be mentioned. The vulnerability arises when the peers are not required to demonstrate that they have participated in all of the authentication methods occurring within the exchange. Where an authentication method sequence is used, it is possible for a man-in-the-middle to intercede between the client and server, fooling the client into believing that a single endpoint acted as the server throughout the exchange. Where one or more authentication methods in the sequence is one-way, or is vulnerable to dictionary attack, this can result in disclosure of client credentials to untrusted peers. Where a one-way authenticated tunnel setup is used to derive authentication and/or encryption keys, and subsequent authentication methods are encapsulated inside the tunnel, it is also possible to a man-in-the-middle attack. By shuttling authentication packets between the client and server, the man-in-the-middle can authenticate itself to the server and obtain the authentication and/or encryption keys needed for subsequent communication with the server. For this attack to be successful, it is necessary for the tunneled authentication methods to also be enabled for use outside the tunnel, and for the same credentials to be used for authentication inside and outside the tunnel. A number of protocols currently proposed within the IETF are vulnerable to these attacks. Vulnerable protocols include, but are not limited to: [XAUTH], an IKE extension widely deployed with IPsec VPNs; [PIC], a protocol for certificate enrollment, proposed for use with IPsec VPNs; PANA over TLS [PANATLS], a protocol proposed for use within wireless networks; EAP TTLS [EAPTTLS], an EAP method which tunnels other EAP mechanisms within a TLS tunnel; and Protected EAP [PEAP], a protocol similar to EAP TTLS. JARI: It would be appropriate to document here also the negative impacts for already strong authentication methods. Given the wide scope of this vulnerability, a solution is desirable, and this document describes the benefits and limitations of potential solution approaches. JARI: Hmm.. before we know the "benefits and limitations" I think the verdict is still out on whether the solution is _always_ desireable or only in some specific cases. Maybe you should just start with "This document describes ...". 1.1. Specification of requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: Authenticator The end of the link requiring the authentication. Peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1x) or 802.11 wireless link, which being authenticated by the Authenticator. In IEEE 802.1X, this end is known as the Supplicant. Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service verifies from the credentials provided by the Peer, the claim of identity made by the Peer. Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. JARI: The above definition is unused. Sequenced Methods Authentication methods which are used in sequence one after an another where each completes and the other one starts. The authentication is complete after the final method in the sequence is completed. JARI: Question: Are there other instances of sequenced methods than the potential sequence usage in EAP? Tunneled Methods The first method sets up a tunnel and subsequent method(s) run within the tunnel. JARI: Sets up a cryptographically protected tunnel? 2. Overview The attacks described in this document can be mounted against a number of proposed IETF protocols, including [XAUTH],[PIC],[PANATLS], [EAPTTLS], and [PEAP]. JARI: This list has already appeared. Each of these protocols support authentication tunneling of legacy authentication methods such as CHAP [RFC1994], EAP- MD5 [RFC2284], One-Time-Password (OTP) [RFC1993], Generic Token Card (GTC) [RFC2284], and SecurID [SECURID] in order to provide a number of benefits, including well understood key derivation, replay and dictionary attack protection and privacy support. JARI: I think these benefits are for the tunneling protocols, not for e.g. CHAP... and the list doesn't seem very complete. For instance, nothing PIC related can be found from the above list. Maybe you could update the list, or move the discussion to the specific sections dealing with e.g. EAPTTLS and PEAP? JARI: Regarding privacy support, Asokan et al discuss this in their binding problem paper, and argue that if the given method supports identity privacy, then additional tunneling is not useful. And if it is not supported, then identities are already exposed on the other use of the same credential (remember that the re-use is required for the attacks to become possible). The attacks are enabled when compound authentication techniques are used, allowing clients and servers to authenticate each other with a sequence of methods, or one or more methods encapsulated within an authenticated tunnel. The most common attacks occur when the tunnel is authenticated only from the server to the client, and where tunneled authentication techniques are permitted both inside and outside a tunnel. The tunnel client, having not proved its identity, can act as a man-in-the-middle, luring unsuspecting clients to authenticate to it, using any authentication method suitable for use inside the tunnel. The attacks are possible, even though the tunnels created within these protocols utilize well analyzed protocols such as ISAKMP [RFC2408] and TLS [RFC2246], because mutual authentication (supported within both protocols) is not used. JARI: Can we always use the mutual authentication feature? A quick look at the PIC I-D didn't reveal how to do this. Since the initial authentication only authenticates the server to the client, or provides only an indication of group membership (where group pre-shared keys are used within IKE), and because the keys derived within ISAKMP and TLS are not subsequently included within the tunneled authentication methods, there is no demonstration that the ISAKMP/TLS JARI: Including ISAKMP/TLS keys in the tunneled auth methods is just one way to fix the problem. Maybe say "are not cryptographically bound to the ..." endpoints are the same as the tunneled authentication endpoints. Where authentication techniques are enabled both inside and outside the tunnel, such as when they are in use for multiple purposes (e.g. dialup or web authentication) then an attacker can induce an unsuspecting client to authenticate, then tunnel the authentication within [XAUTH],[PIC],[PANATLS],[EAPTTLS] or [PEAP]. Jari: Right. For the purposes of the attack, it makes no difference whether the authentication method used inside the tunnel supports mutual authentication or not. The vulnerability exists as long as both sides are not required to demonstrate participation in the previous "tunnel authentication" as well as subsequent authentications, and as long as keys derived during the exchange are not dependent on material from *all* of the authentications. JARI: Remove "*"s. Thus it is the lack of client authentication within the initial security association, combined with key derivation based on a one-way tunnel authentication, and lack of "cryptographic binding" between the security association and the tunneled authentication method that enables the vulnerability. In addition, it is necessary for the same authentication methods to be allowed inside and outside of tunnels. JARI: Good. I think though that the key derivation aspect is just something implied by the root cause i.e. lack of cryptographic binding. I'd reformulate as follows: "Thus it is the lack of mutual authentication within the initial security association, and the use of the same authentication credentials inside and outside of tunnels that enables the vulnerability. In addition, lack of "cryptographic binding" between the methods makes the attack possible." JARI: Same method != same credential. I could be using the same method all over, but the crux is using the same password or secret (presumably also with the same method, though I'm not sure if this is always needed). Despite the prevalence of man-in-the-middle vulnerabilities within IETF protocol proposals, it should be noted that these attacks are not the result of design flaws within IKE [RFC2409] or EAP [RFC2284]. IPsec VPN implementations which require strong mutual authentication within the tunnel prior to permitting subsequent authentication are not vulnerable to this attack. For example, when L2TP over IPsec [RFC3193] or IPsec tunnel mode [DHCPIPsec], are used with certificate authentication or unique pre-shared keys, the attack is not possible. By requiring strong mutual authentication via certificates or a unique pre- shared key, the tunnel server obtains the ability to verify the identity of the tunnel client. The tunnel server may then subsequently apply access control in order to limit authentication within the established tunnel. However, where group pre-shared keys are used (as is common in IKE Main Mode implementations that support clients with dynamically allocated IP addresses), followed by one-way authentication mechanisms such as CHAP [RFC1994], the vulnerability is exposed. Since group pre-shared keys only determine group membership but authenticate neither the client nor the server, it is not possible for the server to enforce access controls on individual members of the group. Since CHAP is a widely used authentication method, an attacker can easily gain access to a client willing to engage in CHAP authentication. This allows any client with knowledge of the group pre-shared key to act as a man-in-the-middle for another member of the group. JARI: Interesting! EAP, as defined in [RFC2284], enables a single authentication mechanism to be negotiated and carried out, but does not describe sequences of methods or tunnels. Most existing EAP implementations do not support authentication sequences, and since EAP does not support a version number, a server cannot easily determine whether an EAP client supports sequences. For backward compatibility, it is therefore necessary for the server to assume that authentication sequences are not supported by default. JARI: (If sequences need to be supported at all.) The concept of EAP tunneling has been introduced by recent work-in- progress such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these proposals have not yet been published as RFCs, and are not yet widely deployed. Note that man-in-the-middle vulnerabilities are not a necessary consequence of "credential reuse". For example, they need not necessarily occur where the same authentication credentials are used in accessing the network via multiple media. For example, L2TP [RFC2661] when used in "compulsory tunneling", assumes that the same credentials are used for both PPP and VPN access. PPP dialin users are then permitted to access a VPN by tunneling PPP packets from the network access server (NAS) to the VPN server. JARI: I don't understand the above. Maybe I should re-read the L2TP RFCs (its been a while). I agree that credential reuse, if correctly implemented, doesn't imply mitm vulnerabilities. But I'm not quite sure why PPP - L2TP is credential reuse, and why if it is, why it isn't vulnerable. Because the LAC and the LNS do mutual auth at IPsec level? Where L2TP over IPsec [RFC3193] is deployed using certificate authentication or a unique pre-shared key, the L2TP Network Server (LNS or VPN server) can choose to authorize an authenticated tunnel client to act as an L2TP Access Concentrator (LAC), tunneling PPP dialin users to the L2TP Network Server (LNS). Alternatively, it can disallow this, permitting only a restricted set of users to authenticate within a tunnel established with given machine credentials. 3. Attack scenarios JARI: Before this, maybe we need a section on the reasons why tunneling mechanisms are useful. E.g. PIC certificate bootstrapping. This is necessary for us to compare these requirements against the limitations possibly induced by the solutions to the binding problem. This section describes how man-in-the-middle vulnerabilities can be exploited, as well as discussing the underlying causes of the attacks. Given the many possible attack variations, we do not attempt to describe every potential variant. The major scenario for the attack is a one-way authenticated tunnel encapsulating subsequent authentication methods. In this scenario, the client and server first establish a tunnel, then include within the tunnel one or more authentication method(s). The attacker first poses as a valid client to the server and establishes a tunnel that is authenticated only on the server end, obtaining tunnel keys. Since these keys protect a conversation between an attacker and a server, the strength of the key derivation is not relevant. For the purposes of exploiting the vulnerability, it does not matter whether the tunneling protocol is IKE [RFC2409] authenticated via a group pre-shared key; PIC [PIC], which uses ISAKMP [RFC2408] with one- way authentication; or TLS [RFC2246] with server-only authentication, as used with [PANATLS], [EAPTTLS] or [PEAP]. The effect is the same - a tunnel that does not provide mutual authentication of the tunnel endpoints. JARI: Isn't there one difference though when you use group pre-shared keys? In this case the attacker must be a member of the group, not just anyone as in the other cases. Once the attacker has established a tunnel to the server, it seeks to induce clients to connect to it. This can be accomplished by having the attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a SIP server supporting CHAP, or a VPN server using a protocol such as PPTP [RFC2637]. For the purposes of the attack, it is necessary that the client be induced to authenticate to the attacker using an authentication mechanism permitted within the tunnel. It is also necessary that the credentials within the client protocol and the tunneled authentication protocol are the same, so that the authentication mechanism remains valid when encapsulated within the tunnel. Figure 1 on the next page illustrates the attack, for the case where the attacker acts as a rogue NAS or Access Point. In step 1, the attacker creates a tunnel with the authentication server. This can occur directly in [PIC] or [XAUTH] or through a NAS using EAP [RFC2284]. In step 2, tunnel keys are derived, using server-only authentication via protocols such as ISAKMP [RFC2408], IKE [RFC2409] with group pre-shared keys or TLS [RFC2246]. Since the tunnel is between the attacker and the server, both the server and attacker possess the keys. Client <-|Rogue NAS | NAS Auth Server | Attacker |-> | | | | | | | | | | Tunnel establishment w/ | | | Server Authentication (1) | | |<========================================>| | | | | | (Non-Authenticated | (Authenticated | end of tunnel) | end of tunnel) | | | | | +--------------+ | +--------------+ | | Tunnel | (2) | | Tunnel | | | Keys Derived | | | Keys Derived | | +--------------+ | +--------------+ | | | | | |..........................................| | | Tunnel | | |..........................................| | | (Encrypted using Tunnel keys) | | | | | | | | | | Tunneled authentication method (3) | |<==============================================================>| | | | | | | | | +--------------+ | | +--------------+ | Method | | | | Method | | Keys Derived | (4) | | | Keys Derived | | and used. | | | | Not Used. | +--------------+ | | +--------------+ | | | | | | |<===tunnel keys=========| | | | | | | Client's session| | | | stolen | | |====================+|<===============>| | | Data || | | | dropped v| | | Figure 1 - Man-in-the-middle attack on a one-way authenticated tunnel In the third step, the client connects to the rogue NAS or AP, and the attacker tunnels the authentication method between the client and server. The tunneled authentication method may or may not derive keys, but if it does, then in the fourth step, the method keys are derived on the client and the server. Since the attacker does not obtain the method keys, it is not able to decrypt traffic sent between client and server. However, while the client may use the method keys, the server will typically use only tunnel keys, which have been obtained by the attacker. In the last step, the attacker obtains access to the server, using the successfully tunneled authentication and the tunnel keys. The attacker does not have access to client data, since it is encrypted with the method keys. As a result, it will typically discard the data sent by the client, who will eventually disconnect due to a lack of response. Since the attacker has accomplished its mission, continued interaction with the client is not necessary unless reauthentication is required. 4. Potential solutions This section describes potential solutions to the man-in-the-middle attacks prevously described. This includes a discussion of solution JARI: s/prevously/previously/g requirements as well as identification of potential solution approaches. 4.1. Solution Requirements The following are some of the criteria for a potential solution: Backwards compatibility A solution MUST NOT require modification of existing authentication methods. Since tunneling is used in order to prolong the life of legacy authentication techniques, requiring replacement of existing methods across the board is likely to be unacceptable. Simplicity A solution SHOULD add minimal round trips to the authentication exchange and be modest in its computational complexity. Protocol compatibility Given that tunneling techniques are used with well- established security protocols such as IKE [RFC2409], ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a solution MUST NOT require changes to these protocols. Forward evolution The solution SHOULD be compatible with authentication methods supporting mutual authentication and key derivation. It is acceptable if the solution cannot provide security for tunneling of one-way authentication methods that do not derive keys, such as CHAP, EAP-MD5, OTP, Generic Token Card, or SecurID. As described earlier, these methods are already vulnerable to connection hijacking. Architectural compatibility Solutions MUST NOT require fundamental architectural changes to established technologies such as network access authentication. Since these technologies are already widely deployed, such changes would be likely to be unacceptable. Tunneling protocol independence While a solution MAY introduce changes to tunneling protocols such as [PIC], [PANATLS], [EAPTTLS], or [PEAP], it is preferable that a single solution be applicable to all of these protocols. This is desirable since a single solution will be easiest deploy and also enables the security community to focus efforts on determining whether the proposal is secure. 4.2. Solution mechanisms Several mechanisms are available to solving the problem: [1] Compound MACs. This solution uses Message Authentication Codes (MACs) computed using keying material from each of the authentication methods within a final mutual authenticating round- trip. In order to make sure that both sides are aware of the outcome of the authentication, the compound MAC MUST include coverage of the authentication result (success/failure) sent by each side. This ensures that the server cannot be tricked into using the tunnel key (in the attacker's posession) to authenticate JARI: s/posession/possession/g and encrypt data. [2] Compound keys. This solution combines keying material from all the methods in order to derive keys used for subsequent encryption and authentication of data. Option 1 prevents a man-in-the-middle from gaining authenticated access, and therefore prevents false authenticated states which could result in a Denial of Service attack (possible in Option 2). This makes this approach relatively straightforward to implement, although it does require an additional round-trip. While it is believed that this approach may be sufficient in some cases, further study is required in order confirm this. Option 2 does not require additional round trips, but it enables the man-in-the-middle to authenticate, although not to obtain keys used for subsequent authentication and encryption of data. This implies that the client will only discover an attack when it discovers that it is unable to decipher the incoming data stream. This enables a form of Denial of Service attack and as a result, Option 2 is probably not sufficient by itself. In order to provide the highest level of assurance against man-in-the- middle attacks, it is recommended that a potential solution utilize both options 1 and 2. This prevents a man-in-the-middle from being able to authenticate, spoof an authentication result or derive keys used to authenticate and encrypt traffic between the legitimate client and server. When both solution options are applied, potential man-in-the- middle attacks are thwarted, as shown in Figure 2 on the next page. As before, the man-in-the-middle can establish a one-way authenticated tunnel, obtain tunnel keys, lure an unsuspecting client to authenticate with it, and encapsulate the authentication exchange within the tunnel. However, after the authentication method is complete, compound keys are derived, requiring knowledge of both the tunnel keys and the keys derived during each of the authentication methods. The compound keys are then used in formulation of a compound MAC covering the authentication result, which is sent from server to client. Since the server is not aware of the man-in-the-middle attack in progress, from its perspective the authentication has been successful. Since the client did not participate in establishment of the tunnel, it does not possess the tunnel keys, and cannot verify the compound MAC sent by the server. The client computes its own compound key and compound MAC, covering an indicated authenticate failure. On receiving the client's reply, the server is unable to verify the client's compound MAC, and the authentication fails. As a result, no compound keys are sent to the NAS, and the attacker is neither authenticated nor gains access to the server. Client <-|Rogue NAS | NAS Auth Server | Attacker |-> | | | | | | | | | | Tunnel establishment w/ | | | Server Authentication (1) | | |<========================================>| | | | | | (Non-Authenticated | (Authenticated | end of tunnel) | end of tunnel) | | | | | +--------------+ | +--------------+ | | Tunnel | (2) | | Tunnel | | | Keys Derived | | | Keys Derived | | +--------------+ | +--------------+ | | | | | |..........................................| | | Tunnel | | |..........................................| | | (Encrypted using Tunnel keys) | | | | | | | | | | Tunneled mutual authentication method (3) | | | w/key derivation| | |<==============================================================>| | | | | | | | | +--------------+ | | +--------------+ | Compound | | | | Compound | | Keys Derived | (4) | | | Keys Derived | +--------------+ | | +--------------+ | | | | | | Compound MAC(5)/| | | | Success | | |<===============================================================| | | | | | | Compound MAC(6)/| | | | Failure | | |===============================================================>| | | | | | | | Attack detected | | | | No keys sent | | | | | | | | Failure | | | | <======================| | | | | Figure 2 - Man-in-the-middle attack thwarted by compound MAC and compound keys JARI: It would be useful to discuss somewhere exactly how do we go about constructing a compound MAC key or session key. Do we have to run a PRF to do this? If yes, can we use the PRF already negotiated in, say, TLS. Or do we standardize one PRF that will be used? Do we need to negotiate the PRF? And if we use a MAC, can we standardize a specific MAC function or does that too have depend on what was negotiated in TLS? Also, I'm not sure exactly how the keys are really generated and used. There seems to be multiple ways to produce it: (1) Take master (session) secrets from both mechanisms and PRF them together. (2) Feed additional material from one mechanisms to the other's PRF construction: TLS-master-secret = TLS-PRF(usual-TLS-input, additional stuff from inner EAP method)? JARI: Once there is a compound key, there are also different ways of using it: (i) Turn it on in the outer mechanism as soon as you have it. (ii) Use outer master (session) secret in the inner method (available immediately, method dependent which message actually uses it) (iii) Once you have run everything, send an additional message which includes material from both master (session) secrets. (iv) Compound key is only used for payload data protection. 4.3. Solution approaches Options 1 or 2 can be implemented in different ways: EAP In this approach, the exchange of a compound MAC is supported within EAP, by implementing the exchange as a new EAP method occuring after authentication is complete. Tunnel keys are JARI: s/occuring/occurring/g provided by the tunneling protocol to the EAP layer in order to enable computation of the compound MAC and compound keys. Since existing EAP implementations already enable EAP methods to provide keying material to the EAP layer, such an interface typically already exists. This approach is general in that it ppplies to any tunneling technique. JARI: s/ppplies/applies/g JARI: Disadvantage is that this requires sequence support, even if just tunnels are being used. JARI: A variation: a protected Success. This might have to be be implemented as a new method, though, so its not certain how different this would be. Tunneling method In this approach, the tunneling method acquires keying material derived by the underlying authentication methods, in order to enable computation of the compound MAC and compound keys. Since existing tunneling techniques typically do not provide an interface for receiving keying material from authentication methods, this approach will typically require some re-architecture of existing implementations. It also has the disadvantage of requiring changes to each tunneling method, and as a result is not as general as an EAP-based solution. Given the prevalence of the attacks described within this document, it would represent a considerable burden on the security community to review changes to each individual tunneling approach. However, such an approach may be able to take advantage of properties of the underlying tunnel technology, such as the ability to have more than one packet in transit at a time. EAP methods In this approach, keys derived from previous EAP methods are incorporated into the authentication calculations of subsequent methods. Since existing interfaces only support the export of keys by EAP methods, not importation, some rearchitecture is required in this approach. In addition, this JARI: s/rearchitecture/re-architecture/? approach requires modification of existing EAP methods, which will create deployment barriers. However, this approach may be applied even to methods which support only one-way authentication and do not generate keys. JARI: Which interfaces are we talking about here? Interfaces between EAP mux and EAP methods? What about interfaces to TLS etc, do they always provide export of session keys? Based on the pros and cons of each approach, we recommend a solution that applies to all EAP methods. JARI: I think we are likely to see a number of solutions for different situations. For instance, as noted by Asokan et al, unprotected tunneling of even weak password schemes may be acceptable under certain conditions. And with strong methods, you may want to avoid tunneling. Combination of weak password schemes, credential reuse, and no possibility to upgrade legacy methods maybe unsolvable. JARI: In conclusion, I think we need a treatment of a number of different cases and the impact of various solutions to them. Also, the "solutions" should include (1) the use of these protocols as is, and (2) forbidding the given scenario. 4.4. Solution scope Since EAP is supported within [PIC], [PANATLS], [EAPTTLS] and [PEAP], though not within [XAUTH], implementation of options 1 and 2 within EAP covers most of the vulnerable protocols. There are some exceptions, however. [1] Methods that do not generate keys. In order to verify that the peers acted as end-points in a compound authentication, the peers can exchange compound MACs and compute compound keys. However, authentication schemes which do not derive keys cannot contribute to calculation of a compound MAC or a compound key. Such mechanisms include popular one-way authentication mechanisms such as CHAP [RFC1994], EAP-MD5 [RFC2284], One-Time-Password [RFC1938], Generic Token Card [RFC2284], and [SECURID]. These mechanisms authenticate the client to the server, but do not authenticate the server to the client. They also do not derive keys which can be used in constructing compound MACs and compound keys or providing keying material for authentication and/or encryption of a subsequent data stream. Without requiring changes to existing methods, secure use of these protocols within sequences or tunnels is not feasible. If an authentication method does not generate keys, then keying material is not available with which to compute a compound MAC or compound key. As a result, the compound authentication sequence cannot be bound together, enabling the man-in-the-middle vulnerability to remain. One workaround is to prohibit use of these methods outside a tunnel; there is some logic to this, since without support for key generation, use of these methods outside the tunnel is vulnerable to connection hijacking. JARI: Interestingly, the IKEv2 work binds EAP and IKE keys together. The specification only talks about the RFC 2284 legacy methods. But those methods do not generate keys... [2] Ciphers without authentication support. Where per-packet authentication and integrity protection is not supported, there is no binding between the results of the authentication and subsequent data traffic. This enables connection hijacking. In order to enable a solution for methods such as CHAP, EAP-MD5, OTP, GTC or SECURID, they may be modified so as to enable key derivation, or to incorporate key material derived during the initial tunnel authentication. However, since the motivation for continued use of legacy technologies is to minimize the deployment of new technology, such upgrades are typically impractical. In situations where deployment of a modified legacy method would be feasible, it would also typically be feasible to consider a wide range of alternatives, such as deployment of a new method supporting mutual authentication and key derivation, or deployment of alternative technologies such as certificates. JARI: Right! Given these constraints, it appears difficult for authentication tunneling to provide a long-term solution to the security vulnerabilities inherent in one-way authentication methods such as CHAP, EAP-MD5, OTP, GTC and SecurID. Where protocols such as [PIC] are used to transition from these technologies to certificate-based authentication, it may be possible to restrict the transition to a short time period, as well as to turn off use of the techniques outside of [PIC]. JARI: The use of these methods is secure as long as they are not used for multiple purposes and server side authentication is always checked. It may be OK to continue to use these methods, if one can disable another, non-tunneled use in some controlled manner. For instance, initially you accept CHAP on your dial-ins. Then you want to enable the same credentials for IPsec VPN use. This would lead to a mitm problem. However, if you turn on PEAP at the same time on the dial-in clients as you enable PIC, you may still be OK. Similarly, you could have a transition period where everyone is expected to use their passwords to get certs, and then these certs would there onwards be used for both VPN access (IKE) and dial-in (EAP TLS). The former approach may require a software upgrade to various devices, however. And the latter sounds quite dangerous in the sense that if someone attacked during the period, they are going to have a *permanent* access. So what does transition mean, a temporary use of PIC, while real certs are being delivered? How useful would that be? JARI: The server side authentication is also an interesting issue. Given that we are using these mechanisms mainly for network access, we can usually check a CRL only after the authentication has already taken place. So, if I get my hands on one of the legitimate access point keys, I can spoof server side authentication before the client notices, and consequently... legacy authentication may not be secure in this case even if servers are authenticted and credentials are not reused? Not sure how important this is. These counter-measures may reduce the risk sufficiently to enable certificate deployment to proceed. However, where [PIC] is used to provide short- term certificates, and long-term use of password or token-card based authentication technology is contemplated, improved security will not be possible without a willingness to replace legacy authentication methods with more secure technology. If a transition to certificate-based authentication is not possible, then at the least, one-way authentication technology can be replaced by techniques supporting mutual authentication and key derivation. For example, CHAP may be replaced by Kerberos [RFC1510] or MS-CHAP-V2 [RFC2759] and Generic Token Card may be replaced by token cards supporting key derivation. 5. Normative references [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 1996. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.] [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3193] Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193, November 2001. [EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication Protocol", Internet draft (work in progress), February 2002. [DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel Mode", Internet draft (work in progress), draft-ietf- ipsec-dhcp-13.txt, June 2001. [PEAP] Andersson, H., et al., "Protected EAP Protocol (PEAP)", Internet draft (work in progress), draft-josefsson- pppext-eap-tls-eap-05.txt, September 2002. [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential Provisioning Protocol", Internet draft (work in progress), draft-ietf-ipsra-pic-06.txt, September 2002. [IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec Remote Access Scenarios", Internet draft (work in progress), draft-ietf-ipsra- reqmts-05.txt, September 2002. [GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and Key Retrieval for IKE", Internet draft (work in progress), draft-bellovin-ipsra-getcert-00.txt, June 2000. [SECURID] Josefsson, S., "The EAP SecurID(r) Mechanism", Internet draft (work in progress), draft-josefsson-eap- securid-01.txt, February 2002. [PANATLS] Ohba, Y., et al., "PANA over TLS", Internet draft (work in progress), draft-ohba-pana-potls-00.txt, September 2002. [XAUTH] Pereira, R., Beaulieu, S., "Extended Authentication within ISAKMP/Oakley", Internet-draft (work in progress), draft-beaulieu-ike-xauth-02.txt, September, 2000. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1997, 1997. 6. Informative references [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998. [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", RFC 2486, January 1999. [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998. [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, Nov. 1998. [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, October 1998. [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999. [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995. [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password Security", Stanford University Computer Science Department, http://theory.stanford.edu/~tjw/krbpass.html [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos authentication system", Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991. [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: Kerberos 4 session keys", Proceedings of the Internet Society Network and Distributed System Security Symposium, pp. 60-70, March 1997. [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- to- Point Tunneling Protocol", Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998. [IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996. JARI: Probably should reference Bernard's keying draft as well as the N. Asokan et al paper (not sure which one was first but in any case...) Any other related works? Acknowledgments Thanks to Bernard Aboba for editorial assistance and discussions relevant to this problem space. JARI: Authors should not thank each other here ;-) Authors' Addresses Jose Puthenkulam Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 EMail: jose.p.puthenkulam@intel.com Phone: +1 503 264 6121 Fax: +1 503 264 8154 Victor Lortz Intel Corporation 2111 NE 25th Avenue, JF3-206 Hillsboro, OR 97124 EMail: viktor.lortz@intel.com Phone: +1 503 264 3253 Fax: +1 503 626 0396 Ashwin Palekar Dan Simon Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: {ashwinp, dansimon, bernarda}@microsoft.com Phone: +1 425 882 8080 Fax: +1 425 936 7329 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." EAP Issues Open issues relating to EAP, including the issues described in this document, are tracked on the following web site: http://www.drizzle.com/~aboba/EAP/eapissues.html Expiration Date This memo is filed as , and expires April 24, 2003.