IETF PANANetwork Working Group Alper E.A. Yegin, Editor INTERNET-DRAFT Yoshihiro OhbaEd. Internet-Draft Samsung AIT Expires: December 2003 Reinaldo9, 2004 Y. Ohba Toshiba R. Penno GeorgeNortel Networks G. Tsirtsis CliffFlarion C. Wang ARO/NCSU June 200310, 2004 Protocol for Carrying Authentication for Network Access (PANA) Requirements draft-ietf-pana-requirements-07.txtdraft-ietf-pana-requirements-08.txt Status of this Memo This document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and isany of which I become aware will be disclosed, in full conformanceaccordance with all provisions of Section 10 of RFC2026.RFC 3668. 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.txthttp://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 December 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. Yegin (Editor), et. al. Expires Dec 2003 [Page 1] Internet Draft PANA Requirements June 2003Table of Contents Abstract..........................................................1 Table of Contents.................................................21. Introduction...................................................3Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Words......................................................4Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Terminology....................................................4Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements...................................................5 4.1. Authentication...............................................5 4.1.1.Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1 Authentication of Client...................................5 4.1.2.Client . . . . . . . . . . . . . . . 6 4.1.2 Authorization, Accounting and Access Control...............6 4.1.3.Control . . . . . 7 4.1.3 Authentication Backend.....................................7 4.1.4. Identifiers................................................7 4.2.Backend . . . . . . . . . . . . . . . . 8 4.1.4 Identifiers . . . . . . . . . . . . . . . . . . . . . 8 4.2 IP Address Assignment........................................7 4.3.Assignment . . . . . . . . . . . . . . . . . . 9 4.3 EAP Lower Layer Requirements.................................8 4.4.Requirements . . . . . . . . . . . . . . . 9 4.4 PAA-to-EP Protocol...........................................8 4.5. Network......................................................9 4.5.1. Multi-access...............................................9 4.5.2.Protocol . . . . . . . . . . . . . . . . . . . . 9 4.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.1 Multi-access . . . . . . . . . . . . . . . . . . . . . 10 4.5.2 Disconnect Indication......................................9 4.5.3.Indication . . . . . . . . . . . . . . . . 10 4.5.3 Location of PAA............................................9 4.5.4.PAA . . . . . . . . . . . . . . . . . . . 10 4.5.4 Secure Channel............................................10 4.6.Channel . . . . . . . . . . . . . . . . . . . . 11 4.6 Interaction with Other Protocols............................10 4.7. Performance.................................................10 4.8.Protocols . . . . . . . . . . . . . 11 4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . 11 4.8 Congestion Control..........................................11 4.9.Control . . . . . . . . . . . . . . . . . . . . 11 4.9 IP Version Independence.....................................11 4.10.Independence . . . . . . . . . . . . . . . . . 12 4.10 Denial of Service Attacks..................................11 4.11.Attacks . . . . . . . . . . . . . . . . 12 4.11 Client Identity Privacy....................................11Privacy . . . . . . . . . . . . . . . . . 12 5. Security Considerations.......................................11IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements..............................................11Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References....................................................12 7.1.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References........................................12 7.2.References . . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References......................................12 8.References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses............................................13 9. Appendix......................................................14 10. FullAddresses . . . . . . . . . . . . . . . . . . . . . . 17 A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statement.....................................16 Yegin (Editor), et.al. Expires Dec 2003 [Page 2] Internet Draft PANA Requirements June 2003Statements . . . . . . . . 24 1. Introduction Providing secureSecure network access service requires access control based on the authentication and authorization of the clients and the access networks. Initial and subsequent client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication parameters between the client and the access network. Link-layer authentication mechanisms are used as enablers of secure network access. A higher-layer authentication protocol is deemed necessary when link-layer authentication mechanisms either do not exist in terms of specifications/standards for a specific technology or present deployment difficulties; when link-layer mechanisms are not able to meet the overall authentication and security requirements; or when multi-layer (e.g., link-layer and network-layer) authentication is needed. Currently there is no standard network-layer solution for authenticating clientsSee Appendix for network access. In the absence of such a solution, some inadequate standards-based solutions are deployed or non-standard ad-hoc solutions are invented. The usage scenarios Internet-Draft [USAGE] describesthe associated problem statement in detail.statement. The protocol design will be limited to defining a messaging protocol (i.e., a carrier) that will allow authentication payload to be carried between the host/client and an agent/server in the access network for authentication and authorization purposes regardless of the AAA infrastructure that may (or may not) reside on the network. As a network-layer protocol, it will be independent of the underlying access technologies. It will also be applicable to any network topology. The intent is not to invent new security protocols and mechanisms but to reuse existing mechanisms such as EAP [EAP].[RFC2284] [I-D.ietf-eap-rfc2284bis]. In particular, the requirements do not mandate the need to define new authentication protocols (e.g., EAP-TLS [EAPTLS]),[RFC2716]), key distribution or key agreement protocols, or key derivation methods. 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, the Mobile IP Working Group has already defined such a carrier for Mobile IPv4 [MIPV4].[RFC3344]. A Mobile IPv4 registration request message is used as a carrier for authentication extensions (MN-FA [MIPv4][RFC3344] or MN-AAA [MNAAA])[RFC3012]) that allow a foreign agent to authenticate mobile nodes before providing forwarding service. The goal of PANA is similar in that it aims to define a network-layer transport for authentication information; however, PANA will be decoupled from mobility management and it will rely on other specifications for the definition of authentication payloads. Yegin (Editor), et.al. Expires Dec 2003 [Page 3] Internet Draft PANA Requirements June 2003This 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 WordsRequirements notation 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].[RFC2119]. 3. Terminology PANA Client (PaC) The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization. PANA Client Identifier (PaCI) The identifier that is presented by the PaC to the PAA for network access authentication. A simple username and NAI [NAI][RFC2794] are examples of PANA client identifiers. 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, this identifier might contain any of IP address, link-layer address, switch port number, etc. of a connected device. PANA Authentication Agent (PAA) The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. Enforcement Point (EP) A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP. Yegin (Editor), et.al. Expires Dec 2003 [Page 4] Internet Draft PANA Requirements June 20034. Requirements 184.108.40.206 Authentication 220.127.116.11.1.1 Authentication of Client PANA MUST enable authentication of PaCs for network access. A PaC's identity can be authenticated by verifying the credentials (e.g., 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"). EAP [EAP]is a candidate protocol that satisfies many of the requirements for authentication. PANA would be a carrier protocol for EAP. If the PANA Working Group decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions. Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer ciphering (e.g., IPsec) can be used to provide such security. These mechanisms require presence of cryptographic keying material at PaC and EP. Although PANA does not deal with key derivation or distribution, it enables this by the virtue of carrying EAP and allowing appropriate EAP method selection. Various EAP methods are capable of generating basic keying material. The keying material produced by EAP methods cannot be directly used with IPsec as it lacks the properties of an IPsec SA (security association) which include secure cipher suite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. These basic (initial) EAP keys can be used with an IPsec key management protocol like IKE to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they are sent between the EP and PaC. Providing a complete secure network access solution by also securing router discovery [RDISC],[RFC1256], neighbor discovery [NDISC],[RFC2461], and address resolution protocols [ARP][RFC1982] is outside the scope as well. Yegin (Editor), et.al. Expires Dec 2003 [Page 5] Internet Draft PANA Requirements June 2003Some access networks might require or allow their clients to get authenticated and authorized by the NAP (network access provider) and ISP before the clients gain network access. NAP is the owner of the access network who provides physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization parameters as a result of two separate authentications is an operational issue and therefore it is outside the scope of PANA. Both the PaC and the PAA MUST be able to perform mutual authentication for network access. Providing only the capability of a PAA authenticating the PaC is not sufficient. Mutual authentication capability is required in some environments but not in all of them. For example, clients might not need to authenticate the access network when physical security is available (e.g., dial-up networks). 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. Certain types of service theft are possible when the DI is not protected during or after the PANA exchange [SECTHREAT].[I-D.ietf-pana-threats-eval]. PANA MUST have the capability to exchange DI securely between the PAC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its utility relies on the use of an authentication method that can generate keys for cryptographic computations on PaC and PAA. 18.104.22.168.1.2 Authorization, Accounting and Access Control After a device is authenticated by using PANA, it MUST be authorized for "network access." That is, the core requirement of PANA is to verify the authorization of a PaC so that PaC's device may send and receive any IP packets. It may also be possible to provide finer granularity authorization, such as authorization for QoS or individual services (e.g., http vs. ssh). However, while a backend authorization infrastructure (e.g., Diameter) might provide such indications to the PAA, explicit support for them is outside the scope of PANA. For instance, PANA is not required to carry any indication of which services are authorized for the authenticated device. Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via the access network. Access control can involve setting access control lists on the EPs. Identification of clients that are authorized to access the network is done by the PANA protocol exchange. If IPsec-based access control Yegin (Editor), et.al. Expires Dec 2003 [Page 6] Internet Draft PANA Requirements June 2003is deployed in an access network, PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs based on EAP keys is outside the scope of PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1). Carrying accounting data is outside the scope of PANA. 22.214.171.124.1.3 Authentication Backend PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. A PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it is not a requirement. When the access network does not rely on an IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use a proprietary backend system, or rely on the information locally stored on the authentication agents. The interaction between the PAA and the backend authentication entities is outside the scope of PANA. 126.96.36.199.1.4 Identifiers PANA SHOULD allow various types of identifiers to be used as the PaCI (e.g., username, NAI, FQDN, etc.). This requirement generally relies on the client identifiers supported by various EAP methods. PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.). A PAA MUST be able to create a binding between the PaCI and the associated DI upon successful PANA exchange. This can be achieved by PANA communicating the PaCI and DI to the PAA during the protocol exchange. The DI can be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. Multi-access networks also require use of a cryptographic protection along with DI filtering to prevent unauthorized access [SECTHREAT].[I-D.ietf-pana-threats-eval]. The keying material required by the cryptographic methods needs to be indexed by the DI. The binding between DI and PaCI is used for access control and accounting in the network as described in section 4.1.2. 188.8.131.52 IP Address Assignment Assigning an IP address to the client is outside the scope of PANA. PANA protocol design MAY require thePaC toMUST configure an IP address before using this protocol. Allocating IP addresses to unauthenticated PaCs may create security vulnerabilities, such as IP Yegin (Editor), et.al. Expires Dec 2003 [Page 7] Internet Draft PANA Requirements June 2003 address depletion attacks on the access network [SECTHREAT]. IPv4 networks with limited address space are the main targets of such attacks. Launching a successful attack that can deplete the addresses in an IPv6 network is relatively harder. This threat can be mitigated by allowing the protocol to run without an IP address configured on the PaC (i.e., using unspecified source address). Such a design choice might limit the re-use of existing security mechanisms, and impose additional implementation complexity. This trade off should be taken into consideration in designingrunning PANA. 184.108.40.206 EAP Lower Layer Requirements The EAP protocol itself imposes various requirements on its transport protocols. These requirements are based on the nature of the EAP protocol, and they need to be satisfied for correct operation. Please see [EAP][I-D.ietf-eap-rfc2284bis] for the generic transport requirements that MUST be satisfied by PANA as well. 220.127.116.11 PAA-to-EP Protocol PANA does not assume that the PAA is always co-located with the EP(s). Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). When the PAA and the EP(s) are separated, there needs to be another transport for client provisioning. This transport is needed to create access control lists to allow authenticated and authorized clients' traffic through the EPs. PANA Working Group will preferably identify an existing protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. Possible candidates include but are not limited to COPS, SNMP, Diameter, etc. This task is similar to what the MIDCOM Working Group is trying to achieve, therefore some of that working group's output might be useful here. It is assumed that the communication between PAA and EP(s) is secure. The objective of using a PAA-to-EP protocol is to provide filtering rules to EP(s) for allowing network access of a recently authenticated and authorized PaC. The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-to-EP protocol exchange per PaC) or the push model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), or both may be required. For example, if the design is such that the EP allows the PANA traffic to pass through even for unauthenticated PaCs, the EP should also allow and expect the PAA to send the filtering information at the Yegin (Editor), et.al. Expires Dec 2003 [Page 8] Internet Draft PANA Requirements June 2003end of a successful PANA exchange without the EP ever sending a request. 18.104.22.168 Network 22.214.171.124.5.1 Multi-access PANA MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST NOT assume the PaC has only one network interface, or the access network has only one first hop router, or the PaC is using a point-to-point link. 126.96.36.199.5.2 Disconnect Indication PANA MUST NOT assume that the link is connection-oriented. Links may or may not provide disconnect indication. Such notification is desirable in order for the PAA to cleanup resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks. This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can happen due to various reasons such as network systems going down, or a change in the access policy. In case the clients cannot send explicit disconnect messages to the PAA, PAA can still detect their departure by relying on periodic authentication requests. 188.8.131.52.5.3 Location of PAA The PAA and PaC MUST be exactly one IP hop away from each other. That is, there must be no IP routers between the two. Note that this does not mean they are on the same physical link. Bridging techniques can place two nodes just exactly one IP hop away from each other although they might be connected to separate physical links. Furthermore, two nodes on the same IP subnet do not necessarily satisfy this requirement, as they can be more than one hop away from each other [MULTILINK].A PAA can be on the NAS (network access server) or WLAN access point or first hop router. The use of PANA when the PAA is multiple IP hops away from the PaC is outside the scope of PANA. Yegin (Editor), et.al. Expires Dec 2003 [Page 9] Internet Draft PANA Requirements June 2003A PaC may or may not be pre-configured with the IP address of PAA. Therefore the PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA. 184.108.40.206.5.4 Secure Channel PANA MUST NOT assume presence of 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 enable protection against replay attacks on both PaCs and PAAs. This requirement partially relies on the EAP protocol and the EAP methods carried over PANA. Use of EAP methods that provide mutual authentication and key derivation/distribution is essential for satisfying this requirement. EAP does not make a secure channel assumption, and supports various authentication methods that can be used in such environments. Additionally, PANA MUST ensure its design does not contain vulnerabilities that can be exploited when it is used over insecure channels. PANA MAY provide a secure channel by deploying a two-phase authentication. The first phase can be used for creation of the secure channel, and the second phase is for client and network authentication. 220.127.116.11 Interaction with Other Protocols Mobility management is outside the scope of PANA. However, PANA MUST be able to co-exist and MUST NOT unintentionally interfere with various mobility management protocols, such as Mobile IPv4 [MIPV4],[RFC3344], Mobile IPv6 [MIPV6],[I-D.ietf-mobileip-ipv6], fast handover protocols [FMIPV4, FMIPV6],[I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff], and other standard protocols like IPv6 stateless address auto-configuration [ADDRCONF][RFC2461] (including privacy extensions [PRIVACY]),[RFC3041]), and DHCP [DHCPV4, DHCPV6].[RFC2131][RFC3315]. It MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC. 18.104.22.168 Performance PANA design SHOULD give consideration to efficient handling of the 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. Yegin (Editor), et.al. Expires Dec 2003 [Page 10] Internet Draft PANA Requirements June 2003 22.214.171.124 Congestion Control PANA MUST provide congestion control for the protocol messaging. Under certain conditions PaCs might unintentionally get synchronized when sending their requests to the PAA (e.g., upon recovering from a power outage on the access network). The network congestion generated from such events can be avoided by using techniques like delayed initialization and exponential back off. 126.96.36.199 IP Version Independence PANA MUST work with both IPv4 and IPv6. 188.8.131.52 Denial of Service Attacks PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing that would swamp the PAA, causing it to spend resources and prevent network access by legitimate clients. 184.108.40.206 Client Identity Privacy Some clients might prefer hiding their identity from visited access networks for privacy reasons. Providing identity protection for clients is outside the scope of PANA. Note that some authentication methods may already have this capability. Where necessary, identity protection can be achieved by letting PANA carry such authentication methods. 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations This document identifies requirements for the PANA protocol design. Due to the nature of this protocol most of the requirements are security related. The actual protocol design is not specified in this document. A thorough discussion on PANA security threats can be found in PANA Threat Analysis and Security Requirements document [SECTHREAT].[I-D.ietf-pana-threats-eval]. Security threats identified in that document are already included in this general PANA requirements document. 6.7. Acknowledgements WeAuthors would like to thank Bernard Aboba, Derek Atkins, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan Forsberg, Francis Dupont, Bernard AbobaHesham Soliman, and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document. Yegin (Editor), et.al. Expires Dec 2003 [Page 11] Internet Draft PANA Requirements June 2003 7.8. References 220.127.116.11 Normative References [KEYWORDS] S.[I-D.ietf-pana-threats-eval] Parthasarathy, M., "PANA Threat Analysis and security requirements", draft-ietf-pana-threats-eval-04 (work in progress), May 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem Statement and Usage Scenarios for PANA", draft-ietf-pana-usage-scenarios-06.txt, April 2003. Work in progress. [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security Requirements", draft-ietf-pana-threats-04.txt, May 2003. Work in progress. [EAP] L.[RFC2284] Blunk, L. and J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, "Extensible"PPP Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-04.txt, June 2003. Work in progress. 7.2.RFC 2284, March 1998. 8.2 Informative References [8021X] "IEEE Standards[I-D.ietf-eap-rfc2284bis] Blunk, L., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004. [I-D.ietf-mipshop-fast-mipv6] Koodli, R., "Fast Handovers for LocalMobile IPv6", draft-ietf-mipshop-fast-mipv6-01 (work in progress), February 2004. [I-D.ietf-mobileip-ipv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. [I-D.ietf-mobileip-lowlatency-handoff] Malki, K., "Low latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in progress), June 2004. [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port BasedPort-Based Network Access Control", IEEE Std 802.1X-2001. [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol",Standard 802.1X, September 2001. [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 2716, October 1999. [MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work in progress. [PPP] W. Simpson (editor),1256, September 1991. [RFC1661] Simpson, W., "The Point-To-PointPoint-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4",[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 3344,1982, August 2002. [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress. [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC3012, November 2000. [NDISC] T.1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2461] Narten, E.T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)",RFC(IPv6)", RFC 2461, December 1998. [ARP][RFC2716] Aboba, B. and D. Plummer, "An Ethernet Address ResolutionSimon, "PPP EAP TLS Authentication Protocol", STD 37,RFC 826, November 1982. Yegin (Editor), et.al. Expires Dec 2003 [Page 12] Internet Draft PANA Requirements June 2003 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in Mobile IPv4", November 2001. Work in progress. [FMIPV6] R. Koodli (editor), et. al., "Fast Handovers2716, October 1999. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for Mobile IPv6", March 2003. Work in progress. [DHCPV4] R. Droms, "Dynamic Host Configuration Protocol",IPv4", RFC 2131,2794, March 1997. [DHCPV6] R. Droms (editor), et. al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",2000. [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2002. Work in progress. [PRIVACY] T.2000. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 8.[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Authors' Addresses Alper E. Yegin DoCoMo USA Labs 181 Metro Drive, Suite 300(editor) Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA, 95110CA 95134 USA Phone: +1 408 451 4743 Email: email@example.com 5656 EMail: firstname.lastname@example.org Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ, 07961-01361 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 973 829 5174 Email:732 699 5305 EMail: email@example.com Reinaldo Penno Nortel Networks 600 Technology Park Billerica, MA,MA 01821 USA Phone: +1 978 288 8011 Email:EMail: firstname.lastname@example.org George Tsirtsis Flarion TechnologiesBedminster One 135 Route 202/206 South Bedminster, NJ,NJ 07921 USA Phone :Phone: +44 20 88260073 E-mail:EMail: G.Tsirtsis@Flarion.com, email@example.com Yegin (Editor), et.al. Expires Dec 2003 [Page 13] Internet Draft PANA Requirements June 2003Cliff Wang Smart Pipes 565 Metro Place South Dublin, OH, 43017ARO/NCSU 316 Riggsbee Farm Morrisville, NC 27560 USA Phone: +1 614 923 6241 Email: firstname.lastname@example.org 9.919 548 4207 EMail: email@example.com Appendix A. PANA Model Following sub-sections capture the PANA usage modelProblem Statement Access networks in different network architectures with reference to its placementmost cases require some form of logical elements such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) with respectauthentication in order to prevent unauthorized usage. In the Enforcement Point (EP) and the Access Router (AR). Four different scenarios are describedabsence of physical security (and sometimes in following sub-sections. Note that PAA may or may not use AAA infrastructureaddition to verifyit) a higher layer (L2+) access authentication mechanism is needed. Depending on the credentialsdeployment scenarios, a number of PaC to authorizefeatures are expected from the authentication mechanism. For example, support for various authentication methods (e.g., MD5, TLS, SIM, etc.), network access. A.1. PAA Co-located withroaming, network service provider discovery and selection, separate authentication for access (L1+L2) service provider and ISP (L3), etc. In the absence of a link-layer authentication mechanism that can satisfy these needs, operators are forced to either use non-standard ad-hoc solutions at layers above the link, insert additional shim layers for authentication, or misuse some of the existing protocols in ways that were not intended by design. PANA will be developed to fill this gap by defining a standard network-layer access authentication protocol. As a network-layer access authentication protocol, PANA can be used over any link-layer that supports IP. DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios therein. Some DSL deployments do not use PPP as the access link-layer (IP is carried over ATM and the subscriber device is either statically- or DHCP-configured). The operators of these networks are either left with using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws. PPP-based authentication can provide some of the required functionality. But using PPP only for authentication is not a good choice, as it incurs additional messaging during the connection setup and extra per-packet processing, and it forces the network topology to a point-to-point model. Aside from resistance to incorporating PPP into an architecture unless it is absolutely necessary, there is even interest in the community to remove PPP from some of the existing architectures and deployments (e.g., 3GPP2, DSL). Using Mobile IPv4 authentication with a foreign agent instead of proper network access authentication is an example of protocol misuse. Registration Required flag allows a foreign agent to force authentication even when the agent is not involved in any Mobile IPv4 signalling (co-located care-of address case), hence enabling the use of a mobility-specific protocol for an unrelated functionality. PANA will carry EAP above IP in order to enable any authentication method on any link-layer. EAP can already be carried by IEEE 802.1X and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, hence it only applies to limited link types. Inserting PPP between IP and a link-layer can be perceived as a way to enable EAP over that particular link-layer, but using PPP for this reason has the aforementioned drawbacks, hence not a good choice. While IEEE 802.1X and PPP can continue to be used in their own domains, they do not take away the need to have a protocol like PANA. Appendix B. Usage Scenarios PANA will be applicable to various types of networks. Based on the presence of lower-layer security prior to running PANA, the following types cover all possibilities: a) Physically secured networks (e.g., DSL networks). Although data traffic is always carried over a physically secured link, the client might need to be authenticated and authorized when accessing the IP services. b) Networks where L1-L2 is already cryptographically secured before enabling IP (e.g., cdma2000 networks). Although the client is authenticated on the radio link before enabling ciphering, it additionally needs to get authenticated and authorized for accessing the IP services. c) No lower-layer security present before enabling IP. PANA is run in an insecure network. PANA-based access authentication is used to bootstrap cryptographic per-packet authentication and integrity protection. PANA is applicable to not only large-scale operator deployments with full AAA infrastructure, but also to small disconnected deployments like home networks and personal area networks. Since PANA enables decoupling AAA from the link-layer procedures, network access authentication does not have to take place during the link establishment. This allows deferring client authentication until the client attempts to access differentiated services (e.g., high bandwidth, unlimited access, etc.) in some deployments. Additionally multiple simultaneous network access sessions over the same link-layer connection can be realized as well. Following scenarios capture the PANA usage model in different network architectures with reference to its placement of logical elements such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) with respect to the Enforcement Point (EP) and the Access Router (AR). Five different scenarios are described in following sub-sections. Note that PAA may or may not use AAA infrastructure to verify the credentials of PaC to authorize network access. Scenario 1: PAA co-located with EP but Separatedseparated from AR In this scenario (Figure 1), PAA is co-located with the enforcement point on which access control is performed. PaCs communicate with the PAA for network access on behalf of a device (D1, D2, etc.). PANA in this case provides a means to transport the authentication parameters from the PaC to PAA. PAA knows how to verify the credentials. After verification, PAA sends back the success or failure response to PaC. However, PANA does not play any explicit role in performing access control except that it provides a hook to access control mechanisms.This might be the case where PAA is co-located with the access point (an IP-capableL2 access device).device (e.g., an IP-capable switch). PaC -----EP/PAA--+ [D1]| +------ AR ----- (AAA) | PaC -----EP/PAA--+ [D2]Figure 1: PAA co-located with EP but separated from AR. Yegin (Editor), et.al. Expires Dec 2003 [Page 14] Internet Draft PANA Requirements June 2003 A.2.Scenario 2: PAA Co-locatedco-located with AR but Separatedseparated from EP Figure 2 describes this model.In this scenario, PAA is not co-located with EPs but it is placed on the AR. Although we have shown only one AR here there could be multiple ARs, one of which is co-located with the PAA. PaC exchanges the same messages with PAA as discussed earlier. The difference here is when the initial authentication for the PaC succeeds, accessAccess control parameters have to be distributed to the respective enforcement points so that the corresponding device on which PaC is authenticated can access to the network. Similar to the earlier case, PANA does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. However, aA separate protocol is needed between PAA and EP to carry access control parameters. PaC ----- EP --+ [D1]| +------ AR/PAA --- (AAA) | PaC ----- EP --+ [D2]Figure 2: PAA co-located with AR but separated from EP. A.3.EP Scenario 3: PAA Co-locatedco-located with EP and AR In this scenario (Figure 3), PAA is co-located with the EP and AR on which access control and routing are performed. PaC exchanges the same messages with PAA and PAA performs similar functionalities as before. PANA in this case also does not play any explicit role in performing access control except that it provides a hook to access control mechanisms. PaC----- EP/PAA/AR--+ [D1]| +-------(AAA) | PaC ----- EP/PAA/AR--+ [D2]Figure 3: PAA co-located with EP and AR. A.4. PAAScenario 4: Separated from EPPAA, EP, and AR Figure 4 represents this model.In this scenario, PAA is neither co-located with EPs nor with ARs. It still resides on the same IP link as ARs. PaC does similar exchanges with PAA as discussed Yegin (Editor), et.al. Expires Dec 2003 [Page 15] Internet Draft PANA Requirements June 2003 earlier. Similar to model in A.2, afterAfter the successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this. PaC ----- EP -----+--- AR ---+ | | PaC ----- EP --- -+ | | | PaC ----- EP -----+--- AR -- + ----(AAA) | +--- PAA Figure 4: PAA, EP and AR separated. Scenario 5: PAA separated from co-located EP and AR In this scenario, EP and AR are co-located with each other bu separated from PAA. PAA still resides on the same IP link as ARs. After the successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this. PaC ----- EP -----+--- AR--------------+--- AR/EP ---+ | | PaC ----- EP --- -+--------------+ | | | PaC ----- EP -----+--- AR--------------+--- AR/EP -- + ----(AAA) | +--- PAA Figure 4:5: PAA separated from EP and AR. 10. Full CopyrightIntellectual Property Statement "Copyright (C)The Internet Society (2003). All Rights Reserved. This document and translationsIETF takes no position regarding the validity or scope of it mayany Intellectual Property Rights or other rights that might be copied and furnishedclaimed to others, and derivative works that comment on or otherwise explain it or assist in itspertain to the implementation may be prepared, copied, published and distributed, in wholeor in part, without restrictionuse of any kind, provided thatthe above copyright notice and this paragraph are included on all such copies and derivative works. However,technology described in this document itself mayor the extent to which any license under such rights might or might not be modified inavailable; nor does it represent that it has made any independent effort to identify any way,such as by removingrights. Information on the copyright notice or referencesprocedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the Internet SocietyIETF Secretariat and any assurances of licenses to be made available, or other Internet organizations, except as needed forthe purposeresult of developing Internet standards in which case the proceduresan attempt made to obtain a general license or permission for copyrights defined inthe Internet Standards process must be followed,use of such proprietary rights by implementers or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will notusers of this specification can be revoked byobtained from the Internet Society orIETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its successorsattention any copyrights, patents or patent applications, or assigns.other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein isare 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 DISCLAIMSDISCLAIM 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 Dec 2003 [Page 16]Copyright Statement Copyright (C) The Internet Society (2004). 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.