Network P. Barany Internet-Draft R. Rezaiifar Expires: August 27, 2006 L. Dondeti V. Narayanan QUALCOMM, Inc. February 23, 2006 Generic EAP Encapsulation (GEE) draft-barany-eap-gee-00.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 August 27, 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 IP. EAP can be used for both access and service authentication, where the access network provider may or may not be the same as the service network provider. However, EAP itself does not have the Barany, et al. Expires August 27, 2006 [Page 1] Internet-Draft GEE February 2006 ability to differentiate between access and service authentication. Furthermore, when the service network provider is a mobility service provider, Mobile IP-AAA signaling is/can be used for service authentication; thereby making EAP service authentication redundant. However, EAP itself does not have the ability to instruct the peer that it should use Mobile IP-AAA signaling for service authentication instead of EAP. This document specifies a general encapsulation protocol, called Generic EAP Encapsulation (GEE), for differentiating between access and service authentication and for communicating to the peer that it should use Mobile IP-AAA signaling for service authentication instead of EAP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture and Overview . . . . . . . . . . . . . . . . . . 7 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. GEE Header Format . . . . . . . . . . . . . . . . . . . . 10 5. GEE Packet Handling at the Peer . . . . . . . . . . . . . . . 11 6. GEE Packet Handling at the Authenticator . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . 13 7.2.2. Threats that might cause theft of service . . . . . . 14 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Barany, et al. Expires August 27, 2006 [Page 2] Internet-Draft GEE February 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 both access and service authentication, where the access network provider may or may not be the same as the service network provider. However, EAP itself does not have the ability to differentiate between access and service authentication. Furthermore, when the service network provider is a mobility service provider, Mobile IP-AAA signaling is/can be used for service authentication; thereby making EAP service authentication redundant. However, EAP itself does not have the ability to instruct the peer that it should use Mobile IP-AAA signaling for service authentication instead of EAP. This document specifies a general encapsulation protocol, called Generic EAP Encapsulation (GEE), for differentiating between access and service authentication and for communicating to the peer that it should use an alternate method (e.g., Mobile IP) for service authentication instead of EAP, where applicable. 1.1. Motivation Barany, et al. Expires August 27, 2006 [Page 3] Internet-Draft GEE February 2006 +--------------+ +--------------+ | 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 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. Additionally, the two types of authentication may or may not be EAP- based, depending on the type of service that requires authentication. 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 the authenticator is the same for both authentications, it is not possible to clearly differentiate between the two types of authentications at the authenticator using available Barany, et al. Expires August 27, 2006 [Page 4] Internet-Draft GEE February 2006 means. The authenticator may be able to route the EAP Response Identity to the correct EAP server based on the NAI included in it. However, subsequent EAP packets may not have the peer identity in the packet - in this case, the authenticator will not know how 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 to occur in parallel via the same authenticator. Furthermore, the authenticator (or some entity attached to it), in many cases, would be expected to derive session keys with the EAP peer for link layer encryption following access authentication, using the keying material obtained from the EAP Server at the end of it. However, the outcome of a service authentication may not always result in the establishment of a security association, which implies that the authenticator may not receive keys from the EAP server at the end of the authentication. Instead, the authenticator may need to rely on mapping other identifiers (e.g., IP address) and Layer2 SAs to verify that a peer has been authenticated for both access and service. Thus, it is essential for the authenticator to distinguish service authentication from access authentication, so that it does not expect to receive keying material from the EAP server at the end of it. In summary, there is a need to identify multiple EAP runs at the authenticator and it is not entirely plausible to distinguish such runs based on [1]. For the specific instance where the service network provider is a mobility service provider, Mobile IP-AAA signaling [11] or IKEv2 [12], [13], [14] may be used for service authentication. In such a scenario, EAP-based service authentication may be redundant and therefore not required. This applies to both Mobile IPv4 [15], and Mobile IPv6 [16]. However, EAP itself does not have the ability to instruct the peer that it should use Mobile IP-AAA signaling or IKEv2 for service authentication instead of EAP. While a Mobile IPv4/IPv6 client may potentially be configured to use the right type of authentication, it is often desirable to let the network provider tell the client what type of authentication should be performed. 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 Barany, et al. Expires August 27, 2006 [Page 5] Internet-Draft GEE February 2006 the peer and the authenticator. It is important that the EAP peer and authenticator be able to differentiate the network and service access 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) [17] 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. Hence, the motivation for this document is to provide the functionality for EAP peers and authenticators to differentiate between network access and service authentication and to provide a means for the network provider to inform the peer about the type of service authentication that must be used. 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 August 27, 2006 [Page 6] Internet-Draft GEE February 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 been 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 access and service authentication independently and potentially with different authentication servers in different provider networks. The two EAP instances may happen sequentially or in parallel. However, in accordance with this version of the protocol, access and service authentication MUST NOT be handled by the same EAP exchange, unless the access and service 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 August 27, 2006 [Page 7] Internet-Draft GEE February 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 Figure 2 shows the protocol stack for GEE in the EAP multiplexing model. Barany, et al. Expires August 27, 2006 [Page 8] Internet-Draft GEE February 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 lower layer (e.g., RADIUS [18]). 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 make certain decisions on routing the EAP packet. For instance, service authentication requests may be routed to a specific backend authentication server, based on policy. Such policies and decisions themselves are outside the scope of this document. 4. Message Format A GEE encapsulated packet has the following format. Barany, et al. Expires August 27, 2006 [Page 9] Internet-Draft GEE February 2006 --------------------------------- | | | Data link layer header | | | --------------------------------- | | | GEE header | | | --------------------------------- | | | EAP packet | | | --------------------------------- Figure 4: 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 |A|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: GEE Header version 8-bit GEE protocol version number. This field MUST be set to 0 in this version of the specification. Access (A) 1-bit "Access type" flag. When A = 1, the encapsulated EAP packet is for access authentication. When A = 0, the encapsulated EAP packet is for service authentication. Mobile IP (M) 1-bit "Mobile IP authentication" flag. Barany, et al. Expires August 27, 2006 [Page 10] Internet-Draft GEE February 2006 In a GEE encapsulated EAP packet sent by the authenticator: When M = 0, then the peer MUST NOT use Mobile IP (either Mobile IPv4 or Mobile IPv6, or both) for service authentication. When M = 1, then the peer MUST use Mobile IP (either Mobile IPv4 or Mobile IPv6, or both) for service authentication. In a GEE encapsulated EAP packet sent by the peer: This field SHOULD be set to 0 by the peer. This field MUST be ignored by the authenticator. Reserved A 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 5. GEE Packet Handling at the Peer When the peer receives a GEE packet, the A flag in the GEE header MUST be used to determine if the encapsulated EAP packet is for access or service authentication. If the A flag is set to 1 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 A=1, the peer MUST ignore the M flag value. When the A flag is set to 0 in the packet received from the authenticator, the peer must perform the necessary service authentication. When the peer receives a GEE packet with the A flag set to 0, it MUST check the value of the M flag. If the M flag is set to 0, it MUST proceed with the EAP processing on the packet. If the M flag is set to 1, the GEE layer on the peer MUST examine the EAP Code field to ensure that the enclosed EAP packet is a Failure (EAP Code = 4) packet. If the enclosed EAP packet is not a Failure packet, the peer Barany, et al. Expires August 27, 2006 [Page 11] Internet-Draft GEE February 2006 MUST silently discard the packet. The GEE process on the peer examining the EAP Code field allows existing EAP implementations to use GEE without affecting the EAP layer implementation. When the peer sends a GEE packet, the A flag in the GEE header MUST be set to 0 if the encapsulated EAP packet is for access authentication. The A flag MUST be set to 1 by the peer if the encapsulated EAP packet is for service authentication. When the peer sends a GEE packet, the M flag in the GEE header SHOULD always be set to 0. 6. GEE Packet Handling at the Authenticator When the authenticator receives a GEE packet, the A flag in the GEE header MUST be used to determine if the encapsulated EAP packet is for access or service authentication. When the authenticator receives a GEE packet, the authenticator MUST ignore the M flag. When the authenticator sends a GEE packet, the A flag in the GEE header MUST be set to 1 if the encapsulated EAP packet is for access authentication. The A flag MUST be set to 0 by the authenticator if the encapsulated EAP packet is for service authentication. When the authenticator sends a GEE packet, with A=0, and the encapsulated EAP packet is a Failure packet (i.e., the Code field is set to 4) [1], the M flag in the GEE header MUST be set to 1, if, based upon policy, the peer MUST use Mobile IP (either Mobile IPv4 or Mobile IPv6, or both) for service authentication instead of EAP. If a backend authentication server is used, the policy is communicated to the authenticator by the backend authentication server via AAA signaling, that contains both the Failure packet and the policy. If the authenticator has no policy corresponding to this and if it did not receive any policy indication from the AAA server, it MUST NOT set the M flag in the GEE packet. If the encapsulated EAP packet is not a Failure packet, then the M flag MUST be set to 0. 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. Barany, et al. Expires August 27, 2006 [Page 12] Internet-Draft GEE February 2006 We note that the vulnerabilities discussed here in are in addition to those considered in EAP [1] and are somewhat similar to those that apply to the PANA protocol suite (RFC 4016 [19] and other PANA drafts). 7.1. Recap of use cases and interactions between network entities GEE encapsulates EAP so an authenticator can signal to the peer whether the EAP request is for access or service authentication, and within service authentication whether EAP or Mobile IP is to be used. GEE also facilitates parallel access and service authentication. 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 service, access and Mobile IP authentication is 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 service or Mobile IP authentication 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 or the A and M flags, to cause either the peer or the authenticator to drop GEE encapsulated EAP packets. Suppose an attacker consistently changes the value of the A 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 Barany, et al. Expires August 27, 2006 [Page 13] Internet-Draft GEE February 2006 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 service authentication is known to be weaker than the EAP method used for access authentication, whereas the authenticator may intend to enforce access authentication before service authentication, an attacker may modify the GEE flags to cause the peer to start the service authentication without the protection of access authentication. The adversary may then be able to break the weaker authentication method and gain access to IP services. Even if the authenticator requires 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 service authentication method is more vulnerable to attacks than the EAP method used for access authentication, 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. 8. Extensibility Version 0 of GEE specified in this document allows the peer or the authenticator to signal whether an EAP message is for access or service authentication. Others have found the need to support a combination of user and device authentication in some networks. We note that other versions of GEE can support signaling device and user authentication and other similar uses in addition to the access and service authentication facilitated by Version 0. The Version field in the GEE header is the RECOMMENDED method to support other simple/lightweight encapsulations of EAP. Other versions of GEE may redefine the flags field (including the reserved portion of Version 0, specified in this document). All such uses of GEE must be registered with IANA in a new registry to be created for GEE. (The best position for the GEE registry might be as a sub- registry of EAP, if that's controversial, a separate registry will do as well). Barany, et al. Expires August 27, 2006 [Page 14] Internet-Draft GEE February 2006 9. IANA Considerations We request IANA to maintain a GEE registry to which new values are added after IESG review. The registry will contain an 8-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. 10. Acknowledgments We thank Jun Wang and AC Mahendran for their review of earlier versions of this draft. 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. 11.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 Barany, et al. Expires August 27, 2006 [Page 15] Internet-Draft GEE February 2006 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] Perkins, C., "Mobile IPv4 Challenge/Response Extensions (revised)", draft-ietf-mip4-rfc3012bis-05 (work in progress), February 2006. [12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [13] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with IKEv2 and the revised IPsec", draft-ietf-mip6-ikev2-ipsec-04 (work in progress), October 2005. [14] Tschofenig, H. and P. Eronen, "Extension for EAP Authentication in IKEv2", draft-eronen-ipsec-ikev2-eap-auth-04 (work in progress), October 2005. [15] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [16] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [17] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. [18] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [19] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005. [20] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, Barany, et al. Expires August 27, 2006 [Page 16] Internet-Draft GEE February 2006 August 2005. [21] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [22] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [23] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. Appendix A. Examples Figure 6 illustrates the basic, successful full EAP access and service authentication exchange. The details of the EAP method exchange for both access and service authentication are omitted for brevity. The backend authentication server is a RADIUS server. peer authenticator backend authentication (i.e., Supplicant) (e.g., NAS) server (e.g., RADIUS server) ------------------- ------------- --------------------- *Begin access authentication <- GEE hdr w/Access Type = Access Auth and MIP Auth = no MIP Auth [EAP-Request/ Identity] GEE hdr w/Access Type = Access Auth [EAP-Response/ Identity (e.g., NAI)] -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (e.g., NAI) -> <----- access authentication with key-generating EAP method -----> <- RADIUS Access-Accept/ EAP-Message/EAP- Barany, et al. Expires August 27, 2006 [Page 17] Internet-Draft GEE February 2006 Success (attribute containing key) <- GEE hdr w/Access Type = Access Auth and MIP Auth = no MIP Auth [EAP-Success] *Begin service authentication <- GEE hdr w/Access Type = Service Auth and MIP Auth = no MIP Auth [EAP-Request/ Identity] GEE hdr w/Access Type = Service Auth [EAP-Response/ Identity (e.g., NAI)] -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (e.g., NAI) -> <--- service authentication with non-key-generating EAP method ---> <- RADIUS Access-Accept/ EAP-Message/EAP- Success <- GEE hdr w/Access Type = Access Auth and MIP Auth = no MIP Auth [EAP-Success] Figure 6: EAP Access and Service Authentication Example *Access and service authentication can occur in parallel. Both access and service authentication may not be necessary (e.g., if the access network provider is the same as the service network provider). Figure 7 illustrates the basic, successful full EAP access and MIPv4 service authentication exchange. The details of the EAP method exchange for access authentication and of the MIPv4 exchange for Barany, et al. Expires August 27, 2006 [Page 18] Internet-Draft GEE February 2006 service authentication are omitted for brevity. The backend authentication server is a RADIUS server. peer authenticator backend authentication (i.e., Supplicant) (e.g., NAS) server (e.g., RADIUS server) ------------------- ------------- --------------------- *Begin access authentication <- GEE hdr w/Access Type = Access Auth and MIP Auth = no MIP Auth [EAP-Request/ Identity] GEE hdr w/Access Type = Access Auth [EAP-Response/ Identity (e.g., NAI)] -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (e.g., NAI) -> <----- access authentication with key-generating EAP method -----> <- RADIUS Access-Accept/ EAP-Message/EAP- Success (attribute containing key) <- GEE hdr w/Access Type = Access Auth and MIP Auth = no MIP Auth [EAP-Success] *Begin service authentication <- GEE hdr w/Access Type = Service Auth and MIP Auth = no MIP Auth [EAP-Request/ Barany, et al. Expires August 27, 2006 [Page 19] Internet-Draft GEE February 2006 Identity] GEE hdr w/Access Type = Service Auth [EAP-Response/ Identity (e.g., NAI)] -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (e.g., NAI) -> <- RADIUS Access-Reject/ EAP-Message/EAP- Failure (attribute indicating that MIPv4 authentication is to be performed) <- GEE hdr w/Access Type = Access Auth and MIP Auth = yes MIP Auth [EAP-Failure] <---------------- service authentication with MIPv4 ----------------> Figure 7: EAP Access and MIP4 Service Authentication Example *Access and service authentication can occur in parallel. Both access and service authentication may not be necessary (e.g., if the access network provider is the same as the service network provider). Barany, et al. Expires August 27, 2006 [Page 20] Internet-Draft GEE February 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 August 27, 2006 [Page 21] Internet-Draft GEE February 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 August 27, 2006 [Page 22]