Internet-Draft Yoshihiro Ohba (Editor) Expires: December, 2002 Subir Das Basavaraj Patil Hesham Soliman June 17, 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 December, 2002 [Page 1] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 Table of Contents 1 Terms ................................................... 2 1.1. Acronyms ................................................ 2 1.2. Terminology ............................................. 2 2. Problem Space ........................................... 4 3. PANA Model .............................................. 6 3.1. Simple PANA Model ....................................... 6 3.2. Advanced PANA model ..................................... 7 3.2.1. PAA Co-located with Access Router ....................... 8 3.2.2. PAA Separated from Access Router ........................ 9 4. Usage Scenarios ......................................... 9 4.1. Initial Authentication Timing ........................... 9 4.2. Multiple Access Routers ................................ 10 4.3. Multiple-Interface Device .............................. 10 4.4. PANA as a Per-packet Protection Enabler ................ 11 5. Security Consideration ................................. 11 6. Acknowledgments ........................................ 12 7. References ............................................. 12 8. Authors' Information ................................... 12 1 Terms 1.1. 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 NAS: Network Access Server PAA: PANA Authentication Agent PaC: PANA Client PPP: Point-to-Point Protocol 1.2. Terminology Following terminologies are defined for this document. See also [PANAREQ]. Expires December, 2002 [Page 2] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 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 PANA 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. Edge Subnet The immediate IP subnet that is available to an interface of the device for network access. PANA Client (PaC) An entity in the edge subnet who is 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) An entity in the edge subnet whose responsibility is to authenticate the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. Access Point A first-hop wireless L2 attachment point from the device in the edge subnet. Access Router A router in the edge subnet. Local Security Association (LSA) A temporary security association between a PaC and a PAA, which is derived from credentials of the PaC during initial authentication. Initial Authentication Authentication performed when a device enters into the edge subnet and provides the credentials to be authorized for network access without having any a priori authorization information. This will require a PAA to verify the credentials either locally or by using a back-end authentication infrastructure. Expires December, 2002 [Page 3] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 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 PAA 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 PaC and a PAA by using the LSA established between them. In this type of re-authentication, the PaC 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 edge subnet as long as authentication for establishing L2 connectivity is not a mandatory part in the specification of an L2 protocol. For example, the best current practice of Ethernet links that are composed of legacy hubs and switches does not use 802.1X authentication. This leads to the following need: i) Need for authentication over L2 links that do not support an appropriate authentication mechanism. In order to satisfy this need where authentication for network access is required, a higher layer protocol for authentication is appropriate. PPP over Ethernet [PPPoE] is currently used for both client authentication and IP packet encapsulation over Ethernet over DSL, however, it was not intended to be used for authentication over multi-access links, and more appropriate authentication carrier protocol that does not require PPP encapsulation over multi-access links is deemed necessary. It is a common practice to use higher-layer authentication on top of link-layer authentication. For example in 3GPP and 3GPP2, PPP is used for authentication after link-layer authentication succeeds. Or, http-redirect method is used as a higher-layer user authentication in some other network access architectures. This leads to the following need: Expires December, 2002 [Page 4] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 ii) Need for L3 authentication separated from L2 authentication Multi-layer authentication is necessary when each authentication layer is associated with a different level of network access authorization. For example, when an ASP (Access Service Provider) provides hot-spot wireless access service from which a user device can connect to its own ISP(s), it is possible to use L2 authentication to access one of the ASPs in the hot-spot area, but higher layer authentication is needed when connecting to one of its ISPs. 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: iii) 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 edge subnet 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 proper change is informed by the entity that was once authenticated successfully. It is also important that re-authentication is performed locally between the PaC and the PAA without involving other network entities. However, there might be some instances 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. With regard to case (a), considering mobile and wireless environments, it is possible that a device has multiple wireless interfaces and switches frequently from one interface to another in the same administrative domain. This type of switching can occur with or without changing an IP address based on variable requirements (e.g., power saving vs. throughput). In this scenario, re-authentication is necessary for the new interface to be authorized for network access, and it is important that re- authentication is performed locally between the PaC and the PAA for fast interface switching. The need for local re- authentication for interface switching immediately leads to a need for another access-independent authentication mechanism that supports: Expires December, 2002 [Page 5] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 o an access technology independent authentication protocol for providing a generic method for local re-authentication among different interfaces, AND o an access independent PaC identifier for associating the different interfaces with the same LSA that is used for local re-authentication. Local authentication described above should be taken into account when designing and implementing an L3 authentication carrier protocol (and any sort of authentication carrier protocol as well). 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. 3. PANA Model Following sub-sections capture the PANA usage model in different network architectures with reference to its placement of logical elements such as, PANA Client (PaC) and PANA Authentication Agent (PAA). 3.1. Simple PANA Model Figure 1 describes a simple architecture in which PAA resides on the first hop access router (AR) and PaC on behalf of a device (D1, D2,.. etc) communicates with PAA for network access. As shown in figure, PaC can use different L2 interfaces to connect to the first hop access router. PAA may or may not use AAA infrastructure to verify the credentials of PaC and grants or deny the device (belongs to that particular PaC) to access the network resources. PANA in this case provides a means to transport the authentication parameters from the PaC to PAA securely. PAA understands how to verify the credentials. After verification, PAA sends back the success or failure to PaC. Although the AR would be the access control enforcement point in this case, PANA does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. Expires December, 2002 [Page 6] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 <============== PANA ===============> +-----------------------------+ | An edge IP subnet | | | | D1 ----[DSLAM]---------+ | | [PaC] | | | | | (AAA infrastructure) | | | . | D2 ----[Ethernet Hub]--+ | . | [PaC] | | . | +-------------AR---------(Internet) | | | [PAA] | D3 ----[802.11a/b AP]--+ | | [PaC] | | | | | | | | | D4 ----[Cellular AP]--+ | | [PaC] | +-----------------------------+ Figure 1: An example of simple PANA model 3.2. Advanced PANA model Figure 2 presents an advanced architecture where, multiple routers are placed in an edge subnet and the device has one or more interfaces. For simplicity, optional connection to AAA infrastructure is not shown in the figures of this section. Each interface of a device supports a specific L2 type. Thus the edge IP subnet consists of one or more L2 segments, where those segments can be different L2 types. PANA can support this advanced architecture in two different ways: (i) co-location of PAA with access router and (ii) separation of PAA from access router. Although this section describes generic models, more detailed issues on multiple access routers and multiple-interface devices are provided in section "Usage Scenarios". Expires December, 2002 [Page 7] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 +------------------------------+ | An edge IP subnet | | | | D1------[DSLAM]----------+ | | | | | +--------- AR | | | \ | D2------[Ethernet Hub]---+ | \ | | | \ | +--------- AR--+---------(Internet) | | | / | D3--+---[802.11a/b AP]---+ | / | | | | / | | +--------- AR | | | | | +---[Cellular AP]----+ | | | +------------------------------+ Figure 2: An example of Advanced Architecture 3.2.1. PAA Co-located with Access Router In this scenario (Figure 3), multiple PAAs can co-exist especially when there are multiple access routers in the edge subnet. PAAs are co-located with these access routers on which access control is performed. When a PaC needs to be authenticated and authorized for network access it exchanges PANA messages (as described above) with a PAA. <============== PANA ================> +------------------------------+ | An edge IP subnet | | | | D1------[DSLAM]----------+ | |[PaC] | | | +---------- AR | | | [PAA]\ | D2------[Ethernet Hub]---+ | \ |[PaC] | | \ | +---------- AR----+--------(Internet) | | | [PAA] / | D3--+---[802.11a/b AP]---+ | / |[PaC]| | | / | | +-----------AR | | | | [PAA] | +---[Cellular AP]----+ | | | +------------------------------+ Figure 3: An example of Advanced PANA Model [PAA co-located with AR] Expires December, 2002 [Page 8] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 3.2.2. PAA Separated from Access Router Figure 4 describes this model. In this scenario, PAA is not co- located with AR but resides on the edge subnet. PaC exchanges the same messages with PAA as discussed earlier. The difference here is when initial authentication for the PaC is successful, access control parameters are to be distributed to all access routers residing in the edge subnet so that the device that PaC resides is authorized at all the access routers. However, PANA does not provide any mechanism how access control parameters are to be distributed. This is in fact outside the scope of PANA. <============== PANA =================> +------------------------------+ | An edge IP subnet | | | | D1------[DSLAM]----------+-----------PAA |[PaC] | | | +---------- AR | | | \ | D2------[Ethernet Hub]---+ | \ |[PaC] | | \ | +---------- AR---+---------(Internet) | | | / | D3--+---[802.11a/b AP]---+ | / |[PaC]| | | / | | +-----------AR | | | | | +---[Cellular AP]----+ | | | +------------------------------+ Figure 4: An example of Advanced PANA Model [PAA separated from AR] 4. Usage Scenarios 4.1. Initial Authentication Timing There are two possible scenarios with regard to the timing at which initial authentication occurs, i.e., initial authentication can occur before or after IP address configuration. 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." There are a number of situations where authentication before IP address configuration would be important, for example: a) If strict access control is required or the IP address resource Expires December, 2002 [Page 9] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 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, initial 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, initial authentication should occur before IP address configuration. On the other hand, initial authentication after IP address configuration would be useful for providing a network access 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. 4.2. 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 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 performed, it would be desired to perform authentication via the same AR. This is one scenario where Figure 3 of the advanced PANA model is applied. On the other hand, there are some cases in which such a routing control would not be possible. For example, if we consider to use "ICMP Redirect or IPv6 Host to Router Load Sharing" [Hinden] mechanism, either Figure 3 or Figure 4 of the advanced PANA model would be applied. Anyway, additional mechanisms would be required for distributing access control parameters from one PAA to other access router(s) that are not physically co-located with the PAA. In other words, the types of routing control would affect the location of PAA as well as the way of access control in multi-AR environments. 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. 4.3. Multiple-Interface Device A device can have multiple interfaces of homogeneous or heterogeneous technologies. Thus, there are two possible scenarios for PANA: multi-homing and interface switching. Expires December, 2002 [Page 10] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 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 should 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, it is important to 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. 4.4. PANA as a Per-packet Protection Enabler Although PANA itself does not define key distribution protocol and mechanism, it is possible to use PANA to enable per-packet protection mechanism (such as IPsec and WEP) to secure communication in the edge subnet, if the authentication carrier protocol that is used by PANA supports key distribution mechanism. Note that using PANA for WEP key distribution would be useful (if implemented appropriately) when L2 authentication is null or does not have key distribution capability. 5. 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 edge subnet. 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. Expires December, 2002 [Page 11] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 o Consideration for Man-In-The-Middle Attacks Consideration is necessary for preventing the communication between PaC and PAA from being spoofed by an attacker in between. The attacker could be on the same edge subnet as PaC and PAA, e.g., by putting a bogus access point between a PaC and a PAA in the edge subnet. 6. Acknowledgments The authors would like to thank James Carlson, Jacques Caron, Paal Engelstad, Henry Haverinen, James Kempf, Thomas Narten, Erik Nordmark, 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. 7. 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. [PPPoE] L. Mamakos, et al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [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. 8. 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 Expires December, 2002 [Page 12] Internet-Draft Problem Space & Usage Scenarios for PANA June 17, 2002 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 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 December, 2002 [Page 13]