Network P. Barany Internet-Draft R. Rezaiifar Expires: October 23, 2006 L. Dondeti V. Narayanan QUALCOMM, Inc. J. Salowey P. Yegani Cisco Systems April 21, 2006 Generic EAP Encapsulation (GEE), Version 0 draft-barany-eap-gee-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on October 23, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Extensible Authentication Protocol (EAP) is a general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers without requiring Barany, et al. Expires October 23, 2006 [Page 1] Internet-Draft GEE April 2006 IP. EAP can be used for different types of authentication, where multiple providers provide access to different services. However, EAP itself does not have the ability to differentiate between multiple types of authentications. This document specifies a general encapsulation protocol, called Generic EAP Encapsulation (GEE), for differentiating between multiple EAP exchanges executed by a peer. This document specifies GEEv0 and provides a summary of capabilities to be specified in GEEv1. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture and Overview . . . . . . . . . . . . . . . . . . 6 3.1. Multiple Authenticator Model . . . . . . . . . . . . . . . 8 4. GEE Message Format . . . . . . . . . . . . . . . . . . . . . . 9 4.1. GEE Header Format . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Use of the TID field . . . . . . . . . . . . . . . . . 11 4.1.2. Use of the result code and flags field . . . . . . . . 11 4.1.3. GEEv0 Header Format . . . . . . . . . . . . . . . . . 11 5. GEEv0 Packet Processing Details . . . . . . . . . . . . . . . 12 5.1. GEEv0 Packet Handling at the Peer . . . . . . . . . . . . 12 5.2. GEEv0 Packet Handling at the Authenticator . . . . . . . . 12 6. GEEv1 Extensions . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Recap of use cases and interactions between network entities . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Threats and mitigation strategies . . . . . . . . . . . . 14 7.2.1. Threats that might cause denial of service . . . . . . 14 7.2.2. Threats that might cause theft of service . . . . . . 15 7.3. Implications of multiple EAP authentications . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Barany, et al. Expires October 23, 2006 [Page 2] Internet-Draft GEE April 2006 1. Introduction The Extensible Authentication Protocol (EAP) [1] is a widely deployed general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers such as the Point-to-Point Protocol (PPP) [3] or IEEE 802 [4], without requiring IP. EAP was originally developed as a general authentication protocol for use with the PPP protocol [5]. It is now also used by IEEE 802 wired media as described in [6] and IEEE wireless LANs as described in [7]. As cdma2000 third generation cellular networks evolve [8], [9], EAP will also be used as a general authentication protocol that runs directly over the data link layer [10]. EAP can be used for different types of authentication, where multiple providers provide access to different services. However, EAP itself does not have the ability to differentiate between multiple types of authentications. This document specifies a general encapsulation protocol, called Generic EAP Encapsulation (GEE), for differentiating between multiple EAP exchanges executed by a peer. This document specifies GEEv0, and GEEv1 will be part of a future IETF specification. While certain additional functionality that needs to be supported in GEE has been identified beyond version 0, in order to allow phased deployment, the two versions are specified separately. Specifically, some restrictions imposed on the use of certain fields in GEEv0 will be relaxed in GEEv1 to support additional functionality. 1.1. Motivation +--------------+ +--------------+ | ANP | | SNP | | | | | +----+ +-----+ | | | | MN |--- | NAS | | | +-------+ | +----+ +-----+ |===| |AAA-SNP| | | \ | | +-------+ | | \ +-------+ | | | | -|AAA-ANP| | | | | +-------+ | | | +--------------+ +--------------+ Barany, et al. Expires October 23, 2006 [Page 3] Internet-Draft GEE April 2006 Figure 1: Model with separate ANP and SNP The network provider model has evolved to a point where it is not uncommon to have multiple network providers that offer various services. For instance, the access network provider (ANP) is often different from a service network provider (SNP) as noted above. It is possible that a peer needs to perform authentication separately with the two network providers. Regardless of whether the access and service network providers are the same or not, separate access and service authentication may be required. Also, for EAP-based authentication, the two EAP methods may or may not be the same. Figure 1 shows an example of the case where the access network provider is different from the service network provider. The ANP hosts the Authenticator (NAS or Network Access Server in the figure) and an Authentication Server (AAA-ANP in the figure). The SNP may have its own Authentication Server (AAA-SNP in the figure). A good example of the case where access and service authentications are performed separately is the case of Mobile Virtual Network Operators (MVNO). In this case, the network provider providing Layer1 and Layer2 access is typically different from that providing IP level service. Hence, separate access and service authentications are usually required to gain access to the respective networks and services. In cases where access and service authentications are performed separately, it may be desirable to do these in parallel, to avoid added latency resulting from a sequential execution of the two authentications. When a peer is performing multiple EAP authentications, it is not possible to clearly differentiate between the two types of authentications using available means. Also, the authenticator will need to distinguish the multiple EAP exchanges in order to route the packets to the correct EAP server. Typically, the Identifier value in an EAP Response packet will be the same as that in the matching Request - however, the authenticator, while operating in pass-through mode, does not keep track of the value of the Identifier field. Even if the authenticator could match up the values of the Identifier field, the two EAP servers performing the access and service authentication may generate the same Identifier (since the Identifier is a randomly chosen 8-bit field in the EAP Request/Response packets). Hence, there is no available means to allow multiple EAP authentications for a given peer to occur in parallel. While EAP methods are TLV-based and can easily be extended to carry additional information between the peer and the server, EAP itself does not provide a means to carry any additional information between the peer and the authenticator. It is important that the EAP peer Barany, et al. Expires October 23, 2006 [Page 4] Internet-Draft GEE April 2006 and authenticator be able to differentiate the access and service authentication exchanges for multiple reasons. For example, it allows proper routing of the messages to the appropriate EAP server and allows the two exchanges to happen in parallel. It may be worthwhile to note that the Protocol for Carrying Authentication for Network Access (PANA) [11] provides a means of differentiating access and service authentication as part of the PANA header exchanged between the PaC (usually the EAP peer) and the PAA (usually the EAP authenticator). However, this is only useful for use on networks that run PANA. Other networks that use EAP-based authentication, such as IEEE 802.11, or that will use EAP-based authentication, such as cdma2000 third generation cellular networks, cannot make use of this feature that is specific to PANA. Furthermore, PANA requires a sequential execution of these two authentications and hence, does not provide the parallel execution advantage. Hence, the motivation for this document is to provide the functionality for EAP peers and authenticators to differentiate multiple EAP exchanges that a peer may be executing in parallel to gain access to different networks or services. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC- 2119 [2]. This document uses terminology already defined in [1]. In addition, this document uses the following terms: Access Network Provider (ANP) A service provider that provides physical and link-layer connectivity (i.e., Layer1 and Layer2 connectivity) to an access network that it manages. Service Network Provider (SNP) A service provider that provides network layer connectivity (i.e., Layer3 connectivity) to a service network that it manages. Access Authentication This refers to the L2 authentication that allows the peer to gain link layer access to the attached network. Barany, et al. Expires October 23, 2006 [Page 5] Internet-Draft GEE April 2006 Service Authentication This refers to the L3 authentication that allows the peer to gain access to L3 services. 3. Architecture and Overview GEE does not define any new architectural elements other than those already defined by EAP. The protocol functionality described in this document applies to the EAP peer and authenticator only. The protocol has no impact and does not depend on the EAP method used by the peer and the server. In accordance with the EAP specification [1], an EAP authenticator may either terminate the EAP session or may act in pass-through mode, where the EAP session is terminated by a backend authentication server, also known as an EAP server. This protocol applies to both modes of operation, unless specifically pointed out. The proposed protocol operation remains mostly the same in the EAP Multiplexing Model as well as the EAP Pass-Through Model. At a high level, this protocol allows the peer and authenticator to perform multiple EAP authentications independently and potentially with different authentication servers in different provider networks. The multiple EAP instances may happen sequentially or in parallel. However, in accordance with this specification, multiple authentications MUST NOT be handled by the same EAP exchange, unless the providers are the same and the peer is using the same credentials and EAP method for both types of authentication. In other words, the peer MUST NOT include multiple identities or use multiple EAP methods within the same EAP conversation. This is no different than the case of EAP exchange without GEE, where the peer gains access to the Layer1 and Layer2 connectivity as well as Layer3 connectivity as a result of one EAP exchange. Barany, et al. Expires October 23, 2006 [Page 6] Internet-Draft GEE April 2006 Peer Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | GEE ! layer | | GEE ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! ! +------------>-------------+ Figure 2: GEE Protocol stack and Peer to Authenticator interaction in the EAP Multiplexing Model Figure 2 shows the protocol stack for GEE in the EAP multiplexing model. Barany, et al. Expires October 23, 2006 [Page 7] Internet-Draft GEE April 2006 Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| ! | | ! | | ! | | ! | EAP ! layer | | EAP !layer| +-+-+-!-+-+-+ +-+-+-+-!-+-+-| ! | | ! | |GEE !layer| | GEE !layer| ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->--------+ +--------->-------+ Figure 3: GEE Pass-Through Processing and Forwarding Model When the authenticator operates in pass-through mode, the GEE layer terminates at the authenticator and the EAP packet is sent over a backend AAA layer (e.g., RADIUS [12]). In this case, the authenticator must handle the GEE fields in exactly the same manner as in the multiplexing model. The fields in the GEE header may be used by the authenticator to identify the correct EAP exchange to properly route the EAP packet. A Transaction ID (TID) field defined in the protocol allows the EAP exchanges to be distinguished. The TID field is used to look up the appropriate domain to which a particular EAP message must be routed. 3.1. Multiple Authenticator Model Barany, et al. Expires October 23, 2006 [Page 8] Internet-Draft GEE April 2006 +--------------+ +--------------+ | ANP | | SNP | | | | | +----+ +-----+ | +-----+ | | MN |--- |NAS 1| |===|NAS 2| | +----+ +-----+ | +-----+ | | \ | | \ | | \ +-------+ | | \ +-------+ | | -|AAA-ANP| | | -|AAA-SNP| | | +-------+ | | +-------+ | +--------------+ +--------------+ Figure 4: Multiple Authenticator Model Depending on the architecture, the authenticator that is responsible for each authentication may be different. This could be true irrespective of whether the EAP server is the same or different for each authentication. However, in most practical cases, the need for multiple authentications arises only when the EAP servers performing the different types of authentications are different. Figure 4 shows the architecture with each provider having a different authenticator that is engaged in different EAP exchanges that the peer performs. Since GEE runs between the peer and the authenticator, it brings a slight variance when the authenticator for each EAP exchange is different. Since the multiple EAP authentications are over the same link, the EAP exchange between the peer and one of the authenticators may have to pass through another authenticator or enforcement point. Hence, the lower layers at each hop in this case must be able to indicate the presence of the GEE header. 4. GEE Message Format A GEE encapsulated packet has the following format. Barany, et al. Expires October 23, 2006 [Page 9] Internet-Draft GEE April 2006 --------------------------------- | | | Data link layer header | | | --------------------------------- | | | GEE header | | | --------------------------------- | | | EAP packet | | | --------------------------------- Figure 5: GEE Encapsulated Packet 4.1. GEE Header Format The GEE Header has the following format. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|TID| Result flags/code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: GEE Header Version The first 4 bits in the GEE header represent the protocol version number. Transaction ID (TID) A 2-bit TID flag is used to distinguish multiple EAP conversations from each other. This field allows the peer to participate in as many as 4 EAP conversations in parallel. Result flags/code The last 10 bits in the GEE header are used to indicate the result of EAP authentication in process. Future versions of GEE, specifically GEEv1, may specify other values. Barany, et al. Expires October 23, 2006 [Page 10] Internet-Draft GEE April 2006 4.1.1. Use of the TID field The TID is a generic mechanism to distinguish multiple parallel EAP authentications between an authenticator and a peer. TID values may be assigned to EAP authentications using a static assignment policy or dynamic assignment. In static TID assignment, as in case of GEEv0 (described below), TID values are assigned to types of EAP authentications with associated processing and result code interpretation rules. The authenticator may provide hints about an acceptable list of realms for a given TID, as specified in RFC4284 [13]. GEEv1 will support dynamic TID assignment, where, an authenticator may pick an unused TID value and send information about authentication type and other policy hints as part of the EAP identity request message. The hints may be a list of acceptable realms as specified in RFC4284 [13], as in the static TID assignment case. With this information alone, the peer needs to readily understand the nature of authentication based on the realm information. However, in some cases, a peer may have multiple credentials for a give realm and for that or other reasons, providing a list of realms alone may not be sufficient. In those cases, each realm or the list of realms may need to be associated with additional information such as the type of authentication required by the EAP identity request sent by the authenticator. Specifically due to the introduction of additional capability to use the identity hints and indicating the type of authentication via extensible options (TLVs), the restriction imposed in GEEv0 for the semantics of the TID field have been lifted for GEEv1. This makes GEEv1 more generic for future deployments that are expected to have support for RFC4284 [13] as well as the additional TLVs defined in this document. 4.1.2. Use of the result code and flags field The GEE header has 10 bits allocated for the authenticator to communicate information about the EAP authentication processes underway to the peer. No flags are currently defined for GEEv0. In GEEv1, the setting of the last bit is an indication of the presence of TLVs in the GEE header. 4.1.3. GEEv0 Header Format For Version 0, the GEE header is as follows: Barany, et al. Expires October 23, 2006 [Page 11] Internet-Draft GEE April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|0|x|0|0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: GEEv0 Header Version This field MUST be set to 0 for GEEv0. TID semantics for GEE, Version 0 In Version 0 of GEE (GEEv0), the TID field MUST be either 00 or 01. This maps to a 1-bit "Access type" flag. When TID = 01, the encapsulated EAP packet is for access authentication. When TID = 00, the encapsulated EAP packet is for service authentication. In GEEv0, TID values other than 00 and 01 MUST NOT be used. Result flags/code In GEEv0, all of these 10 bits are reserved and MUST be set to zero at the sender and MUST be ignored by the receiver. 5. GEEv0 Packet Processing Details 5.1. GEEv0 Packet Handling at the Peer When the peer receives a GEEv0 packet, the TID field in the GEEv0 header MUST be used to determine if the encapsulated EAP packet is for access or service authentication. If TID value is 01 in the packet received from the authenticator, the peer must perform the necessary access authentication. For instance, this may mean that the peer provides the appropriate identity and use the appropriate EAP method in the EAP session. When the TID is set to 00 in the packet received from the authenticator, the peer must perform the necessary service authentication. When the peer sends a GEEv0 packet, the TID value MUST be 01 if the encapsulated EAP packet is for access authentication. The TID value MUST be set to 00 by the peer if the encapsulated EAP packet is for service authentication. 5.2. GEEv0 Packet Handling at the Authenticator When the authenticator receives a GEEv0 packet, the TID value in the header MUST be used to determine if the encapsulated EAP packet is Barany, et al. Expires October 23, 2006 [Page 12] Internet-Draft GEE April 2006 for access or service authentication. When the authenticator sends a GEEv0 packet, the TID value in the header MUST be set to 01 if the encapsulated EAP packet is for access authentication. The TID value MUST be set to 00 by the authenticator if the encapsulated EAP packet is for service authentication. 6. GEEv1 Extensions In GEEv1, the authenticator may pick a unique TID value to use with a particular EAP exchange with a peer. However, in this case, the TID value does not give the peer any clues on the type of authentication. When the peer possesses credentials with different realms, it would have no means of determining which credential to use in a particular EAP exchange. For this purpose, the authenticator SHOULD use RFC4284-style identity hints to the peer, while using GEEv1. This implies that the authenticator, along with the EAP request identity packet, sends out a list of realms that it supports for that exchange. The peer may then pick the appropriate credentials. This may imply that the authenticator selectively sends only those realms that make sense for a particular type of authentication. However, a peer may have multiple sets of credentials for different types of authentication (e.g, user and device) with the same realm. In such a case, an extension is required to RFC4284 to include the type of authentication that the network requests the peer to perform for a particular realm. This document does not propose any such extensions at this time. Future documents may provide such extensions to RFC4284. In addition, GEEv1 would define appropriate TLVs for carrying additional information between the peer and the authenticator. A bit in the GEE header will indicate the presence of TLVs. 7. Security Considerations In this section, we recap the use cases of GEE and possible interactions between various network entities using GEE, discuss potential vulnerabilities that an adversary might exploit and finally describe mechanisms and best practices on how to mitigate the threats. We note that the vulnerabilities discussed here in are in addition to those considered in EAP [1] and are somewhat similar to those that Barany, et al. Expires October 23, 2006 [Page 13] Internet-Draft GEE April 2006 apply to the PANA protocol suite (RFC 4016 [14] and other PANA drafts [11]). 7.1. Recap of use cases and interactions between network entities GEE encapsulates EAP so an authenticator can signal to the peer about the type of authentication the EAP request is meant for. GEE also facilitates parallel execution of such authentications. For instance, Access and service authentication may take place in tandem (in any order) or in parallel. A further consideration is whether the same network provider is providing access and service (different credentials and same AAA server), or different network providers, i.e., different AAA servers are involved. 7.2. Threats and mitigation strategies The GEE header is not cryptographically protected. Thus it is plausible for an eavesdropper to use L2, GEE and EAP headers and collate information on how certain devices are authenticating themselves to their network providers: the order and combination of the different types of authentication are easily available in those headers. Note that if access authentication occurs first and subsequent authentication processes take place via an L2 encrypted channel, information about the rest of the authentications will not be available to passive observers on the path from the peer to the authenticator. In addition to the passive attacks, an adversary may launch mainly two types of active attacks on GEE: in the first, the adversary may attempt to disrupt or deny service for other entities whereas in the second, the adversary may attempt to gain network access or IP services impersonating other entities. 7.2.1. Threats that might cause denial of service An adversary may change any of the contents of the GEE payload, the version field and/or the TID field, to cause either the peer or the authenticator to drop GEE encapsulated EAP packets. Suppose an attacker consistently changes the value of the TID field, the AAA server may conclude that the peer's credentials may have been compromised and may revoke access so as to trigger an offline process for updating that peer's credentials. As a result the peer may lose connectivity temporarily. Note however that DoS attacks identical or similar to this are also possible on EAP conversations without GEE Barany, et al. Expires October 23, 2006 [Page 14] Internet-Draft GEE April 2006 encapsulation. 7.2.2. Threats that might cause theft of service If the EAP method used for one authentication is known to be weaker than the EAP method used for another authentication, whereas the authenticator may intend to enforce one authentication before the other, an attacker may modify the GEE flags to cause the peer to start the weaker authentication without the protection of stronger authentication. The adversary may then be able to break the weaker authentication method and gain access to services. Even if the authenticator requires, say, both access and service authentications from all peers, it is plausible for a rogue peer with available credentials for access authentication to gain access to IP services for which it does not have proper credentials. To mitigate this threat, i.e., when the EAP method used for one authentication (e.g., service) is more vulnerable to attacks than the EAP method used for another authentication (e.g., access), the authenticator needs to strictly enforce a policy of access authentication first, and require that the service authentication occur within the secure channel established as a result of access authentication. Another possible solution is for the authenticator to maintain an association between the L2 security association and L3 address(es), to prevent rogue peers from stealing other peers' IP services. 7.2.2.1. Possible subversion of access authentication policy Suppose a peer has credentials for access authentication in a visited network and credentials for access and service authentication in the home network. It is plausible that the peer may supply its home network credentials for access as well as service authentication and thereby avoid any payments to the visited ANP. To avoid this possibility, the AAA-ANP may send to the authenticators its access authentication policy by sending a list of realms for which access authentication request is allowed to be forwarded to home network. The authenticator may share that information with the peer in the EAP identity request following the semantics in RFC 4284 [13], similar procedures, or extensions thereof. 7.3. Implications of multiple EAP authentications GEE is designed to facilitate the use of multiple parallel EAP authentications. As discussed in the PANA specification [11], multiple EAP authentications impose certain requirements on the EAP methods used. First, it is clear that at least one of the methods must be key generating and all the methods must be mutually Barany, et al. Expires October 23, 2006 [Page 15] Internet-Draft GEE April 2006 authenticating. The key generation requirement is to authenticate the data packets as coming from the peer that participated in the authentication whereas the mutual authentication requirement is self- explanatory. There is however still the possibility of a man-in-the-middle (MiTM) attack between EAP authentications. Briefly, since the authenticator does not have enough information to associate NAIs corresponding to multiple authentications, it is plausible for an adversary to skip one or more of the EAP authentications and instead claim the authentication exchange of a legitimate peer as its own. The authenticator would have no way of verifying the claim. There are several possible mitigation strategies including the use of identifier binding between authentications (e.g., L2 and L3 identifier binding), NAI binding between authentications, or in case of sequential authentications, the use of key material from the first authentication to encrypt future authentications. Other solutions require all authentications to be key generating and binding all the keys to generate the master key used to bootstrap the traffic key generation process. 8. IANA Considerations We request IANA to maintain a GEE registry to which new values are added after IESG review. The registry will contain an 4-bit Version field (Version 0 is to be registered for this RFC), and the use of the bits in the reserved field is to be specified in an RFC. TID values 00 and 01 are used by GEEv0. Future versions of GEE may specify the use of other possible TID values. All bits in the result code are reserved and may be specified in a future RFC. GEEv0 is frozen as per this specification. All extensions of the TID field and the result code field are to be registered with a new version of GEE. 9. Acknowledgments We thank Jun Wang, Raymond Hsu, Parag, Agashe, and AC Mahendran for their review of earlier versions of this draft and/or for their contributions to the many discussions on this topic. 10. References Barany, et al. Expires October 23, 2006 [Page 16] Internet-Draft GEE April 2006 10.1. Normative References [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [4] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture, IEEE Standard 802", 1990. [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [6] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", Dec 2004. [7] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security, IEEE 802.11i", July 2004. [8] 3GPP2, "3GPP2 X.S0011-002-D v1.0, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", (to be published).". [9] 3GPP2, "3GPP2 A.S0008-B v1.0, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces", (to be published).". [10] 3GPP2, "3GPP2 C.S0063-0 v2.0, "cdma2000 High Rate Packet Data Supplemental Services", (to be published).". [11] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-11 (work in progress), March 2006. Barany, et al. Expires October 23, 2006 [Page 17] Internet-Draft GEE April 2006 [12] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [13] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. [14] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005. [15] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [16] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [17] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [18] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [19] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [20] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [21] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [22] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. [23] Perkins, C., "Mobile IPv4 Challenge/Response Extensions (revised)", draft-ietf-mip4-rfc3012bis-05 (work in progress), February 2006. [24] Tschofenig, H. and P. Eronen, "Extension for EAP Authentication in IKEv2", draft-eronen-ipsec-ikev2-eap-auth-04 (work in progress), October 2005. Barany, et al. Expires October 23, 2006 [Page 18] Internet-Draft GEE April 2006 Authors' Addresses Peter Barany QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-658-2341 Email: pbarany@qualcomm.com Ramin Rezaiifar QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-651-2067 Email: rrezaiifar@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Barany, et al. Expires October 23, 2006 [Page 19] Internet-Draft GEE April 2006 Joeseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA USA Phone: +1 206-256-3380 Email: jsalowey@cisco.com Parviz Yegani Cisco Systems 3625 Cisco Way San Jose, CA USA Phone: +1 408-832-5729 Email: pyegani@cisco.com Barany, et al. Expires October 23, 2006 [Page 20] Internet-Draft GEE April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barany, et al. Expires October 23, 2006 [Page 21]