PANA Working Group Alper E. Yegin, Editor INTERNET-DRAFT Yoshihiro Ohba Date: March 2002 Reinaldo Penno Expires: September 2002 George Tsirtsis Cliff Wang Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1x for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of the PANA Working Group is to design a general network-layer protocol to authenticate clients to the networks. The protocol will run between a client's device and an agent device in the network where the agent might be a client of the AAA infrastructure. The protocol should be independent of the underlying access-type and not be limited to specific network topologies. This document defines the common terminology and identifies the requirements for PANA. Yegin (Editor), et. al. Expires Sep 2002 [Page 1] Internet Draft PANA Requirements and Terminology Mar 2002 Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Table of Contents.................................................2 1. Introduction...................................................2 2. Key Words......................................................3 3. Terminology....................................................4 4. Requirements...................................................4 4.1. Authentication...............................................4 4.1.1. Authentication of Client...................................4 4.1.2. Authorization, Accounting and Access Control...............5 4.1.3. Authentication Backend.....................................5 4.1.4. Identifiers................................................5 4.2. Network......................................................6 4.2.1. Multi-access...............................................6 4.2.2. Disconnect Indication......................................6 4.2.3. Location of PAA............................................6 4.2.4. Secure Channel.............................................6 4.3. Interaction with Other Protocols.............................6 4.4. Performance..................................................7 4.5. Reliability and Congestion Control...........................7 4.6. Miscellaneous................................................7 4.6.1. IP Version Independence....................................7 4.6.2. Denial of Service Attacks..................................7 4.6.3. Location Privacy...........................................7 Acknowledgements..................................................7 References........................................................8 AuthorsĘ Addresses................................................9 Full Copyright Statement.........................................10 1. Introduction Currently there are a variety of access technologies available to the network clients. While most of the clients currently have single interface, it is expected that in the future they will have multiple interfaces of different types to access the network. An authentication mechanism is needed in order to provide secure network access to the legitimate clients. Some of the current authentication mechanisms are access technology specific. For example 802.1x [8021X] works for only IEEE 802 link layers. If a client can have more than one type of interface, using access- specific authentication mechanisms leads to running a collection of protocols on the client for the same purpose. It is clearly Yegin (Editor), et.al. Expires Sep 2002 [Page 2] Internet Draft PANA Requirements and Terminology Mar 2002 advantageous to use a general protocol to authenticate the client for network access on any type of technology. The most widely used protocol for authenticating clients is the PPP [PPP]. This protocol can run on various access types, but it provides an inherently point-to-point interface. While it can efficiently be applied to such topologies, using PPP with a multi- access network creates sub-optimal solutions. Such multi-access networks require either a full mesh of PPP links among clients, or a designated router as the end-point of PPP links. There is currently no general protocol to be used by a client for gaining network access, and the PANA Working Group will attempt to fill that hole. The Working Group will design a protocol between a client's device and an agent device in the network where the agent might be a client of the AAA infrastructure. As a network-layer protocol, it will be independent of the underlying access technologies. It will also be applicable to any network topology. The protocol design will be limited to defining a messaging protocol (i.e., a carrier) for providing the clients' information to the network for authentication and authorization purposes. The Working Group will not invent new security protocols and mechanisms but instead will use the existing mechanisms. In particular, the Working Group will not define authentication protocols, key distribution or key agreement protocols, or key derivation. The desired protocol can be viewed as the front-end of the AAA protocol or any other protocol/mechanisms the network is running at the background to authenticate its clients. It will act as a carrier for an already defined security protocol or mechanism. As an example, Mobile IP Working Group has already defined such a carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request message is used as the carrier for authentication extensions (MN-FA [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the foreign agents. In that sense, designing the equivalent of Mobile IPv4 registration request messages for general network access is the goal of this work, but not defining the equivalent of MN-FA or MN- AAA extensions. This document defines the common terminology and identifies the requirements of a protocol for PANA. These terminology and requirements will be used to define and limit the scope of the work to be done in this group. 2. Key Words 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]. Yegin (Editor), et.al. Expires Sep 2002 [Page 3] Internet Draft PANA Requirements and Terminology Mar 2002 3. Terminology 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. At most one PANA client should be associated with a DI on a PANA authentication agent. 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 network 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 and grant network access service to the device associated with the client and identified by a DI. 4. Requirements 4.1. Authentication 4.1.1. Authentication of Client PANA MUST authenticate a PaC for network access. A PaC can be identified by the credentials (identifier, authenticator) supplied by one of the users of the device or the device itself. PANA MUST only grant network access service to the device identified by the DI, rather than granting separate access to multiple simultaneous users of the device. Once the network access is granted to the device, the methods used by the device on arbitrating which one of its users can access the network is outside the scope of PANA. PANA MUST NOT define new security protocols or mechanisms. Instead it must be defined as a "carrier" for such protocols. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload"). An example of a carrier would be the registration request message of Mobile IPv4 [MIPV4] that carries MN- FA authentication extension. Authentication and encryption of data traffic sent to and from an authenticated PaC is outside the scope of PANA. Providing a complete Yegin (Editor), et.al. Expires Sep 2002 [Page 4] Internet Draft PANA Requirements and Terminology Mar 2002 secure network access solution by also securing router discovery [RDISC], neighbor discovery [NDISC], and address resolution protocols [ARP] is outside the scope as well. Both the PaC and the PAA MUST be able to authenticate each other for network access. Providing capability of only PAA authenticating the PaC is not sufficient. PANA MUST be capable of carrying out both periodic and on-demand re- authentication. Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process. When the DI is carried explicitly as part of the PANA payload, the authentication computation MUST also include this field to provide integrity protection for the DI. When the DI is carried implicitly as the source of the PANA message, the protocol has to make sure that the DI's integrity is protected by some other means (e.g., physical verification of incoming port number of the PANA message in the case of switch port number as a DI and PAA co-located with the link-layer access device). Protecting PaCs against DI theft is outside the scope of PANA. 4.1.2. Authorization, Accounting and Access Control In addition to carrying authentication information, PANA MUST also carry a binary result (i.e., success or failure) of authorization for network access to the PaC. Providing finer granularity authorization is outside the scope of PANA. Providing access control functionality in the network is outside the scope of PANA. PAA MAY communicate the DI associated with a PaC to other entities in the network to setup access control and accounting state. This interaction is outside the scope of PANA as well. Carrying accounting data is outside the scope of PANA. 4.1.3. Authentication Backend PAA MAY use either a AAA backend, some other mechanism or a local database to authenticate the PaC. PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. The interaction between the PAA and the backend authentication entities is outside the scope of PANA. 4.1.4. Identifiers PANA SHOULD allow various types of identifiers to be used for the PaC (e.g., NAI, IP address, FQDN, etc.) Yegin (Editor), et.al. Expires Sep 2002 [Page 5] Internet Draft PANA Requirements and Terminology Mar 2002 PANA SHOULD allow various types of identifiers to be used as the DI (IP address, link-layer address, port number of a switch, etc.) PAA MUST be able to create a binding between the PaC and the associated DI upon successful PANA exchange. The DI MUST be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. This binding is used for access control and accounting in the network as described in section 4.1.2. 4.2. Network 4.2.1. Multi-access Protocol MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. 4.2.2. Disconnect Indication PANA MUST NOT assume connection-oriented links. Links may or may not provide disconnect indication. PANA SHOULD define a "disconnect" indication to allow PaCs to notify the PAA of their departure from the network. A similar indication SHOULD also be used to let PAA notify a PaC about the discontinuation of the network access. Access discontinuation can happen due to various reasons such as network systems going down, or a change in access policy. 4.2.3. Location of PAA PAA MAY be one or more hop away from the PaC. PANA MUST define a method used by PaCs for locating the PAAs in a network. 4.2.4. Secure Channel PANA MUST not assume a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST provide protection against replay attacks on both PaCs and PAAs. 4.3. Interaction with Other Protocols Mobility management is outside the scope of PANA. Though, PANA MUST be able to co-exist and not interfere with various mobility management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other standard protocols like IPv6 stateless address auto-configuration [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP Yegin (Editor), et.al. Expires Sep 2002 [Page 6] Internet Draft PANA Requirements and Terminology Mar 2002 [DHCP]. It MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC. 4.4. Performance PANA design SHOULD give consideration to efficient handling of authentication process. This is important for gaining network access with minimum latency. As an example, a method like minimizing the protocol signaling by creating local security associations can be used for this purpose. 4.5. Reliability and Congestion Control PANA MUST provide reliability and congestion control. It can do so by using techniques like re-transmissions, cyclic redundancy check, delayed initialization and exponential back-off. 4.6. Miscellaneous 4.6.1. IP Version Independence PANA MUST work for both IPv4 and IPv6. 4.6.2. Denial of Service Attacks PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing that swamp the PAA in spending much resources and prevent legitimate clientsĘ attempts of network access. The required robustness is no worse than that for TCP SYN attack. 4.6.3. Location Privacy Location privacy is outside the scope of PANA. Acknowledgements We would like to thank Basavaraj Patil, Subir Das, and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document. Yegin (Editor), et.al. Expires Sep 2002 [Page 7] Internet Draft PANA Requirements and Terminology Mar 2002 References [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [8021X] "IEEE Standards for Local and Metropolitan Area Networks: Port Based Network Access Control", IEEE Draft 802.1X/D11, March 2001. [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002, October 1996. [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress. [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC3012, November 2000. [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, September 1991. [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)",RFC 2461, December 1998. [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in Mobile IPv4", November 2001. Work in progress. [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile IPv6", July 2001. Work in progress. [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration Protocol for IPv6", December 2001. Work in progress. [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Yegin (Editor), et.al. Expires Sep 2002 [Page 8] Internet Draft PANA Requirements and Terminology Mar 2002 Authors' Addresses Alper E. Yegin DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA, 95110 USA Phone: +1 408 451 4743 Email: alper@docomolabs-usa.com Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ, 07961-0136 USA Phone: +1 973 829 5174 Email: yohba@tari.toshiba.com Reinaldo Penno Nortel Networks 2305 Mission College Boulevard Santa Clara, CA, 95054 USA Phone: +1 408 565 3023 Email: rpenno@nortelnetworks.com George Tsirtsis Flarion Technologies Bedminster One 135 Route 202/206 South Bedminster, NJ, 07921 USA Phone : +44 20 88260073 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com Cliff Wang Smart Pipes 565 Metro Place South Dublin, OH, 43017 USA Phone: +1 614 923 6241 Email: cwang@smartpipes.com Yegin (Editor), et.al. Expires Sep 2002 [Page 9] Internet Draft PANA Requirements and Terminology Mar 2002 Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Yegin (Editor), et.al. Expires Sep 2002 [Page 10]