IETF PANA Working Group                          Alper E. Yegin, Editor 
INTERNET-DRAFT                                           Yoshihiro Ohba 
Expires: December 2003                                   Reinaldo Penno 
                                                        George Tsirtsis 
                                                             Cliff Wang 
                                                              June 2003 
 
 
                 Protocol for Carrying Authentication for  
                    Network Access (PANA) Requirements 
                    draft-ietf-pana-requirements-07.txt 
 
    
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026. 
 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as  
   Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   It is expected that future IP devices will have a variety of access 
   technologies to gain network connectivity. Currently there are 
   access-specific mechanisms for providing client information to the 
   network for authentication and authorization purposes. In addition 
   to being limited to specific access media (e.g., 802.1X for IEEE 802 
   links), some of these protocols are limited to specific network 
   topologies (e.g., PPP for point-to-point links). The goal of 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 2003 
  
Table of Contents 
    
    
   Abstract..........................................................1 
   Table of Contents.................................................2 
   1. Introduction...................................................3 
   2. Key Words......................................................4 
   3. Terminology....................................................4 
   4. Requirements...................................................5 
   4.1. Authentication...............................................5 
   4.1.1. Authentication of Client...................................5 
   4.1.2. Authorization, Accounting and Access Control...............6 
   4.1.3. Authentication Backend.....................................7 
   4.1.4. Identifiers................................................7 
   4.2. IP Address Assignment........................................7 
   4.3. EAP Lower Layer Requirements.................................8 
   4.4. PAA-to-EP Protocol...........................................8 
   4.5. Network......................................................9 
   4.5.1. Multi-access...............................................9 
   4.5.2. Disconnect Indication......................................9 
   4.5.3. Location of PAA............................................9 
   4.5.4. Secure Channel............................................10 
   4.6. Interaction with Other Protocols............................10 
   4.7. Performance.................................................10 
   4.8. Congestion Control..........................................11 
   4.9. IP Version Independence.....................................11 
   4.10. Denial of Service Attacks..................................11 
   4.11. Client Identity Privacy....................................11 
   5. Security Considerations.......................................11 
   6. Acknowledgements..............................................11 
   7. References....................................................12 
   7.1. Normative References........................................12 
   7.2. Informative References......................................12 
   8. Authors' Addresses............................................13 
   9. Appendix......................................................14 
   10. Full Copyright Statement.....................................16 
    
    
    
    
    
    
    
    
    
                                         



    
 Yegin (Editor), et.al.        Expires Dec 2003               [Page 2] 
 Internet Draft             PANA Requirements                June 2003 
  
1. Introduction  
        
   Providing secure 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 clients 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] 
   describes the problem statement in detail.  
        
   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]. In particular, 
   the requirements do not mandate the need to define new 
   authentication protocols (e.g., EAP-TLS [EAPTLS]), 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]. A Mobile IPv4 registration 
   request message is used as a carrier for authentication extensions 
   (MN-FA [MIPv4] or MN-AAA [MNAAA]) 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 2003 
  
    
   This document defines the common terminology and identifies the 
   requirements of a protocol for PANA. These terminology and 
   requirements will be used to define and limit the scope of the work 
   to be done in this group.  
    
     
2. Key Words  
        
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [KEYWORDS].  
 
 
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] 
        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 2003 
  
4. Requirements  
        
4.1. Authentication  
        
  4.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], neighbor discovery [NDISC], and address 
   resolution protocols [ARP] is outside the scope as well. 
    



    
 Yegin (Editor), et.al.        Expires Dec 2003               [Page 5] 
 Internet Draft             PANA Requirements                June 2003 
  
   Some 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]. 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. 
    
         
  4.1.2. Authorization, Accounting and Access Control  
     
   After a device is authenticated 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 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 2003 
  
   is 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.   
    
            
  4.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.  
    
        
  4.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]. 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.  
    
    
4.2. IP Address Assignment 
    
   Assigning an IP address to the client is outside the scope of PANA. 
   PANA protocol design MAY require the PaC to 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 
   designing PANA. 
    
 
4.3. 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] for the generic transport requirements 
   that MUST be satisfied by PANA as well. 
    
    
4.4. 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 2003 
  
   end of a successful PANA exchange without the EP ever sending a 
   request. 
    
    
