PANA Working Group P. Jayaraman Internet-Draft Net.Com Expires: September 4, 2006 R. Lopez Univ. of Murcia Y. Ohba (Ed.) Toshiba M. Parthasarathy Nokia A. Yegin Samsung March 3, 2006 PANA Framework draft-ietf-pana-framework-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract PANA (Protocol for carrying Authentication for Network Access) design Jayaraman, et al. Expires September 4, 2006 [Page 1] Internet-Draft PANA Framework March 2006 provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This document defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and wireless LANs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General PANA Framework . . . . . . . . . . . . . . . . . . . . 6 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 12 6. Data Traffic Protection . . . . . . . . . . . . . . . . . . . 15 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. PAA and EP Locations . . . . . . . . . . . . . . . . . . . 16 7.2. Notification of PaC Presence . . . . . . . . . . . . . . . 17 7.3. Filter Rule Installation . . . . . . . . . . . . . . . . . 18 8. Network Selection . . . . . . . . . . . . . . . . . . . . . . 19 9. Authentication Method Choice . . . . . . . . . . . . . . . . . 21 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. DSL Access Network . . . . . . . . . . . . . . . . . . . . 22 10.1.1. Bridging Mode . . . . . . . . . . . . . . . . . . . . 22 10.1.2. Router Mode . . . . . . . . . . . . . . . . . . . . . 23 10.1.3. PANA and Dynamic ISP Selection . . . . . . . . . . . 24 10.2. Wireless LAN Example . . . . . . . . . . . . . . . . . . . 25 10.2.1. PANA with Bootstrapping IPsec . . . . . . . . . . . . 25 10.2.2. PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 29 10.2.3. Capability Discovery . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 39 Jayaraman, et al. Expires September 4, 2006 [Page 2] Internet-Draft PANA Framework March 2006 1. Introduction PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic network access authentication protocol that runs between a client that wants to gain access to the network and a server on the network side. PANA defines a new EAP [RFC3748] lower layer that uses IP between the protocol end points. The motivation to define such a protocol and the requirements are described in [RFC4058]. Protocol details are documented in [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes use of IPsec for access control following PANA-based authentication. IPsec can be used for per-packet security, but nevertheless it is not the only way to achieve this functionality. Alternatives include reliance on physical security and link-layer ciphering. The server for PANA may or may not be co-located with the entity enforcing the per-packet access control function. When the server for PANA and per-packet access control entities are separate, SNMP [I-D.ietf-pana-snmp] may be used to carry information between the two nodes. PANA design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. PANA is intended to be used in any access network regardless of the underlying security. For example, the network might be physically secured, or secured by means of cryptographic mechanisms after the successful client-network authentication. The server for PANA and per-packet access control entities can be placed on various elements in the access network (e.g., access point, access router, dedicated host). IP address configuration mechanisms vary as well. Static configuration, DHCP [RFC2131], stateless address auto-configuration [RFC2461] are possible mechanisms to choose from. If the client for PANA configures an IPsec tunnel for enabling per-packet security, configuring IP addresses inside the tunnel becomes relevant, for which there are additional choices such as IKE [RFC2409]. This document defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: PANA over DSL (Digital Subscriber Line) networks and WLANs (Wireless LANs). Jayaraman, et al. Expires September 4, 2006 [Page 3] Internet-Draft PANA Framework March 2006 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119]. Jayaraman, et al. Expires September 4, 2006 [Page 4] Internet-Draft PANA Framework March 2006 2. Terminology Pre-PANA address (PRPA) This is an IP address configured on a client for PANA before starting the PANA exchange with a server for PANA. This address may be unconfigured after a post-PANA address is configured. Post-PANA address (POPA) This is an IP address that is optionally configured on a client for PANA after successful authentication. This address may be used for communicating with a server of PANA or any node in the Internet. IPsec Tunnel Inner Address (IPsec-TIA) This is an IP address configured on a client for PANA as the inner address of an IPsec tunnel mode SA (Security Association) established between the client and a per-packet access control element for IPsec-based access control. IPsec Tunnel Outer Address (IPsec-TOA) This is the address configured on a client for PANA as the outer address of an IPsec tunnel mode SA between the client and a per- packet access control element for IPsec-based access control. Secure Association Protocol A protocol that runs between a client for PANA and a per-packet access control element to provide a cryptographic binding between the initial entity authentication (and authorization) exchange to the subsequent exchange of data packets. Examples of secure association protocols include the 4-way handshake in IEEE 802.11i [802.11i], and IKE [RFC2409] in IPsec-based access control. Jayaraman, et al. Expires September 4, 2006 [Page 5] Internet-Draft PANA Framework March 2006 3. General PANA Framework PANA is designed to facilitate authentication and authorization of clients in access networks. PANA is an EAP [RFC3748] lower-layer that carries EAP authentication methods encapsulated inside EAP between a client node and an agent in the access network. While PANA enables the authentication process between the two entities, it is only a part of an overall AAA (Authentication Authorization and Accounting) and access control framework. A AAA and access control framework using PANA is comprised of four functional entities. Figure 1 illustrates these functional entities and the interfaces (protocols, APIs) among them. Note that PANA will not define API. RADIUS/ Diameter/ +-----+ PANA +-----+ LDAP/ API +-----+ | PaC |<----------------->| PAA |<---------------->| AS | +-----+ +-----+ +-----+ ^ ^ | | | +-----+ | IKE/ +-------->| EP |<--------+ SNMP/ API 4-way handshake +-----+ Figure 1: PANA Functional Model PANA Client (PaC): The PaC is the client implementation of PANA. This entity resides on the node that is requesting network access. PaCs can be end hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers that are connected to a network via a wired or wireless interface. A PaC is responsible for requesting network access and engaging in the authentication process using PANA. PANA Authentication Agent (PAA): The PAA is the server implementation of PANA. A PAA is in charge of interfacing with the PaCs for authenticating and authorizing them for the network access service. The PAA consults an authentication server in order to verify the credentials and rights of a PaC. If the authentication server resides on the same node as the PAA, an API is sufficient for this interaction. When they are separated (a much more common case in public access networks), a protocol needs to run between the two. AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are Jayaraman, et al. Expires September 4, 2006 [Page 6] Internet-Draft PANA Framework March 2006 commonly used for this purpose. The PAA is also responsible for updating the access control state (i.e., filters) depending on the creation and deletion of the authorization state. The PAA communicates the updated state to the Enforcement Points in the network. If the PAA and EP are residing on the same node, an API is sufficient for this communication. Otherwise, a protocol is required to carry the authorized client attributes from the PAA to the EP. While not prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] is suggested for this task. The PAA resides on a node that is typically called a NAS (network access server) in the access network. For example on a BRAS (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN (Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may be one or more IP hops away from the PaCs. Authentication Server (AS): The server implementation that is in charge of verifying the credentials of a PaC that is requesting the network access service. The AS receives requests from the PAA on behalf of the PaCs, and responds with the result of verification together with the authorization parameters (e.g., allowed bandwidth, IP configuration, etc). This is the server that terminates the EAP and the EAP methods. The AS might be hosted on the same node as the PAA, on a dedicated node on the access network, or on a central server somewhere in the Internet. Enforcement Point (EP): The access control implementation that is in charge of allowing access (data traffic) of authorized clients while preventing access by others. An EP learns the attributes of the authorized clients from the PAA. The EP uses non-cryptographic or cryptographic filters to selectively allow and discard data packets. These filters may be applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic access control is used, a secure association protocol needs to run between the PaC and EP. After completion of the secure association protocol, link or network layer per-packet security (for example TKIP, IPsec ESP) is enabled for integrity protection, data origin authentication, replay protection and optionally confidentiality protection. Jayaraman, et al. Expires September 4, 2006 [Page 7] Internet-Draft PANA Framework March 2006 An EP must be located strategically in a local area network to minimize the access of unauthorized clients to the network. For example, the EP can be hosted on the switch that is directly connected to the clients in a wired network. That way the EP can drop unauthorized packets before they reach any other client node or beyond the local area network. Some of the entities may be co-located depending on the deployment scenario. For example, the PAA and EP would be on the same node (BRAS) in DSL networks. In that case a simple API is sufficient between the PAA and EP. In small enterprise deployments the PAA and AS may be hosted on the same node (access router) that eliminates the need for a protocol run between the two. The decision to co-locate these entities or otherwise, and their precise location in the network topology are deployment decisions that are out of the scope of this document. Use of IKE or IEEE 802.11i 4-way handshake protocols for secure association is only required in the absence of any lower-layer security prior to running PANA. Physically secured networks (e.g., DSL) or the networks that are already cryptographically secured on the link-layer prior to PANA run (e.g., cdma2000) do not require additional secure association and per-packet security. These networks can bind the PANA authentication and authorization to the lower-layer secure channel that is already available. Figure 2 illustrates the signaling flow for authorizing a client for network access. PaC EP PAA AS | | | | IP address ->| | | | config. | PANA | | AAA | |<------------------------------>|<-------------->| | | SNMP | | (Optional) | |<-------------->| | IP address ->| | | | reconfig. | Sec.Assoc. | | | |<------------->| | | | | | | | Data traffic | | | |<-----------------> | | | | | | Figure 2: PANA Signaling Flow The EP on the access network allows general data traffic from any authorized PaC, whereas it allows only limited type of traffic (e.g., Jayaraman, et al. Expires September 4, 2006 [Page 8] Internet-Draft PANA Framework March 2006 PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This ensures that the newly attached clients have the minimum access service to engage in PANA and get authorized for the unlimited service. The PaC MUST dynamically or statically configure an IP address prior to running PANA. After the successful PANA authentication, depending on the deployment scenario the PaC MAY need to re-configure its IP address or configure additional IP address(es). The additional address configuration MAY be executed as part of the secure association protocol run (e.g., via IKE). If this additional IP address configuration happens in the middle of an application protocol run, an appropriate procedure for changing an IP address will need to be taken so that the IP address change is transparent to the application protocol. An initially unauthorized PaC starts the PANA authentication by discovering the PAA, followed by the EAP exchange over PANA. The PAA interacts with the AS during this process. Upon receiving the authentication and authorization result from the AS, the PAA informs the PaC about the result of its network access request. If the PaC is authorized to gain the access to the network, the PAA also sends the PaC-specific attributes (e.g., IP address, cryptographic keys, etc.) to the EP by using another protocol (e.g., SNMP). The EP uses this information to alter its filters for allowing data traffic from and to the PaC to pass through. In case cryptographic access control needs to be enabled after the PANA authentication, a secure association protocol runs between the PaC and the EP. The PaC should already have the input parameters to this process as a result of the successful PANA exchange. Similarly, the EP should have obtained them from the PAA during the service provisioning. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per-packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP. Finally, filters that are installed at the EP allow general purpose data traffic to flow between the PaC and the intranet/Internet. Jayaraman, et al. Expires September 4, 2006 [Page 9] Internet-Draft PANA Framework March 2006 4. Environments PANA can be used on any network environment whether there is a lower- layer secure channel prior to PANA, or one has to be enabled upon successful PANA authentication. With regard to network access authentication two types of networks need to be considered: a. Networks where a secure channel is already available prior to running PANA This type of network is characterized by the existence of protection against spoofing and eavesdropping. Nevertheless, user authentication and authorization is required for network connectivity. One example is a DSL network where the lower-layer security is provided by physical means (a.1). Physical protection of the network wiring ensures that practically there is only one client that can send and receive IP packets on the link. Another example is a cdma2000 network where the lower-layer security is provided by means of cryptographic protection (a.2). By the time the client requests access to the network-layer services, it is already authenticated and authorized for accessing the radio channel, and link-layer ciphering is enabled. The presence of a secure channel before PANA exchange eliminates the need for executing a secure association protocol after PANA. The PANA session can be bound to the communication channel it was carried over. Also, the choice of EAP authentication method depends on the presence of this security during PANA run. For example, weak authentication methods, such as EAP-MD5, may be used for such networks but not for the others. b. Networks where a secure channel is created after running PANA These are the networks where there is no lower-layer protection prior to running PANA. A successful PANA authentication enables generation of cryptographic keys that are used with a secure association protocol to enable per-packet cryptographic protection. PANA authentication is run on an insecure channel that is vulnerable to eavesdropping and spoofing. The choice of EAP method must be resilient to the possible attacks associated with such an environment. Furthermore, the EAP method must be able to create cryptographic keys that will later be used by the secure Jayaraman, et al. Expires September 4, 2006 [Page 10] Internet-Draft PANA Framework March 2006 association protocol. Whether to use a link-layer per-packet security (b.1) or a network layer security (b.2) is a deployment decision and outside the scope of this document. This decision also dictates the choice of the secure association protocol. If link-layer protection is used, the protocol would be link-layer specific. If IP-layer protection is used, the secure association protocol would be IKE and the per-packet security would be provided by IPsec AH/ESP regardless of the underlying link-layer technology. Jayaraman, et al. Expires September 4, 2006 [Page 11] Internet-Draft PANA Framework March 2006 5. IP Address Configuration The PaC configures an IP address before the PANA exchange begins. This address is called a pre-PANA address (PRPA). After a successful authentication, the client may have to configure a post-PANA address (POPA) for communication with other nodes, if the PRPA is a local-use (e.g., a link-local or private address) or a temporarily allocated IP address. An operator might choose allocating a POPA only after successful PANA authorization either to prevent waste of premium (e.g., globally routable) IP resources until the client is authorized, or to enable client identity based address assignment. There are different methods by which a PRPA can be configured. 1. In some deployments (e.g., DSL networks) the PaC may be statically configured with an IP address. This address SHOULD be used as a PRPA. 2. In IPv4, some clients attempt to configure an address dynamically using DHCP [RFC2131]. If they are unable to configure an address using DHCP, they can configure a link-local address using [RFC3927]. When the network access provider is able to run a DHCP server on the access link, the client would configure the PRPA using DHCP. This address may be from a private address pool [RFC1918]. Also, the lease time on the address may vary. For example, a PRPA configured solely for running PANA can have a short lease time. The PRPA may be used for local-use only (i.e., only for on-link communication, such as for PANA and IPsec tunneling with EP), or also for ultimate end-to-end data communication. In case there is no running DHCP server on the link, the client would fall back to configuring a PRPA via zeroconfiguration technique [RFC3927]. This yields a long-term address that can only be used for on-link communication. (Note: At time of this writing, the zeroconfiguration technique is not widely implemented in routers.) 3. In IPv6, clients automatically configure a link-local address [RFC2462] when they initialize an interface. Additionally, they may also configure global address(es) when DHCP or router advertisements with global prefixes are made available to the them. In case PAA is not on the same IP subnet as the PaCs are, the deployment must ensure that a non-link-local PRPA is configurable by the clients. Jayaraman, et al. Expires September 4, 2006 [Page 12] Internet-Draft PANA Framework March 2006 When a PRPA is configured, the client starts the PANA exchange. By that time, a dual stacked client might have configured both an IPv4 address and an IPv6 address as PRPAs. Regardless of whether the PaC has both IPv4 and IPv6 PRPAs or only one of those, only one PANA run is required. A dual-stack device that implements PaC or PAA MUST be able to run PANA over both IPv4 and IPv6. When a dual-stack PaC or PAA initiates PANA authentication, it chooses either IPv4 or IPv6 where the choice is made depending on the deployment. A dual-stack PaC or PAA that is initiated PANA authentication by its peer MUST use the same IP version that the peer is using. When the client successfully authenticates to the network, it may be required to configure POPAs for its subsequent data communication with the other nodes. If the client is already configured with an address that can be used with data communication, it is not required to configure a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to indicate the available configuration methods to the PaC. The PaC can choose one of the methods and act accordingly. 1. If the network relies on physical or link layer security, the PaC can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6 stateless auto-configuration [RFC2461]. An IPv4 PRPA SHOULD be unconfigured when the POPA is configured to prevent IPv4 address selection problem [RFC3927]. If IPv6 is used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484]. If the PaC is a dual-stacked node, it can configure both IPv4 and IPv6 type POPAs. The available POPA configuration methods are indicated within PANA. 2. If the network uses IPsec for protecting the traffic on the link subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC would use the PRPA as the outer address of IPsec tunnel mode SA (IPsec-TOA). The PaC also needs to configure an inner address (IPsec-TIA). There are different ways to configure an IPsec-TIA which are indicated in a PANA-Bind-Request message. When an IPv4 PRPA is configured, the same address may be used as both IPsec-TOA and IPsec-TIA. In this case, a POPA is not configured. Alternatively, an IPsec-TIA can be obtained via the configuration method available within [RFC3456] for IPv4, [RFC4307] for both IPv4 and IPv6. This newly configured address constitutes a POPA. Please refer to [I-D.ietf-pana-ipsec] for more details. Jayaraman, et al. Expires September 4, 2006 [Page 13] Internet-Draft PANA Framework March 2006 IKEv2 [RFC4307] can enable configuration of one IPv4 IPsec-TIA and one IPv6 IPsec-TIA for the same IPsec tunnel mode SA. Therefore, IKEv2 is recommended for handling dual-stacked PaCs where single execution of PANA and IKE is desired. In this case, the same IP version that has been used for PANA is used for IKE, and the IKE entity on the dual-stack PaC will request one or both of IPv4 and IPv6 IPsec-TIAs from the IKE entity on the EP and obtain the one(s) that is(are) available on the EP. Although there are potentially a number of different ways to configure a PRPA, and POPA when necessary, it should be noted that the ultimate decision to use one or more of these in a deployment depends on the operator. The decision is dictated by the operator's choice of per-packet protection capability (physical and link-layer vs network-layer), PRPA type (local and temporary vs global and long- term), and POPA configuration mechanisms available in the network. Jayaraman, et al. Expires September 4, 2006 [Page 14] Internet-Draft PANA Framework March 2006 6. Data Traffic Protection Protecting data traffic of authenticated and authorized client from others is another component of providing a complete secure network access solution. Authentication, integrity and replay protection of data packets is needed to prevent spoofing when the underlying network is not physically secured. Encryption is needed when eavesdropping is a concern in the network. When the network is physically secured, or the link-layer ciphering is already enabled prior to PANA, data traffic protection is already in place. In other cases, enabling link-layer ciphering or network- layer ciphering might rely on PANA authentication. The user and network have to make sure that an appropriate EAP method which generates keying materials is used. Once the keying material is available, it needs to be provided to the EP(s) for use with data traffic protection. Network-layer protection, i.e., IPsec, can be used when data traffic protection is required but link-layer protection is not available. Note that the keying material generated by an EAP method is insufficient to be used alone by IPsec AH/ESP or most link layer mechanisms. In addition to the fresh and unique session key derived from the EAP method, IPsec also needs both traffic selectors and other IPsec SA parameters are missing. The shared secret can be used in conjunction with a key management protocol like IKE [RFC2409] to turn a session key into the required IPsec SA. The details of such a mechanism is outside the scope of PANA and is specified in [I-D.ietf- pana-ipsec]. PANA provides bootstrapping functionality for such a mechanism by carrying EAP methods that can generate initial keying material. Using network-layer ciphers should be regarded as a substitute for link-layer ciphers when the latter is not available. Network-layer ciphering can also be used in addition to link-layer ciphering if the added benefits outweigh its cost to the user and the network. In this case, PANA bootstraps only the network-layer ciphering; link- layer ciphering is enabled using any of the existing link-layer specific methods. Jayaraman, et al. Expires September 4, 2006 [Page 15] Internet-Draft PANA Framework March 2006 7. PAA-EP Protocol PANA provides client authentication and authorization functionality for securing network access. The other component of a complete solution is the access control which ensures that only authenticated and authorized clients can gain access to the network. PANA enables access control by distinguishing authenticated and authorized clients from others and generating filtering information for access control mechanisms. Access control can be achieved by placing EPs (Enforcement Points) in the network for policing the traffic flow. EPs should prevent data traffic from and to any unauthorized client unless it's either PANA or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor discovery, DHCP, etc.). When a PaC is authenticated and authorized, the PAA should notify EP(s) and ask for installing filtering rules to allow the PaC to send and receive data traffic. When the PAA and EP(s) are not co-located, they MUST implement SNMP [I-D.ietf-pana-snmp] for the PAA-EP communication. They MAY optionally implement and use other standard or proprietary protocols as well. This section describes the possible models on the location of PAA and EP, as well as the basic authorization information that needs to be exchanged between PAA and EP. When PAA and EP are not co-located in a single device, there are other issues such as dead or rebooted peer detection and consideration for specific authorization and accounting models. However, these issues are closely related to the PAA-EP protocol solution and thus not discussed in this document. See [I-D.ietf-pana-snmp] for further discussion. 7.1. PAA and EP Locations EPs' location in the network topology should be appropriate for performing access control functionality. When the access control is performed at link-layer, an IP-capable access device on the same link as the client devices is the logical choice. When IPsec-based or non-cryptographic access control mechanisms are used, the EPs' location can range from the first-hop router to other routers within the access network. The first-hop router may be preferred in order to limit the access of unauthorized IP traffic. PAA and EPs should be aware of each other as this is necessary for access control. Generally this can be achieved by manual configuration. Dynamic discovery is another possibility, but this is left to implementations and outside the scope of this document. Jayaraman, et al. Expires September 4, 2006 [Page 16] Internet-Draft PANA Framework March 2006 Since PANA allows the separation of EP and PAA, there are several models depending on the number of EPs and PAAs and their locations. In the simplest model, the PAA and EP are co-located on the same device. In this model, the PAA-EP communication is implemented locally by using an API. When there are multiple such co-located devices in the same IP subnet, only the PAA co-locating with the EP that is closest to the PaC among all EPs in the same subnet needs to be discovered by the PaC in order to perform per-packet access control appropriately. To achieve this, each PAA/EP device on an link-layer switch or access point MUST NOT forward multicast PANA discovery message sent by PaCs attached to it to other devices. This model is suitable for an access network with a small number of EPs. In the other model, the PAA and EP are separated into multiple devices and they communicate using a PAA-EP protocol such as SNMP. A typical scenario is that a single PAA controls multiple EPs (Figure 3). While this model is complex compared to the first model, it is particularly useful in an access network with a large number of EPs because it eliminates EAP messaging when the PaC switches from one EP to another in the same access network without inter-PAA communications. In a more complex scenario, the single PAA may be replaced with multiple PAAs to avoid a single point of failure. Those PAAs may or may not be co-located with EPs. +---+ |EP |--+ +---+ \ \ +---+ +---+ +---+ |PaC| |EP |----|PAA| +---+ +---+ +---+ / +---+ / |EP |--+ +---+ Figure 3: An example model for a single PAA and multiple EPs 7.2. Notification of PaC Presence When PAA and EP are separated and PAA is configured to be the initiator of the discovery and initial handshake phase of PANA, EP has the responsibility to detect presence of a new PaC and notifies the PAA(s) of the presence [RFC4058]. Such a presence notification is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp]. Jayaraman, et al. Expires September 4, 2006 [Page 17] Internet-Draft PANA Framework March 2006 7.3. Filter Rule Installation Filtering rules to be installed on EP generally include a device identifier of PaC, and also cryptographic keying material (e.g., IKE pre-shared key [RFC2409]) when cryptographic data traffic protection is needed (See Section 6). Each keying material is uniquely identified with a keying material name (e.g., ID_KEY_ID in IKE [RFC2409]) and has a lifetime for key management, accounting, access control and security reasons in general. In addition to the device identifier and keying material, other filter rules, such as the IP filter rules specified in NAS-Filter-Rule AVPs carried in Diameter EAP application [RFC4072] may be installed on EP. When IPsec is used the filter rules are applied to IP packets carried inside the IPsec tunnel, otherwise, the filter rules are applied to IP packets that are not protected with IPsec. Jayaraman, et al. Expires September 4, 2006 [Page 18] Internet-Draft PANA Framework March 2006 8. Network Selection The network selection problem statement is made in [I-D.ietf-eap- netsel-problem]. PANA [I-D.ietf-pana-pana] provides a way for networks to advertise which ISPs are available and for a PaC to choose one ISP from the advertised information. When the PaC chooses an ISP in the PANA exchange, the ultimate destination of the AAA exchange is determined based on the identity of the chosen service provider. It is also possible that the PaC does not choose a specific ISP in the PANA exchange. In this case, both the ISP choice and the AAA destination are determined based on the PaC's identity, where the identifier may be an NAI [RFC2486] or the physical port number or link-layer address of the subscriber. As described in [I-D.ietf-eap-netsel-problem], network selection is not only related to AAA routing but also related to payload routing. Once an ISP is chosen and the PaC is successfully authenticated and authorized, the PaC is assigned an address by the ISP. Consider a typical DSL network where the AR (access router), EP, and PAA are co-located on a BRAS in the access network operated by a NAP (Network Access Provider). Figure 4 shows a typical model for ISP selection. <---- NAP ----><--------- ISP ---------> +---ISP1 / +---+ +---------+/ |PaC|----|AR/EP/PAA| +---+ +---------+\ BRAS \ +---ISP2 Figure 4: A Network Selection Model When network selection is made at network-layer with the use of PANA instead of link-layer specific authentication mechanisms, the IP link between the PaC and PAA needs to exist prior to doing PANA (and prior to network selection). In this model, the PRPA is either given by the NAP or a link-local address is auto-configured. After the successful authentication with the ISP, the PaC may acquire an address (POPA) from the ISP. It also learns the address of the access router (AR), e.g., through DHCP, to be used as its default router. The address of the AR may or may not be in the same IP subnet as that of the PaC's POPA. Note that the physically secured DSL networks do not require IPsec-based access control. Therefore the PaC uses one IP address at a time where the POPA replaces the Jayaraman, et al. Expires September 4, 2006 [Page 19] Internet-Draft PANA Framework March 2006 PRPA upon configuration. Jayaraman, et al. Expires September 4, 2006 [Page 20] Internet-Draft PANA Framework March 2006 9. Authentication Method Choice Authentication methods' capabilities and therefore applicability to various environments differ among them. Not all methods provide support for mutual authentication, key derivation or distribution, and DoS attack resiliency that are necessary for operating in insecure networks. Such networks might be susceptible to eavesdropping and spoofing, therefore a stronger authentication method needs to be used to prevent attacks on the client and the network. The authentication method choice is a function of the underlying security of the network (e.g., physically secured, shared link, etc.). It is the responsibility of the user and the network operator to pick the right method for authentication. PANA carries EAP regardless of the EAP method used. It is outside the scope of PANA to mandate, recommend, or limit use of any authentication methods. PANA cannot increase the strength of a weak authentication method to make it suitable for an insecure environment. PANA can carry these EAP encapsulating methods but it does not concern itself with how they achieve protection for the weak methods (i.e., their EAP method payloads). Jayaraman, et al. Expires September 4, 2006 [Page 21] Internet-Draft PANA Framework March 2006 10. Example Cases 10.1. DSL Access Network In a DSL access network, PANA is seen applicable in the following scenarios. A typical DSL access consists of an access router (BRAS -- Broadband Remote Access Server) [DSL] in the DSL access provider network, and a bridge/router (DSL Modem/Routing Gateway) in the customer premises network (CPN) that is in charge of connecting the CPN to the DSL network. The DSL Modem/RG supports multiple modes of operation and PANA is applicable in each of these modes. In the current DSL deployment, a DSLAM (DSL Access Multiplexor) which is placed between the DSL Modem/RG and the BRAS is a transparent device from PANA perspective. In a future DSL model, the PAA may reside in the DSLAM which may directly connect ISP routers through VLANs. Host--+ +-- ISP1 | DSL link | +-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2 | | Host--+ +-- ISP3 <-------- CPN --------> <------ NAP ------> <-- ISP --> Figure 5: DSL Model The devices at the customer premises have been shown as "hosts" in the above network. DSL networks are protected by physical means. Eavesdropping and spoofing attacks are prevented by keeping the unintended users physically away from the network media. Therefore, generally cryptographic protection of data traffic is not common. Nevertheless, if enhanced security is deemed necessary for any reason, IPsec-based access control can be enabled on DSL networks as well by using the method described in [I-D.ietf-pana-ipsec]. 10.1.1. Bridging Mode In the bridging mode, the DSL Modem/RG acts as a simple link-layer bridge. The hosts in the CPN will function as clients to obtain addresses from the BRAS by using DHCP or PPPoE. If PPPoE is used, authentication is typically performed using CHAP or Jayaraman, et al. Expires September 4, 2006 [Page 22] Internet-Draft PANA Framework March 2006 MS-CHAP. PANA will be applicable when the hosts use DHCP to obtain an IP address. DHCP does not support authentication of the devices on either side of the DSL access line. In the simplest method of address assignment, the BRAS will allocate the IP address to a host with a lease time reasonably sufficient to complete a full PANA based authentication which will be triggered immediately after the address assignment. The hosts will perform the PaC function and the BRAS will perform the PAA, EP and AR functions. Host--+ (PaC) | +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP | (Bridge) (PAA,EP,AR) Host--+ (PaC) Figure 6: Bridge Mode The DSL service provider's trunk network should not be accessible to any host that has not successfully completed the PANA authentication phase. 10.1.2. Router Mode In this mode, the DSL Modem/RG acts as a router for the CPN. The DSL Modem/RG itself may obtain the IP address using DHCP or be configured with a static IP address. Once the DSL Modem/RG is authenticated using PANA and is provided access to the service provider's network, the BRAS should begin exchanging routing updates with the DSL Modem/RG. All devices at the customer premises will then have access to the service provider's network. Host--+ | +-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP | (Router, PaC) (PAA,EP,AR) Host--+ Figure 7: Router Mode It is possible that both ends of the DSL link are configured with static IP addresses. PANA-based mutual authentication of PaC and PAA is desirable before data traffic is exchanged between the CPN and the service provider network. The DSL Modem/RG may also use NAPT (Network Address Port Translation). Jayaraman, et al. Expires September 4, 2006 [Page 23] Internet-Draft PANA Framework March 2006 10.1.3. PANA and Dynamic ISP Selection In some installations, a BRAS is shared by multiple service providers. Each service provider configures the BRAS with a certain IP address space. The devices at the customer premises network indicate their choice of service provider and the BRAS chooses the IP address from the appropriate service provider's pool. In many cases, the address is assigned not by the BRAS but by the AAA server that is managed fully by the service provider. This simplifies the management of the DSL access network as it is not always necessary to configure each DSL access line with the service provider's identity. The service provider is chosen dynamically by the DSL Modem/RG. This is typically known as "dynamic Internet Service Provider selection". The AAA function is usually overloaded to perform dynamic ISP selection. 10.1.3.1. Selection as Part of the DHCP protocol or an Attribute of DSL Access Line The ISP selection, therefore the IP address pool, can be conveyed based on the DHCP protocol exchange using, e.g., the 'client-id' field of a DHCP packet, or by associating the DSL access line to the service provider before the PANA authentication begins. When any of these schemes is used, the IP address used during PANA authentication (PRPA) is the ultimate IP address and it does not have to be changed upon successful authorization. 10.1.3.2. Selection as Part of the PANA Authentication The ISP selection of the client can be explicitly conveyed during the PANA authentication (see "Network Selection" in [I-D.ietf-pana- pana]). In that case, the client can be assigned a temporary IP address (PRPA) prior to PANA authentication. This IP address might be obtained via DHCP with a lease reasonably long to complete PANA authentication, or via the zeroconf technique [RFC3927]. In either case, successful PANA authentication signalling prompts the client to obtain a new (long term) IP address via DHCP. This new IP address (POPA) replaces the previously allocated temporary IP address. The devices at the customer premises have been shown as "hosts" in the above network. The document specifically describes the use of PANA in non-PPP-based DSL deployments. These are the deployments that lack a standard network access authentication protocol between the customer premise Jayaraman, et al. Expires September 4, 2006 [Page 24] Internet-Draft PANA Framework March 2006 and the NAP. 10.2. Wireless LAN Example This section describes how PANA can be used on WLANs. PANA may bootstrap either link-layer or IP-layer security. IP-layer security uses IPsec-based data traffic protection, bootstrapped by PANA. When IP-layer security is used, link-layer security is not necessary. The PAA indicates to the PaC whether IP-layer or link-layer protection is necessary via the Protection-Capability AVP in a PANA-Bind-Request message. The most common deployment cases are expected to be (1) a co-located EP and Access Point (AP) bootstrapping link-layer security, or (2) an Access Router (AR) co-located with a PAA (and perhaps an EP) bootstrapping IP-layer security. These cases are depicted together in Figure 8. +-----+ |AP/EP|----+ +-----+ | | +---+ +-----+ | +---------+ |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet +---+ +-----+ | +---------+ | +-----+ | |AP/EP|----+ +-----+ Figure 8: PANA Wireless LAN Model 10.2.1. PANA with Bootstrapping IPsec In this model, data traffic is protected by using IPsec tunnel mode SA and an IP address is used as the device identifier of the PaC (see Section 5 for details). Some or all of AP, DHCPv4 Server (including PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA and EP may be co-located in a single device. EP is always co-located with AR and may be co-located with PAA. When EP and PAA are not co- located, PAA-EP protocol is used for communication between PAA and EP. Note that for all of the cases described in this section, a PBR (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA [I-D.ietf-pana-pana] should occur after installing the authorization parameter to the AR, so that IKE can be performed immediately after the PANA authentication is successfully completed. The PAA can obtain the required device identifier (i.e., the IPsec-TOA in this case) to be installed on the AR from the IP header of a PANA message Jayaraman, et al. Expires September 4, 2006 [Page 25] Internet-Draft PANA Framework March 2006 sent by the PaC before sending the PBR. However, when the PBR/PBA exchange fails, the authorization parameters already installed on the AR must be immediately revoked to avoid unauthorized access. 10.2.1.1. IPv4 Case A: IPsec-TIA obtained by using DHCPv4 In this case, the IPsec-TIA and IPsec-TOA are the same as the PRPA, and all configuration information including the IP address is obtained by using DHCPv4 [RFC2131]. No POPA is configured. Case A is the simplest compared to other ones and might be used in a network where IP address depletion attack on DHCP is not a significant concern. The PRPA needs to be a routable address unless NAT is performed on AR. PaC AP DHCPv4 Server PAA EP(AR) | Link-layer | | | | | association| | | | |<---------->| | | | | | | | | | DHCPv4 | | | |<-----------+------------>| | | | | | | |PANA(Discovery and handshake phase | | | & PAR/PAN exchange in authentication | | and authorization phase) | | |<-----------+-------------------------->| | | | | | | | |Authorization| | | |[IKE-PSK, | | | | PaC-DI, | | | | Session-Id] | | | |------------>| | | | | |PANA(PBR/PBA exchange in | | | authentication and authorization phase) | |<-----------+-------------------------->| | | | | | | | IKE | | |<-----------+---------------------------------------->| | | | | Figure 9: An example case for configuring IPsec-TIA by using DHCPv4 Jayaraman, et al. Expires September 4, 2006 [Page 26] Internet-Draft PANA Framework March 2006 Case B: IPsec-TIA obtained by using IKE Like Case A, the PRPA is obtained by using DHCPv4 and used as the IPsec-TOA. The difference is that the POPA is obtained by using IKE (via a Configuration Payload exchange or equivalent) and used as the IPsec-TIA. Case C: IPsec-TIA obtained by using RFC3456 Like Case B, the PRPA is obtained by using DHCPv4. The difference is that the POPA (eventually used as IPsec-TIA) and other configuration parameter are configured by running DHCPv4 over a special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server may be co-located on the same node. Note: this case may be used only when IKEv1 is used as the IPsec key management protocol (IKEv2 [RFC4307] does not seem to support [RFC3456] equivalent case). Jayaraman, et al. Expires September 4, 2006 [Page 27] Internet-Draft PANA Framework March 2006 PaC AP DHCPv4 Server PAA | Link-layer | | | | association| | | |<---------->| | | | | | | | DHCPv4 | | |<-----------+-------->| | | | | |PANA(Discovery and handshake phase | | & PAR/PAN exchange in | | authentication and authorization phase) |<-----------+-------------------------->| | | | | | | EP(AR) | | | |Authorization | | | |[IKE-PSK, | | | | PaC-DI, | | | | Session-Id] | | |----------->| | | | | |PANA(PBR/PBA exchange in authentication | | | and authorization phase) | | |<-----------+-------------------------->| | | | | | | IKEv1 phase I & II | | (to create DHCP SA) | |<-----------+--------------------------------------->| | | | | DHCP over DHCP SA | |<-----------+--------------------------------------->| | | | | IKEv1 phase II | | (to create IPsec SA for data traffic) | |<-----------+--------------------------------------->| Figure 10: An example case for configuring IPsec-TIA by using RFC3456 10.2.1.2. IPv6 IPsec-TIA (POPA) is obtained by using IKE (via a Configuration Payload exchange or equivalent). Other configuration information may be obtained in the same Configuration Payload exchange or may be obtained by running an additional DHCPv6. Jayaraman, et al. Expires September 4, 2006 [Page 28] Internet-Draft PANA Framework March 2006 PaC AP PAA EP(AR) | Link-layer | | | | association| | | |<---------->| | | | | | | | | | | |PANA(Discovery and handshake phase | | & PAR/PAN exchange in | | authentication and authorization phase) |<-----------+------------>| | | | | | | | | | | | |Authorization| | | |[IKE-PSK, | | | | PaC-DI, | | | | Session-Id] | | | |------------>| | | | | |PANA(PBR/PBA exchange in | | | authentication and authorization phase) |<-----------+------------>| | | | | | IKEv2 | | (with Configuration Payload exchange) | |<-----------+-------------------------->| | | | | Figure 11: An example sequence for configuring IPsec-TIA in IPv6 10.2.2. PANA with Bootstrapping WPA/IEEE 802.11i In this model, PANA is used for authentication and authorization, and link-layer ciphering is used for access control. Successful PANA authentication enables link-layer ciphering which is based on PSK (Pre-Shared Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i]. The PSK is derived from the EAP AAA-Key as a result of successful PANA authentication. In this model, MAC addresses are used as the device identifiers in PANA. This model allows the separation of PAA from EPs(APs). A typical purpose of using this model is to reduce AP management cost by allowing physical separation of RADIUS/Diameter client from access points, where AP management can be a significant issue when deploying a large number of access points. Additionally, this centralized AAA framework enhances mobility-related performance (inter-AP but intra- PAA mobility does not require additional PANA executions). By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is Jayaraman, et al. Expires September 4, 2006 [Page 29] Internet-Draft PANA Framework March 2006 also possible to improve wireless LAN security by providing protected disconnection procedure at L3. This model does not require any change in the current WPA and IEEE 802.11i specifications. This also means that PANA doesn't provide any link-layer security features beyond those already provided for in WPA and IEEE 802.11i. The IEEE 802.11 specification [802.11] allows Class 1 data frames to be received in any state. Also, IEEE 802.11i [802.11i] optionally allows higher-layer data traffic to be received and processed on the IEEE 802.1X Uncontrolled Ports. This feature allows processing IP- based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client authentication. Until the PaC is successfully authenticated, only a selected type of IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any other IP traffic is dropped at the AP without being forwarded to the DS (Distribution System). Upon successful PANA authentication, the traffic switches to the controlled port. Host configuration, including obtaining an (potentially new) IP address, takes place on this port. Usual DHCP-based, and also in the case of IPv6 stateless autoconfiguration, mechanism is available to the PaC. After this point, the rest of the IP traffic, including PANA exchanges, are processed on the controlled port. When a PaC does not have a PSK for the AP, the following procedure is taken: 1. The PaC associates with the AP. 2. The PaC configures a PRPA by using a method defined in Section 5 and then runs PANA. 3. Upon successful authentication, the PaC obtains a separate PSK for each AP controlled by the PAA as well as the information on the available POPA configuration methods. 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK (Pair-wise Transient Key) with the PaC, by using the PMK. 5. The PaC obtains a POPA when necessary using one of the available POPA configuration methods. An alternative to running PANA over IEEE 802.1X Uncontrolled Port is to dedicate a virtual open-access AP for the authentication. Upon successful PANA authentication over this AP, the PaC will switch over to another virtual AP to utilize the PANA-derived PSK. Jayaraman, et al. Expires September 4, 2006 [Page 30] Internet-Draft PANA Framework March 2006 10.2.3. Capability Discovery When a PaC is a mobile, there may be multiple APs available in its vicinity. Each AP can be one of the following types: a) AP without IEEE 802.11i There is no IEEE 802.11i link-layer security on this AP. b) AP with IEEE 802.11i using PSK mode bootstrapped from PANA The clients are required to perform PANA authentication which allows the PaC to bootstrap a dynamic PSK to access this AP. c) AP with IEEE 802.11i using native PSK mode AP and PaC must share a statically configured PSK to access this AP. d) AP with IEEE 802.11i using 802.1X/EAP mode The clients are required to perform IEEE 802.1X/EAP authentication for this AP. Checking the capability information advertised in IEEE 802.11 Beacon/ Probe Response frames (IEEE 802.11i defines RSN Information Element (IE) for this purpose), PaC can extract certain information about the different types of APs. Specifically, if no RSN IE is contained in Beacon/Probe Response frames then the AP is Type (a). Additionally, Type (d) can be recognized because IEEE 802.1X-EAP mode is advertised in the RSN IE. However Types (b) and (c) are not distinguishable by a PaC that does not have a PSK bootstrapped from PANA for the AP, because in both cases PSK mode is advertised in the RSN IE. Thus, the PaC will need to take an additional action of trying to associate to the AP. If either the PaC receives a disassociation frame from the AP as the AP does not hold a PSK for the PaC, or AP immediately starts 4-way handshake after association, PaC can consider AP as Type (c). Otherwise it is Type (b). The PaC behavior after identifying an Type (b) AP is described in Section 10.2.2. Jayaraman, et al. Expires September 4, 2006 [Page 31] Internet-Draft PANA Framework March 2006 11. Security Considerations Security is discussed throughout this document. For protocol- specific security considerations, refer to [I-D.ietf-pana-pana]. Jayaraman, et al. Expires September 4, 2006 [Page 32] Internet-Draft PANA Framework March 2006 12. IANA Considerations This document has no actions for IANA. Jayaraman, et al. Expires September 4, 2006 [Page 33] Internet-Draft PANA Framework March 2006 13. Acknowledgments We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley and Jari Arkko for their valuable comments. Jayaraman, et al. Expires September 4, 2006 [Page 34] Internet-Draft PANA Framework March 2006 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. [I-D.ietf-pana-snmp] Mghazli, Y., "SNMP usage for PAA-EP interface", draft-ietf-pana-snmp-05 (work in progress), January 2006. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA Enabling IPsec based Access Control", draft-ietf-pana-ipsec-07 (work in progress), July 2005. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for Jayaraman, et al. Expires September 4, 2006 [Page 35] Internet-Draft PANA Framework March 2006 IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. [DSL] DSL Forum Architecture and Transport Working Group, "DSL Forum TR-059 DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003. 14.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [I-D.ietf-eap-netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", draft-ietf-eap-netsel-problem-03 (work in progress), October 2005. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless IP Network Standard", 3GPP2 P.S0001-B/v2.0, September 2004. [802.11i] Institute of Electrical and Electronics Engineers, "IEEE Standard for Information technology - Telecommunications Jayaraman, et al. Expires September 4, 2006 [Page 36] Internet-Draft PANA Framework March 2006 and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, 2004. [802.11] Institute of Electrical and Electronics Engineers, "Information technology - telecommunications and information exchange between systems - local and metropolitan area networks - specific requirements part 11: Wireless lan medium access control (mac) and physical layer (phy) specifications", IEEE Standard 802.11, 1999(R2003). [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi- Fi WPA v3.1, 2004. Jayaraman, et al. Expires September 4, 2006 [Page 37] Internet-Draft PANA Framework March 2006 Authors' Addresses Prakash Jayaraman Network Equipment Technologies, Inc. 6900 Paseo Padre Parkway Fremont, CA 94555 USA Phone: +1 510 574 2305 Email: prakash_jayaraman@net.com Rafa Marin Lopez University of Murcia 30071 Murcia Spain Email: rafa@dif.um.es Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 408 734 8820 Email: mohanp@sbcglobal.net Alper E. Yegin Samsung Advanced Institute of Technology Istanbul, Turkey Phone: +90 538 719 0181 Email: alper01.yegin@partner.samsung.com Jayaraman, et al. Expires September 4, 2006 [Page 38] Internet-Draft PANA Framework March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jayaraman, et al. Expires September 4, 2006 [Page 39]