Network P. Barany Internet-Draft R. Rezaiifar Intended status: Informational L. Dondeti Expires: August 5, 2007 V. Narayanan QUALCOMM, Inc. J. Salowey P. Yegani Cisco Systems February 2007 3GPP2 Generic EAP Encapsulation (GEE) Protocol draft-barany-eap-gee-05 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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 August 5, 2007 [Page 1] Internet-Draft GEE February 2007 IP. EAP can be used for different types of authentication, where multiple providers provide 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 . . . . . . . . . . . . . . . 6 4. Expected Lower Layer Behavior for GEE . . . . . . . . . . . . 7 5. GEE Message Format . . . . . . . . . . . . . . . . . . . . . . 7 5.1. GEE Header Format . . . . . . . . . . . . . . . . . . . . 8 6. Packet Processing Details . . . . . . . . . . . . . . . . . . 9 6.1. Packet Handling at the Peer . . . . . . . . . . . . . . . 9 6.2. Packet Handling at the Authenticator . . . . . . . . . . . 9 6.3. Multiple authentications and access control enforcement . 10 7. GEE Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Recap of use cases and interactions between network entities . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Threats and mitigation strategies . . . . . . . . . . . . 12 8.2.1. Threats that might cause denial of service . . . . . . 13 8.2.2. Threats that might cause theft of service . . . . . . 13 8.3. Implications of multiple EAP authentications . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Barany, et al. Expires August 5, 2007 [Page 2] Internet-Draft GEE February 2007 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 different services. However, EAP itself does not have the ability to differentiate between multiple EAP conversations between a peer and an authenticator. Typically, the lower layer is responsible for differentiating multiple EAP conversations and thid document provides one such mechanism. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. Note that this protocol is "generic" within the specific context of 3gpp2. In other words, this mechanism may be used by multiple lower layers within 3gpp2. 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| | | | | +-------+ | | | +--------------+ +--------------+ Barany, et al. Expires August 5, 2007 [Page 3] Internet-Draft GEE February 2007 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 authentications 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). Note that the Authenticator for the SNP may be the same as that in the ANP. In lower layers that support simultaneous attachment to multiple access points, the Authenticator for each network may be different. A good example where separate authentications are needed 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 authentications are usually required. In cases where multiple authentications are performed, it may be desirable to do them 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 always 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 authentications may generate the same Identifier (since the Identifier is a randomly chosen 8-bit field in the EAP Request/Response packets to unambiguously match up requests with responses). Hence, there is no available means that can be used by any lower layer to allow multiple EAP authentications for a given peer to occur in parallel. While some 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 Barany, et al. Expires August 5, 2007 [Page 4] Internet-Draft GEE February 2007 between the peer and the authenticator. Hence, the primary motivation for this document is to provide, in the context of 3gpp2, the functionality for EAP peers and authenticators to differentiate between multiple EAP exchanges that a peer may be executing in parallel. 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 Layer3 connectivity to a network it manages. Type 1 Authentication This refers to one authentication that is performed by the peer. Type 2 Authentication This refers to another authentication that is performed by the peer, that is different from Type 1 authentication. 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 Barany, et al. Expires August 5, 2007 [Page 5] Internet-Draft GEE February 2007 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 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. When the authenticator operates in pass-through mode, the GEE-enabled lower 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. 3.1. Multiple Authenticator Model +--------------+ +--------------+ | ANP | | SNP | | | | | +----+ +-----+ | +-----+ | | MN |--- |NAS 1| |===|NAS 2| | +----+ +-----+ | +-----+ | | \ | | \ | | \ +-------+ | | \ +-------+ | | -|AAA-ANP| | | -|AAA-SNP| | | +-------+ | | +-------+ | +--------------+ +--------------+ Figure 2: 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 Barany, et al. Expires August 5, 2007 [Page 6] Internet-Draft GEE February 2007 the different types of authentications are different. Figure 2 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. When 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 must be able to indicate the presence of the GEE header. 4. Expected Lower Layer Behavior for GEE The peer and the authenticator must have a mechanism to agree on the use of GEE as an encapsulation for EAP. Such a mechanism may be achieved via lower layer negotiation. Alternately, the peer may be pre-configured to know which networks require the use of GEE. Further, there is no requirements placed on the EAP layer due to GEE. The lower layer is fully expected to hide the presence of GEE from the EAP layer. GEE is not a lower layer for EAP. Hence, this implies that the processing of GEE happens fully within the lower layer and the interface between the lower layer and EAP is unimpacted by the presence of GEE. When the authenticator sends an EAP packet to the peer, the lower layer of the authenticator appends a GEE header to the EAP packet created by the EAP layer before sending it to the peer. Upon reception of the packet, the lower layer of the peer needs to process the GEE header to determine which credentials to use in the EAP response. Note that this does not assume any GEE-related interface between the EAP and lower layers. It only implies that there must be a mechanism of providing the right identity or credential to the EAP layer based on the type of authentication requested by GEE. 5. GEE Message Format A GEE encapsulated packet has the following format. Barany, et al. Expires August 5, 2007 [Page 7] Internet-Draft GEE February 2007 --------------------------------- | | | EAP packet | | | --------------------------------- | | | GEE header | | | --------------------------------- | | | Data link layer header | | | --------------------------------- Figure 3: GEE Encapsulated Packet 5.1. GEE Header Format The GEE Header has the following format. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Version|TID|RFL| +-+-+-+-+-+-+-+-+ Figure 4: 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 August 5, 2007 [Page 8] Internet-Draft GEE February 2007 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 Master Session Key (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 lower layer of the peer MUST bind the MSKs to derive TSKs. The process of MSK binding is described in Section 6.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. 6. Packet Processing Details 6.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 with 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. 6.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 Barany, et al. Expires August 5, 2007 [Page 9] Internet-Draft GEE February 2007 header MUST be set to 01 if the encapsulated EAP packet is for Type 1 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. 6.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 Access Control Matrix In GEEv0, at least one of the authentications MUST be key generating and both authentications MUST 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. 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 occur in parallel, the keys must be bound as specified below. Barany, et al. Expires August 5, 2007 [Page 10] Internet-Draft GEE February 2007 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 a combined key as follows: Intermediate-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 at least 512 bits. With GEEv0, the PRF is HMAC-SHA-256. 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. 7. 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, providing a list of realms alone may not be sufficient. In those cases, the realm information itself is insufficient. Also, 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. Due to such limitations with existing mechanisms, other mechanisms are likely to be needed to support the required functionality for dynamic TID assignment. This document does not propose any such mechanisms at this time. Specifically, if there is a need for additional capability to use the identity hints and indicate the type of authentication via extensible Barany, et al. Expires August 5, 2007 [Page 11] Internet-Draft GEE February 2007 options (TLVs), the restriction imposed in GEEv0 on the semantics of the TID field can be removed for future versions of the protocol that may be developed. Further, future versions of GEE may use the last bit in the result flags/code (RFL) field to indicate the presence of TLVs in the GEE header. 8. 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]. 8.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 sequentially (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. The lower layer needs to negotiate the use of GEE. Lower layer implementations MAY choose to confirm the negotiation in the secure association protocol exchange performed after EAP. However, negotiation of GEE is an operational thing and no security properties are lost if such a confirmation is not done. 8.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. Note that if Type 1 authentication occurs first and subsequent authentication processes take place via a Layer 2 encrypted channel, Barany, et al. Expires August 5, 2007 [Page 12] Internet-Draft GEE February 2007 information about the rest of the authentications will not be available to passive observers on the path from the peer to the authenticator. However, this obviously suffers from the shortcoming that the multiple authentications cannot be executed in parallel if this is required. Further, this is no different than an eavesdropper obtaining information from the EAP headers on the wire when GEE is not used. Hence, such passive attacks are not considered to be of any additional significance in GEEv0. If future versions of GEE allow any sensitive data to be carried in GEE, passive attack considerations must be revisited. 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. 8.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 EAP conversations without GEE encapsulation are vulnerable to denial-of-service attacks, and GEEv0 does not change this vulnerability. 8.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. 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 pass off the successful Type 2 authentication of another peer as its own. 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 Barany, et al. Expires August 5, 2007 [Page 13] Internet-Draft GEE February 2007 authentication first, and require that the Type 2 authentication occur within the secure channel established as a result of Type 1 authentication. 8.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 [12] (and applicable security considerations) or other similar procedures. 8.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, 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 with the generated keys. When the multiple authentications are key generating and occur in parallel, GEEv0 requires that all of the MSKs resulting from each Barany, et al. Expires August 5, 2007 [Page 14] Internet-Draft GEE February 2007 authentication be used for access control in order to successfully prevent any MiTM attacks. When only one of the authentications is key generating or when the authentications occur sequentially, other administrative policies must be used to ensure that the threat is mitigated. When multiple authentications occur, packet modification attacks may cause the wrong type of access to be granted to the peer as a result of a particular authentication. To prevent this, specific authorization information must be sent from the backend AAA server to the authenticator specifying the type of access granted after a particular authentication. 9. IANA Considerations We request IANA to maintain a GEE registry. The registry will be version dependent and will contain the following items for GEEv0: The 4-bit Version field (Version 0 is to be registered for this RFC). Additional values can be allocated via IETF Review [13]. 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. 10. 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. 11. References 11.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. Barany, et al. Expires August 5, 2007 [Page 15] Internet-Draft GEE February 2007 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 11.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 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., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. [13] 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. [14] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. Barany, et al. Expires August 5, 2007 [Page 16] Internet-Draft GEE February 2007 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 August 5, 2007 [Page 17] Internet-Draft GEE February 2007 Joseph 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 August 5, 2007 [Page 18] Internet-Draft GEE February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 August 5, 2007 [Page 19]