4.5. Network  
        
  4.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. 
    
        
  4.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 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. 
    
    
  4.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 2003 
  
   A 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. 
    
                
  4.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. 
    
         
4.6. 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], 
   Mobile IPv6 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and 
   other standard protocols like IPv6 stateless address  
   auto-configuration  [ADDRCONF] (including privacy extensions 
   [PRIVACY]), and DHCP [DHCPV4, DHCPV6]. It MUST NOT make any 
   assumptions on the protocols or mechanisms used for IP address 
   configuration of the PaC.   
    
    
4.7. 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 
  
4.8. 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. 
    
    
4.9. IP Version Independence  
        
   PANA MUST work with both IPv4 and IPv6.  
    
    
4.10. 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.  
    
        
4.11. 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. 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]. Security threats identified in that document are 
   already included in this general PANA requirements document.  
 
    
6. Acknowledgements  
        
   We would like to thank Subir Das, Lionel Morand, Mohan 
   Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan 
   Forsberg, Francis Dupont, Bernard Aboba 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. References 
    
7.1. Normative References  
        
   [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate   
   Requirement Levels", 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. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, 
   "Extensible Authentication Protocol (EAP)",  
   draft-ietf-eap-rfc2284bis-04.txt, June 2003. Work in progress. 
     
 
7.2. Informative References  
    
   [8021X] "IEEE Standards for Local and Metropolitan Area Networks:  
   Port Based Network Access Control", IEEE Std 802.1X-2001.  
 
   [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", 
   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), "The Point-To-Point Protocol (PPP)", STD 
   51, RFC 1661, July 1994.  
      
   [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC 
   3344, 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. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 
   for IP Version 6 (IPv6)",RFC 2461, December 1998.  
    
   [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 
   RFC 826, November 1982.  
        


    
 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 Handovers for Mobile 
   IPv6", March 2003. Work in progress.  
        
   [DHCPV4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 
   March 1997. 
    
   [DHCPV6] R. Droms (editor), et. al., "Dynamic Host Configuration 
   Protocol for IPv6 (DHCPv6)", November 2002. Work in progress. 
             
   [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 
   Address Autoconfiguration in IPv6", RFC 3041, January 2001.  
 
        
8. Authors' Addresses  
        
      Alper E. Yegin  
      DoCoMo USA Labs  
      181 Metro Drive, Suite 300  
      San Jose, CA, 95110  
      USA  
      Phone: +1 408 451 4743  
      Email: alper@docomolabs-usa.com  
     
      Yoshihiro Ohba  
      Toshiba America Research, Inc.  
      P.O. Box 136  
      Convent Station, NJ, 07961-0136  
      USA  
      Phone: +1 973 829 5174  
      Email: yohba@tari.toshiba.com  
        
      Reinaldo Penno  
      Nortel Networks  
      600 Technology Park  
      Billerica, MA, 01821 
      USA  
      Phone: +1 978 288 8011 
      Email: rpenno@nortelnetworks.com  
 
      George Tsirtsis  
      Flarion Technologies  
      Bedminster One  
      135 Route 202/206 South  
      Bedminster, NJ, 07921  
      USA  
      Phone : +44 20 88260073  
      E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com  
    
    


    
 Yegin (Editor), et.al.        Expires Dec 2003              [Page 13] 
 Internet Draft             PANA Requirements                June 2003 
  
      Cliff Wang  
      Smart Pipes  
      565 Metro Place South  
      Dublin, OH, 43017  
      USA  
      Phone: +1 614 923 6241  
      Email: cwang@smartpipes.com  
 
 
9. Appendix  
    
   A. PANA Model 
    
   Following sub-sections 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). Four 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. 
    
    
   A.1.  PAA Co-located with EP but Separated 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-capable L2 access device). 
    
    
            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.  PAA Co-located with AR but Separated 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, access control parameters have 
   to be distributed to 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, a 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.  PAA Co-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.  PAA Separated from 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, after 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 separated from EP and AR. 
    
      
10. Full Copyright Statement  
        
   "Copyright (C) The Internet Society (2003). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.  
        
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns.  
        
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING  
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION  
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
        
        
    
    
    
    
 



    
 Yegin (Editor), et.al.        Expires Dec 2003              [Page 16]