Internet-Draft Yoshihiro Ohba (Editor) Expires: September, 2002 Subir Das Basavaraj Patil Hesham Soliman March 1, 2002 Problem Space and Usage Scenarios for PANA Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents, valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Most of the commercial networks today require users (or devices on behalf of users) to provide their authentication information, such as identity, device identifier, etc., before being allowed access to network resources. Resources here include basic access to the network, specific value added services, different grade of services etc. While such networks are available in the market place, the authentication process and access control mechanisms depend upon the type of network that a user is attaching to and in most cases it is specific to an access technology. Due to the rapid proliferation of access technologies, wireless devices and next generation services offerings, a flexible authentication (which is independent of underlying access technologies) and access control mechanisms are deemed necessary. This document therefore attempts to describe several such scenarios where existing mechanisms are not sufficient and finally argue the need for a new higher layer protocol called PANA (Protocol for carrying Authentication for Network Access). It also helps to understand the problem space clearly and facilitate the discussion for PANA requirements and framework. Expires September, 2002 [Page 1] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 Table of Contents 1 Terms ................................................... 2 1.1. Requirements Language ................................... 2 1.2. Acronyms ................................................ 2 1.3. Terminology ............................................. 2 2. Problem Space ........................................... 4 3. Usage Scenarios ......................................... 7 3.1. Multiple Access Routers ................................. 7 3.2. Multiple-Interface Device ............................... 7 4. Security Consideration .................................. 8 5. Acknowledgments ......................................... 8 6. References .............................................. 9 7. Authors' Information .................................... 9 1 Terms 1.1. Requirements Language 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 [Keywords]. 1.2. Acronyms AAA: Authentication, Authorization and Accounting AP: Access Point AR: Access Router DSL: Digital Subscriber Line EAP: Extensible Authentication Protocol GPRS: General Packet Radio Service LSA: Local Security Association PDP: Packet Data Protocol PKI: Public Key Infrastructure NAS: Network Access Server PAA: PANA Authentication Agent PaC: PANA Client PPP: Point-to-Point Protocol 1.3. Terminology Expires September, 2002 [Page 2] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 Following terminologies are defined for this document. See also [PANAREQ]. Device A network element (namely notebook computers, PDAs, etc.) that requires access to a provider's network. Device Identifier (DI) The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, identifier might contain any of IP address, link- layer address, switch port number, etc. of a device. PANA authentication agent keeps a table for binding device identifiers to the PANA clients. PANA Client (PaC) The entity wishing to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a device and a set of credentials to prove its identity within the scope of PANA. PANA Authentication Agent (PAA) The entity whose responsibility is to authenticate the credentials provided by a PANA client either locally or by using a back-end authentication infrastructure such as a AAA infrastructure and grant basic network access and specific service (if requested) to the device associated with the client and identified by a DI. Local Network The immediate network(s) that is available to the device for network access. Client An entity that resides on the device and provides authentication information to a NAS in the local network. PaC is a client. Network Access Server (NAS) An entity in the local network which resides at the edge and allows network access to the device after verifying the credentials provided by the client. For example, PAA is a NAS. Access Point A first-hop wireless L2 attachment point from the device in the local network. Access Router Expires September, 2002 [Page 3] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 A first-hop router from the device in the local network. Local Security Association (LSA) A temporary security association between a client and a NAS, which is derived from credentials of the client during initial authentication. Initial Authentication Authentication performed when a device enters into a local network and provides the credentials to be authorized for network access without having any a priori authorization information. This will require a NAS to verify the credentials either locally or by using a back-end authentication infrastructure. Re-authentication Authentication that occurs when a device needs to extend the authorization lifetime, changes attributes such as, IP address and/or MAC address, etc., for the same network access after successful initial authentication. This may require a NAS to verify the credentials (used for initial authentication) either locally or by using a back-end authentication infrastructure. Local re-authentication A type of re-authentication that occurs locally between a client and a NAS by using the LSA established between them. In this type of re-authentication, the client does not use the same credentials as used for initial authentication. Higher Layer A layer that is higher than layer two. 2. Problem Space Today's technologies mostly rely on access specific authentication mechanisms (i.e., L2 authentication mechanisms) for network access. For example, PPP has a built-in mechanism for peer authentication [RFC1661] and IEEE 802 networks define a port-based network access control with peer authentication in point-to-point LAN segments [802.1X]. However, it is not guaranteed that L2 authentication is always available in the local network as long as authentication for establishing L2 connectivity is not a mandatory part in the specification of an L2 protocol, and this leads to the following need: i) Need for authentication over unauthenticated L2 links In order to satisfy this need where authentication for network access is required, a higher layer protocol for authentication is clearly needed. While it is true that L2 can be extended to support authentication, we argue that a common higher layer protocol will provide a flexible and generic solution to all L2s. Expires September, 2002 [Page 4] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 Due to the rapid proliferation of access technologies, wireless devices are becoming very popular. On the other hand, these technologies demands different kinds of authentication, such as: ii) Need for local re-authentication Re-authentication is necessary at least in the following situations: a) If the underlying access network does not have a capability to detect physical disconnection of devices, periodical re- authentication is necessary for minimizing the impact of attacks (e.g., free riding) due to IP address and/or MAC address spoofing, which would possibly occur when the device is shutdown or the user leaves the local network with the device without performing explicit log-off from the local network. b) If there is a change in attributes (e.g., IP address and/or MAC address) of a device, re-authentication is necessary in order to make sure that the change is informed by the entity that was once authenticated successfully. It is desired that re-authentication is performed locally between client and NAS as much as possible. However, there might be some cases where re-authentication with help of back-end authentication infrastructure is necessary in addition to local re- authentication, considering security for accounting such as non- repudiation. While L2 authentication with some EAP mechanism [EAPSRP,RFC2284] that supports built-in local re-authentication may be used for situations in case (a), there are some scenarios where L2 authentication is not desired. For example, considering mobile and wireless environments, it is possible that a device has multiple wireless interfaces and switches from one interface to other in the same administrative domain with or without changing an IP address based on variable requirements (e.g., power saving vs. throughput). In this case, re-authentication is necessary for the new interface to be authorized for network access, and it is desired that re-authentication is performed locally between the client and NAS in order to perform interface switching quickly. The need for local re-authentication for interface switching immediately leads to a need for an access-independent authentication mechanism that supports: o an access technology independent authentication protocol for providing a generic method for local re-authentication among different interfaces, AND o an access independent client identifier for associating the different interfaces with the same LSA that is used for local re-authentication. On the other hand, using an access-independent authentication mechanism is not sufficient for local re-authentication, and additional consideration for location of NAS is also necessary. Expires September, 2002 [Page 5] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 For example, if two NASes of L2 technologies A and B are physically in different boxes, it is not possible to use L2 authentication to perform local re-authentication without using another protocol such as a context transfer protocol and/or a AAA protocol (note: initial authentication does not necessarily require a AAA protocol) in order to share the LSA used for local re-authentication directly or indirectly between the two L2 NASes. Thus, a higher layer protocol that provides not only an access- independent authentication mechanism but also flexibility in location of NAS is needed so that a client can continue to use a single NAS for performing local re-authentication in a "self- contained" manner (i.e., without requiring other protocols) when interface switching occurs. So far we have described the problem space and the need for an additional authentication protocol at the higher layer. In the following section we present some important issues that such a higher protocol MUST satisfy and consider them as base requirements. iii) Need for authentication independent of IP address configuration There are two types of independence between authentication and IP address configuration as described below. Note that "IP address configuration" in this document means configuration of an IP address that needs to be authorized for network access, and thus configuring an IPv6 link local address or any temporal IP address that is used only for authentication purpose and not necessarily authorized for network access is excluded from the definition of "IP address configuration." o Method independence. Authentication MUST be independent of any IP address configuration method for both dynamic address configuration (e.g., DHCPv4/v6, and IPv6 stateless address autoconfiguration, etc.) and static address configuration. o Timing independence. Authentication MUST be able to occur both before and after configuring an IP address. There are a number of situations where authentication before IP address configuration would be necessary, for example: a) If strict access control is required or the IP address resource used for network access is scarce, authentication should occur before IP address configuration. b) If an AP supports multiple VLANs and it is possible to dynamically associate a device with one of the VLANs depending on the authentication and authorization result, authentication should occur before IP address configuration. c) If a distinct IPv6 64-bit prefix can be assigned to each PDP context in GPRS[GPRS] or to each subscriber of DSL or cable internet, authentication should occur before IP address configuration. On the other hand, authentication after IP address configuration would be useful for providing a network access Expires September, 2002 [Page 6] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 service in which access to local information such as local-area map and flight information for free of charge, while access to specific external web-sites is subject to charge. In conclusion, we anticipate that a higher layer protocol like PANA (Protocol carrying Authentication for Network Access) will satisfy all of the above needs that are emerging. We also understand that there are some functional overlap between L2 authentication and PANA. However, it is not very clear at this moment whether PANA and L2 authentication both are required for a network or they can be used exclusively for different scenarios. In the following section, the problem domain is translated into few scenarios which we believe MUST be supported by PANA: - Multiple access routers - Multiple-interface device 3. Usage Scenarios 3.1. Multiple Access Routers In multi-access environments, such as IEEE 802 networks, it is possible for multiple ARs to coexist on the same shared media. In such a scenario, it would be desirable to use multiple ARs in such a way that traffic coming from and going to a specific device always goes through a single AR for ease of access control, but traffic from different devices diverges over multiple ARs for the purpose of load balancing and redundancy. If such a routing control is possible, it would be easier to perform authentication via the same AR. On the other hand, there are some cases in which such a routing control would not be possible. This is due to e.g., ICMP Redirect or the use of "IPv6 Host to Router Load Sharing" [Hinden], and it may be better to put a PANA authentication agent separately from ARs in those cases. In other words, the types of routing control would affect the location of PAA in multi-AR environments. Given that the location of PAA is not restricted within ARs, PANA MUST have a mechanism to provide the information of the location of PAA(s) to devices. The multi-AR scenario also addresses the issue of multiple providers on the same shared media, i.e., each AR may not be administered by the same provider. In this case, it would be necessary for PANA to have a mechanism to provide the identity of PAA(s) for a PaC so that the PaC can choose an appropriate provider to access. The important point is PANA MUST support all multi-AR scenarios. 3.2. Multiple-Interface Device PANA MUST support a device with multiple interfaces of homogeneous or heterogeneous technologies. There are two possible scenarios: multi- homing and interface switching. Expires September, 2002 [Page 7] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 In case of multi-homing, the multiple interfaces of a device may be activated at the same time for various requirements such as increased bandwidth, load balancing and reliability. PANA MUST provide a way for the PaC of the device to perform initial authentication and local re-authentication for each interface. In case of interface switching, PANA MUST use an access-independent authentication mechanism (as described in section 2). This access- independent authentication mechanism allows a PaC to perform local re-authentication with a PAA when interface switching occurs. Location of the PAA MUST be flexible so that the PaC can use the same PAA for each interface while it is roaming within the same domain. This will allow a device to roam seamlessly among different access technologies within an operator's domain. 4. Security Consideration We anticipate following security issues or concerns relating to a higher layer protocol such as PANA. o Consideration for Eavesdropping Since PANA protocol carries authentication information, consideration is necessary for preventing confidential part of the credentials of a PaC from being known by eavesdroppers in the local network. The eavesdroppers include users and operators in the local network. o Consideration for Denial of Service Attacks Since PANA protocol is used for authentication, consideration is necessary for preventing authentication of a legitimate PaC from being denied as a result of processing PANA messages sent from attackers. Next, since both initial authentication and re- authentication would require cryptographic computation on both PaC and PAA, consideration is necessary for both PaC and PAA not to spend CPU and memory resources for processing PANA messages sent from an attacker more than that is spent by the attacker to attack. The attackers may or may not be on the same link as the PaC or PAA. Additionally, since during initial authentication PAA may use back-end authentication infrastructure, consideration is necessary to prevent the authentication infrastructure from being attacked via PAA while using PANA. o Consideration for Man-In-The-Middle Attacks Since PANA protocol needs to be able to operate over multiple router hops, consideration is necessary for preventing the communication between PaC and PAA from being spoofed by an attacker in between. 5. Acknowledgments Expires September, 2002 [Page 8] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 The authors would like to thank James Carlson, Jacques Caron, Paal Engelstad, Henry Haverinen, James Kempf, Phil Roberts, David Spence, Barani Subbiah, George Tsirtsis, Cliff Wang, Alper Yegin, and the rest of the PANA Working Group for the ideas and support they have given to this document. 6. References [802.1X] IEEE Standard for Local and Metropolitan Area Networks, "Port-Based Network Access Control", IEEE Std 802.1X-2001. [EAPSRP] J. Carlson, et al., "EAP SRP-SHA1 Authentication Protocol", Internet-Draft, Work in progress, July 2001. [GPRS] R. Bates, "GPRS", McGraw-Hill TELECOM, ISBN 007138188, 2002. [Hinden] R. Hinden, "IPv6 Host to Router Load Sharing", Internet-Draft, Work in progress, January 2002. [Keywords] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PANAREQ] A. Yegin, et al., "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", Internet-Draft, Work in progress, February 2001. [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD 51), July 1994. [RFC2284] L. Blunk, et. al., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. 7. Authors' Information Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ 07961-0136 USA Phone: +1 973 829 5174 Fax: +1 973 829 5601 Email: yohba@tari.toshiba.com Subir Das MCC 1D210R, Telcordia Technologies 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA Phone: +1 972-894-6709 Expires September, 2002 [Page 9] Internet-Draft Problem Space & Usage Scenarios for PANA March 1, 2002 Email: Basavaraj.Patil@nokia.com Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 29, Kista, Stockholm 16480 Sweden Phone: +46 8 4046619 Fax: +46 8 4047020 E-mail: Hesham.Soliman@era.ericsson.se Expires September, 2002 [Page 10]