EAP Working Group Jose Puthenkulam INTERNET-DRAFT Victor Lortz Category: Informational Intel Corporation <draft-puthenkulam-eap-binding-00.txt> Ashwin Palekar 27 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 IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS, and PEAP. This document reviews potential solutions to the problem, including solutions which can be implemented as extensions to the EAP protocol. Puthenkulam et al. Informational [Page 1]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 ................................... 8 4.1 Solution requirements ........................... 10 4.2 Solution mechanisms ............................. 11 4.3 Solution approaches ............................. 13 4.4 Solution scope .................................. 14 5. Normative references .................................. 16 6. Informative references ................................ 17 ACKNOWLEDGMENTS .............................................. 19 AUTHORS' ADDRESSES ........................................... 19 Full Copyright Statement ..................................... 20 Puthenkulam et al. Informational [Page 2]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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. 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 possible to launch another 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 access to 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. Given the wide scope of this vulnerability, a solution is desirable, and this document describes the benefits and limitations of potential solution approaches. 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 Puthenkulam et al. Informational [Page 3]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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. 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. Tunneled Methods The first method sets up a tunnel and subsequent method(s) run within the tunnel. 2. Overview The attacks described in this document can be mounted against a number of protocols currently proposed for authenticated network access, including [XAUTH],[PIC],[PANATLS], [EAPTTLS], and [PEAP]. 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, so that the client does not prove its identity to the server, and where authentication techniques are Puthenkulam et al. Informational [Page 4]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 permitted both inside and outside a tunnel. In order to enable secure access using legacy authentiation methods, protocols such as XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP first create a security association, using well analyzed techniques such as ISAKMP [RFC2408] and TLS [RFC2246]. They then tunnel authentication methods within the security association. The intent is to utilize dual authentication techniques so as to provide mutual authentication, as well as to allow the derivation of keys used to provide subsequent per- packet authentication and encryption. However, because 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 computations, there is no demonstration that the ISAKMP/TLS 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]. Thus it is the lack of client authentication within the initial security association, along with a dependency of key derivation solely on the initial one-way authentication, the deployment of untunneled authentication methods, and the lack of "cryptographic binding" between the security association and the tunneled authentication method, that enables the vulnerability. Note that in addition to these vulnerabilities, authentication tunneling also provides a number of security benefits, including well understood key derivation, replay and dictionary attack protection and privacy support. These benefits explain why tunneling has been so frequently proposed for legacy authentication methods with known security vulnerabilities. For the purposes of the attack, it makes no difference whether the authentication technique used inside the tunnel provides for mutual authentication or not. As long as the tunneled authentication method does not require that both sides 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, the vulnerability exists. 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. Despite the prevalence of man-in-the-middle vulnerabilities within IETF protocol proposals, it should be noted that these attacks are not the Puthenkulam et al. Informational [Page 5]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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, and vice versa. 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 members of the group individually. Since CHAP is a widely used authentication method, an attacker can gain access to a client willing to engage in CHAP authentication in a variety of ways. 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. 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. The concept of 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, and permits a PPP dialin user to access a VPN by tunneling PPP packets from the network access server (NAS) to the VPN server. Puthenkulam et al. Informational [Page 6]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 This section describes a how man-in-the-middle vulnerabilities can be exploited, as well as discussing the underlying causes of the attacks. Given the man possible attack variations, we do not attempt to describe every potential variant. The major scenario for the attack is a one-way authenticated tunnel. In this scenario, the client and server first establish a tunnel, then include within the tunnel an authentication method which derives keys and provides strong mutual authentication. The attacker first poses as a valid client to the server and establishes a tunnel that is authenticated only on the server end. Although the attacker that sets up the tunnel has not been authenticated, it obtains the tunnel key derived as part of the tunnel establishment. 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 unique mutual authentication of the tunnel endpoints. 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, the important characteristic is that the protocol used by the client enables an authentication method which is also permitted within the tunneling mechanism, without first requiring that the attacker authenticate itself. For example, an attacker setting up a rogue L2TP over IPsec [RFC3193] server would not be successful since clients would first require mutual authentication within IKE prior to connecting to the rogue server. Puthenkulam et al. Informational [Page 7]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 It is also necessary that the credentials used for the client protocol and the tunneled authentication protocol are the same. Without this, it would not be possible for the authentication conversation between the client and server to conclude successfully. 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 using protocols such as ISAKMP [RFC2408], IKE [RFC2409] or TLS [RFC2246]. Since the tunnel is between the attacker and the authentication server, both the authentication server and attacker possess the keys. In the third step, the client connects to the rogue NAS or AP, and the attacker tunnels the authentication method between the client and authentication server. The 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 authentication server. Since the attacker does not obtain the method keys, it is not able to decrypt traffic sent between client and authentication server. However, while the client may use the method keys, the authentication server will typically use only tunnel keys, which have been obtained by the attacker. In the last step, this allows the attacker to obtain access to the network, using the successfully tunneled authentication and the tunnel keys. The attacker does not have access to the client data, since it is encrypted with the method keys, so that it will typically discard the data sent by the client, who will eventually disconnect due to a lack of response. However, the attacker has accomplished its mission so that 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 described within this document. This includes a description of solution requirements as well as identification of potential solution approaches. Puthenkulam et al. Informational [Page 8]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 one-way authenticated tunnel Puthenkulam et al. Informational [Page 9]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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, or Generic Token Card. As described earlier, these methods are vulnerable to connection hijacking attacks, and are therefore inherently insecure. 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 [XAUTH],[PIC], [PANATLS], [EAPTTLS], or [PEAP], it is preferable that a single solution be applicable to all of these protocols. This is desirable both because such a solution will require the least effort deploy, as well as to enable the security community to focus on a single proposed solution so as to be able to determine that it is secure. Puthenkulam et al. Informational [Page 10]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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, by adding 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 in order to authenticate and encrypt data. [2] Compound keys. this solution combines keying material from all the methods in order to derive the keys used for encrypting and authenticating 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. 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, so that a man-in-the-middle will not be 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 applied, potential man-in-the-middle attacks are thwarted, as shown in Figure 2 on the next page. Puthenkulam et al. Informational [Page 11]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 keys Puthenkulam et al. Informational [Page 12]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 an acknowledged result indication sent from server to client. Since the server is not aware of the man-in-the-middle attack in progress, it indicates that from its perspective the authentication has been successful. However, since the client did not participate in establishment of the tunnel, it does not possess the tunnel keys, and will not be able to verify the compound MAC sent by the server. As a result, it will compute its own compound key and compound MAC which will include a result indicating authentication failure. On receiving the client's reply, the server will be unable to verify the client's compound MAC, and the authentication will fail. As a result, no compound keys are sent to the NAS, and the attacker is neither authenticated nor gains access to the network. 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. In this approach, the tunneling key material is provided to the EAP layer in order to enable computation of a 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. Since this approach applies to any tunneling technique it is the most general approach. 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 Puthenkulam et al. Informational [Page 13]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 security community to individually review changes to each 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 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. Based on the pros and cons of the above techniques, we recommend a solution that applies to all EAP methods. Since EAP is supported within [PIC], [PANATLS], [EAPTTLS] and [PEAP], though not within [XAUTH], this approach covers most of the vulnerable protocols, though not all of them. Assuming that changes to individual EAP methods are not permitted, this approach is only applicable to tunneling of authentication methods that support mutual authentication and derive keys. It is therefore not applicable to CHAP, EAP-MD5, EAP-OTP, EAP-GTC or EAP-SECURID authentication methods. Without requiring changes to established 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. 4.4. Solution scope While options 1 and 2 address many of the attack scenarios, they do not cope with all of them. If every authentication method within a sequence generates keys, then a compound MAC can be used to verify that each endpoint participated in each of the authentication methods within the compound authentication. There are some exceptions: [1] Anonymous or one-way authentication methods. Some authentication methods use anonymous or one-way authentication. In this case, as long as a combination of authentication methods support mutual authentication, the combined keys could be used to verify both peers. Puthenkulam et al. Informational [Page 14]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 [2] Methods that do not generate keys. If one or more authentication method(s) that do not generate keys are allowed to run with and without tunneling, then a man-in-the-middle attack is enabled. [3] Lack of data integrity/encryption. Where per-packet authentication, integrity and encryption is not used, there is no binding between the results of the authentication and subsequent data traffic. This enables connection hijacking. In order to verify that the peers acted as end-points in a compound authentication, the peers can exchange compound MACs. 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 a compound MAC or providing authentication and/or encryption of a subsequent data stream via a compound key. As a result, without modifications these methods cannot be bound to the underlying tunnel authentiation and also do not provide a binding between the one-way authentication and subsequent data authentication, thereby creating a connection hijacking vulnerability. In order to enable a solution for these methods, existing one-way authentication methods 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. 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, and Generic Token Card. 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]. 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 Puthenkulam et al. Informational [Page 15]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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. Puthenkulam et al. Informational [Page 16]
INTERNET-DRAFT Compound Binding Problem 27 October 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. Puthenkulam et al. Informational [Page 17]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 [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 Puthenkulam et al. Informational [Page 18]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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. Acknowledgments Thanks to Bernard Aboba for editorial assistance and discussions relevant to this problem space. 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 Puthenkulam et al. Informational [Page 19]
INTERNET-DRAFT Compound Binding Problem 27 October 2002 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 <draft-puthenkulam-eap-binding-00.txt>, and expires April 24, 2003. Puthenkulam et al. Informational [Page 20]