Network P. Barany Internet-Draft R. Rezaiifar Intended status: Experimental L. Dondeti Expires: June 22, 2007 V. Narayanan QUALCOMM, Inc. J. Salowey P. Yegani Cisco Systems December 19, 2006 3GPP2 Generic EAP Encapsulation (GEE) Protocol draft-barany-eap-gee-04 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 June 22, 2007. 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 June 22, 2007 [Page 1] Internet-Draft GEE December 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 EAP conversations between a peer and an authenticator. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture and Overview . . . . . . . . . . . . . . . . . . 5 3.1. Multiple Authenticator Model . . . . . . . . . . . . . . . 8 4. GEE Message Format . . . . . . . . . . . . . . . . . . . . . . 8 4.1. GEE Header Format . . . . . . . . . . . . . . . . . . . . 9 5. Packet Processing Details . . . . . . . . . . . . . . . . . . 10 5.1. Packet Handling at the Peer . . . . . . . . . . . . . . . 10 5.2. Packet Handling at the Authenticator . . . . . . . . . . . 10 5.3. Multiple authentications and access control enforcement . 11 6. GEE Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Recap of use cases and interactions between network entities . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Threats and mitigation strategies . . . . . . . . . . . . 13 7.2.1. Threats that might cause denial of service . . . . . . 14 7.2.2. Threats that might cause theft of service . . . . . . 14 7.3. Implications of multiple EAP authentications . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Barany, et al. Expires June 22, 2007 [Page 2] Internet-Draft GEE December 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) [4] or other link layer protocols, 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 EAP conversations between a peer and an authenticator. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. In the rest of this document, we refer to this protocol as GEE, Version 0 or GEEv0. 1.1. Motivation +--------------+ +--------------+ | ANP | | SNP | | | | | +----+ +-----+ | | | | MN |--- | NAS | | | +-------+ | +----+ +-----+ |===| |AAA-SNP| | | \ | | +-------+ | | \ +-------+ | | | | -|AAA-ANP| | | | | +-------+ | | | +--------------+ +--------------+ 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 Barany, et al. Expires June 22, 2007 [Page 3] Internet-Draft GEE December 2006 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 Layer 3 service (i.e., 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 and authenticator be able to differentiate between 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. Barany, et al. Expires June 22, 2007 [Page 4] Internet-Draft GEE December 2006 Hence, the primary motivation for this document is to provide the functionality for EAP peers and authenticators to differentiate between 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 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. Type 1 Authentication This refers to one authentications that is performed by the peer. For instance, it may be the Layer 1 and Layer 2 authentication that allows the peer to gain link layer access to the attached network. Type 2 Authentication This refers to a second authentication that is performed by the peer. For instance, it may be the Layer 3 authentication that allows the peer to gain access to Layer 3 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. Barany, et al. Expires June 22, 2007 [Page 5] Internet-Draft GEE December 2006 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 conversations may happen sequentially or in parallel. However, in accordance with RFC 3748, an EAP peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, unless the providers are the same and the peer is using the same credentials and EAP method for both types of authentication. 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 Barany, et al. Expires June 22, 2007 [Page 6] Internet-Draft GEE December 2006 the EAP Multiplexing Model Figure 2 shows the protocol stack for GEE in the EAP multiplexing model. 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 [11]). 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. Barany, et al. Expires June 22, 2007 [Page 7] Internet-Draft GEE December 2006 3.1. Multiple Authenticator Model +--------------+ +--------------+ | 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. In 3GPP2 networks, single authenticator and multiple authenticator architectures are both possible. 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 June 22, 2007 [Page 8] Internet-Draft GEE December 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 +-+-+-+-+-+-+-+-+ |Version|TID|RFL| +-+-+-+-+-+-+-+-+ Figure 6: GEE Header Version The first 4 bits in the GEE header represent the protocol version number. This field MUST be set to 0 for GEEv0. Transaction ID (TID) A 2-bit TID flag is used to distinguish between multiple EAP conversations. In Version 0 of GEE (GEEv0), the TID field MUST be either 00 or 01. When TID = 01, the encapsulated EAP packet is for Type 1 authentication. When TID = 00, the encapsulated EAP packet is for Type 2 authentication. In GEEv0, TID values other than 00 and 01 are reserved and MUST NOT be used. Barany, et al. Expires June 22, 2007 [Page 9] Internet-Draft GEE December 2006 Result flags/code (RFL) The last 2 bits in the GEE header are used to indicate the result of the EAP authentication in progress. The leftmost bit in this field is the 'K' bit and indicates whether the MSK resulting from the EAP conversation being encapsulated by the particular GEE session must be bound with an MSK resulting from the second EAP conversation carried in a second GEE session. If set, this implies that the peer MUST bind the MSKs to derive TSKs. The process of MSK binding is described in Section 5.3. In GEEv0, the last bit is the R bit and is reserved and MUST be set to zero at the sender and MUST be ignored by the receiver. 5. Packet Processing Details 5.1. 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 Type 1 or Type 2 authentication. If TID value is 01 in the packet received from the authenticator, the peer must perform the necessary Type 1 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 Type 2 authentication. While Type 1 and Type 2 authentications are not explicitly defined in this document, these must be defined at the peer and authenticator for a given usage of this protocol. When the peer sends a GEEv0 packet in response to a GEEv0 packet received from the authenticator, the TID value MUST be copied from the corresponding packet received from the authenticator. As in the packet from the authenticator, a value of 01 indicates that the EAP packet is for Type 1 authentication and a value of 00 indicates that the encapsulated EAP packet is for Type 2 authentication. The RFL value MUST be set to 00. 5.2. 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 for Type 1 or Type 2 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 Type 1 Barany, et al. Expires June 22, 2007 [Page 10] Internet-Draft GEE December 2006 authentication. The TID value MUST be set to 00 by the authenticator if the encapsulated EAP packet is for Type 2 authentication. The K bit in the RFL field MUST be set if the peer is expected to bind the MSKs prior to using it for generating other keys. The last bit in the RFL field MUST always be set to 0. In order to set the K bit appropriately, it is expected that the authenticator knows about another EAP exchange that the peer may be doing and if the keys must be bound or not. 5.3. Multiple authentications and access control enforcement When both Type 1 and Type 2 authentications are carried out, access control MUST conform to the following cases. Type1 Type2 Combined result Case 1 Success Success Success Case 2 Success Failure Type1 related access only Cases 3&4 Failure S/F Failure Cases 5&6 N/A S/F S/F Access Control Matrix GEE requires that at least one of the authentications to be key generating and both authentications to be mutually authenticating. If one of the authentications is not key generating, then there MUST be a way for the authenticator to identify the two authentication conversations (Type 1 and Type 2) corresponding to a peer. Specifically, there MUST be a mechanism for the authenticator to correlate the Type 1 and Type 2 credentials; typically this is facilitated by backend network protocol support. An example of such backend support is to be able to send an identifier that is unique to the peer across the authentications in an authenticated manner. For instance, when both authenticators reside in the same node, the AAA transactions may return Chargeable-User-Identity (CUI) attributes [12] and the node can compare them for equality. If there is a mismatch, or the node has not received such an identity from both transactions, the peer MUST be disconnected. It must be noted that such non-cryptographic bindings cannot translate to absolute access control based on both authentications, unlike the case of key binding described below. These may be used in the presence of non-key generating methods under tightly controlled administrative environments. If both Type 1 and Type 2 authentications are key generating and Barany, et al. Expires June 22, 2007 [Page 11] Internet-Draft GEE December 2006 occur in parallel, one of the following techniques are used: MSK Binding In this case,even when there are multiple authenticators, we assume that there is only one access control enforcement point. Here, the combined MSK MUST be used to derive session keys (Transient session keys, TSKs). Both authenticators deliver the MSK to the enforcement point and it computes the combined MSK as follows: Combined-MSK = f(MSK-Type 1, "GEE Combined Key" || MSK- Type 2), where f represents prf+ as defined in [3]. The length of the Combined-MSK MUST be 512 bits. With GEEv0, the PRF is HMAC- SHA-256. Single Access Control Enforcement with Protected Result Indication In the event that there can be a protected result indication between authenticators and/or enforcement points with a way to correlate the peer IDs used in the EAP conversations, it is feasible to have the TSK generated from only one MSK. A MiTM attack may be plausible in this case, and hence it is NOT RECOMMENDED. When two EAP authentications are performed, it is always feasible to use keys from a first exchange to protect a subsequent exchange. Note that the two authentications in this case will occur sequentially and the first method must be key generating. The use of GEE does not preclude such an operation, even though the main motivation for GEE is to allow parallel execution of the EAP exchanges. 6. GEE Extensibility GEE could be extended to support dynamic TID assignment, where an authenticator may pick an unused TID value. The peer could participate in as many as 4 EAP conversations in parallel. In order for the peer to be able to understand the meaning of each TID, a new mechanism would be needed to send information about authentication type and other policy hints. Such a mechanism could either operate on the layer that carries GEE, or in an extended version of GEE itself. Note that RFC 4284 defines a mechanism for the authenticator to advertise a set of roaming realms. 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 (e.g., for device and user authentication) for a give realm and for that or other reasons, Barany, et al. Expires June 22, 2007 [Page 12] Internet-Draft GEE December 2006 providing a list of realms alone may not be sufficient. In those cases, the realm information itself is insufficient. Similarly, due to EAP MTU and other considerations, RFC 4284 can carry only a very limited amount of information, and it is not intended for carrying other policy information. As a result, its applicability for this purpose is limited, and other mechanisms are likely to be needed. This document does not propose any such mechanisms at this time. 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 can be removed for future versions. Furthermore, in the result code and flags field the last bit may be set to indicate the presence of TLVs in the GEE header. 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]. 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, Type 1 and Type 2 authentication may take place in tandem (in any order) or in parallel. A further consideration is whether the same network provider is providing Type 1 and Type 2 services (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 Layer 2, 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. Barany, et al. Expires June 22, 2007 [Page 13] Internet-Draft GEE December 2006 Note that if Type 1 (say, access) authentication occurs first and subsequent authentication processes take place via a Layer 2 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 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 Type 1 and Type 2 authentications from all peers, it is plausible for a rogue peer with available credentials for Type 1 authentication to gain access to Type 2 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., Type 2) is more vulnerable to attacks than the EAP method used for another authentication (e.g., Type 1), the authenticator needs to strictly enforce a policy of Type 1 authentication first, and require that the Type 2 authentication occur within the secure channel established as a result of Type 1 authentication. Another possible solution is for the authenticator to maintain an association between the Layer 2 security association and Layer 3 address(es), to prevent rogue peers from stealing other Barany, et al. Expires June 22, 2007 [Page 14] Internet-Draft GEE December 2006 peers' IP services. 7.2.2.1. Possible subversion of authentication policy Suppose a peer has credentials for Type 1 authentication in a visited network and credentials for both Type 1 and Type 2 authentication in the home network. It is plausible that the peer may supply its home network credentials for Type 1 as well as Type 2 authentication and thereby avoid any payments to the visited ANP. To avoid this possibility, the AAA-ANP may send to the authenticators its Type 1 authentication policy by sending a list of realms for which Type 1 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] or other similar procedures. 7.3. Implications of multiple EAP authentications GEE is designed to facilitate the use of multiple parallel EAP authentications and that implies 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 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., Layer 2 and Layer 3 identifier correlation), 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 or using multiple encapsulations using the generated keys. When the multiple authentications are key generating and occur in parallel, GEEv0 requires that the MSKs resulting from each authentication be all used for access control in order to successfully prevent any MiTM attacks. When only one of the Barany, et al. Expires June 22, 2007 [Page 15] Internet-Draft GEE December 2006 authentications is key generating or when the authentications occur sequentially, other administrative policies must be used to ensure that the threat is mitigated. 8. IANA Considerations We request IANA to maintain a GEE registry. The registry will contain the following items: The 4-bit Version field (Version 0 is to be registered for this RFC). Additional values can be allocated via IETF Review [14]. The 2-bit TID field (values 00 and 01 are to be registered for this RFC). Additional values can be allocated via IETF Review, but only in conjunction of defining a new version number. The 2-bit RFL field (the first bit, K, is to be registered for this RFC). Additional values can be allocated via IETF Review. 9. Acknowledgments We thank Parag Agashe, Paul Bender, Raymond Hsu, AC Mahendran, and Jun Wang for their review of earlier versions of this draft and/or for their contributions to the many discussions on this topic. 10. References 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. [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 10.2. Informative References [4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Barany, et al. Expires June 22, 2007 [Page 16] Internet-Draft GEE December 2006 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] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [12] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. [13] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-05 (work in progress), September 2006. Barany, et al. Expires June 22, 2007 [Page 17] Internet-Draft GEE December 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 June 22, 2007 [Page 18] Internet-Draft GEE December 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 June 22, 2007 [Page 19] Internet-Draft GEE December 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Barany, et al. Expires June 22, 2007 [Page 20]