EAP Working Group Jose Puthenkulam INTERNET-DRAFT Victor Lortz Category: Informational Intel Corporation <draft-puthenkulam-eap-binding-01.txt> 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 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 28 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 ................................... 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 Puthenkulam et al. Informational [Page 2]
INTERNET-DRAFT Compound Binding Problem 28 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 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. 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 28 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 proposed IETF protocols, including [XAUTH],[PIC],[PANATLS], [EAPTTLS], and [PEAP]. 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. Puthenkulam et al. Informational [Page 4]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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. 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 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]. 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. 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. 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] Puthenkulam et al. Informational [Page 5]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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. 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 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. 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, Puthenkulam et al. Informational [Page 6]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 permitting only a restricted set of users to authenticate within a tunnel established with given machine credentials. 3. Attack scenarios 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. 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. Puthenkulam et al. Informational [Page 7]
INTERNET-DRAFT Compound Binding Problem 28 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 a one-way authenticated tunnel Puthenkulam et al. Informational [Page 8]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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 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 Puthenkulam et al. Informational [Page 9]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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 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. Puthenkulam et al. Informational [Page 10]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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. Puthenkulam et al. Informational [Page 11]
INTERNET-DRAFT Compound Binding Problem 28 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 compound keys Puthenkulam et al. Informational [Page 12]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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 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. 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 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 each approach, we recommend a solution that applies to all EAP methods. Puthenkulam et al. Informational [Page 13]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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. [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. Puthenkulam et al. Informational [Page 14]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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]. 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 Puthenkulam et al. Informational [Page 15]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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 Puthenkulam et al. Informational [Page 16]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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. Puthenkulam et al. Informational [Page 17]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 [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. 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 Puthenkulam et al. Informational [Page 18]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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." Puthenkulam et al. Informational [Page 19]
INTERNET-DRAFT Compound Binding Problem 28 October 2002 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-01.txt>, and expires April 24, 2003. Puthenkulam et al. Informational [Page 20]