[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 rfc4058                         
PANA Working Group                               Alper E. Yegin, Editor
INTERNET-DRAFT                                           Yoshihiro Ohba
Date: May 2003                                           Reinaldo Penno
Expires: November 2003                                  George Tsirtsis
                                                             Cliff Wang

                 Protocol for Carrying Authentication for
                    Network Access (PANA) Requirements
                   <draft-ietf-pana-requirements-06.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 the
   PANA is to provide a link-layer agnostic and IPv4/IPv6 compatible
   client-server protocol that allows a host to be authenticated for
   network access. The protocol will run between a client's device and
   an agent device in the network where the agent might be a client of
   the AAA infrastructure. This document defines the common terminology
   and identifies the requirements for PANA.

Yegin (Editor), et. al.         Expires Nov 2003             [Page 1]


Internet Draft             PANA Requirements                 May 2003
Table of Contents
   Status of this Memo...............................................1
   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.....................................6
   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......................................................8
   4.5.1. Multi-access...............................................8
   4.5.2. Disconnect Indication......................................9
   4.5.3. Location of PAA............................................9
   4.5.4. Secure Channel.............................................9
   4.6. Interaction with Other Protocols............................10
   4.7. Performance.................................................10
   4.8. Congestion Control..........................................10
   4.9. IP Version Independence.....................................10
   4.10. Denial of Service Attacks..................................11
   4.11. Client Identity Privacy....................................11
   5. Security Considerations.......................................11
   6. Change Log....................................................11
   7. Acknowledgements..............................................12
   8. References....................................................12
   8.1. Normative References........................................12
   8.2. Informative References......................................12
   9. Authors' Addresses............................................13
   10. Appendix.....................................................14
   11. Full Copyright Statement.....................................16




Yegin (Editor), et.al.        Expires Nov 2003               [Page 2]


Internet Draft             PANA Requirements                 May 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 methods between the client and the access
   network. The IETF PANA Working Group has been chartered with the
   goal of designing a network-layer access authentication protocol.
   Link-layer authentication mechanisms are used as enablers of secure
   network access. A higher-layer authentication is deemed necessary
   when link-layer authentication mechanisms are either not available
   for lack of technology or deployment difficulties; when link-layer
   authentication mechanisms are not able to meet the overall
   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 client-server
   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 Working Group will not invent new security protocols and
   mechanisms but instead it will use the existing mechanisms. In
   particular, the Working Group will not 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 Nov 2003               [Page 3]


Internet Draft             PANA Requirements                 May 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 entity wishing to obtain network access from a PANA
        authentication agent within a network. A PANA client is
        associated with a network device and a set of credentials to
        prove its identity 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 entity whose responsibility is to authenticate the
        credentials provided by a PANA client and grant network
        access service to the device associated with the client
        and identified by a DI.
   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 Nov 2003               [Page 4]


Internet Draft             PANA Requirements                 May 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"). The current thinking is that a sufficient
   solution would be for PANA to carry EAP [EAP]. If the PANA WG
   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 (e.g., IPsec) ciphering can be
   used to provide such security. These mechanisms require presence of
   cryptographic keying material at PaC and EP, which can be generated
   by various EAP methods. Although PANA does not deal with key
   derivation or distribution, it indirectly enables this by the virtue
   of carrying EAP. The keying material produced by EAP methods cannot
   be directly used with IPsec. In that case these initial keys can be
   used with an IPsec key management protocol like IKE to generate the
   required security associations. Key distribution from PAA to EP
   SHOULD be handled by a separate protocol that takes care of
   provisioning in the network (see section 4.4). 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. Securing IPv6 router
   discovery and neighbor discovery protocols are within the scope of
   the IETF SEND Working Group.
   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

Yegin (Editor), et.al.        Expires Nov 2003               [Page 5]


Internet Draft             PANA Requirements                 May 2003
   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 authenticate each other for
   network access. Providing only the capability of a PAA
   authenticating the PaC is not sufficient. Mutual authentication
   capability is necessary 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 to the 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.
   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

Yegin (Editor), et.al.        Expires Nov 2003               [Page 6]


Internet Draft             PANA Requirements                 May 2003
   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), then 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
   Providing address assignment functionality is outside the scope of
   PANA. PANA protocol design MAY require the PaC to configure an IP
   address before using this protocol. Allocating an IP address to
   unauthenticated PaCs may create security vulnerabilities, such as IP
   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.

Yegin (Editor), et.al.        Expires Nov 2003               [Page 7]


Internet Draft             PANA Requirements                 May 2003
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 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. This WG 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. This task is similar to what the MIDCOM Working Group is
   trying to achieve, therefore some of that WG'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
   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.

Yegin (Editor), et.al.        Expires Nov 2003               [Page 8]


Internet Draft             PANA Requirements                 May 2003

  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. When such indications
   are not protected by means of physical or link-layer mechanisms,
   PANA MUST ensure this protection to prevent attackers 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.
   A PaC 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

Yegin (Editor), et.al.        Expires Nov 2003               [Page 9]


Internet Draft             PANA Requirements                 May 2003
   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 not interfere with various mobility
   management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6
   [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other
   standard protocols like IPv6 stateless address auto-configuration
   [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP
   [DHCP]. 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.
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.

Yegin (Editor), et.al.        Expires Nov 2003              [Page 10]


Internet Draft             PANA Requirements                 May 2003
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.
6. Change Log
   Version 06
   * Location privacy requirements replaced with client identity
   privacy requirement.
   * PAC, PAC identifier, device identifier concepts clarified.
   Version 05
   * Definition of EP added.
   * Text is clarified to indicate some of the requirements are
   satisfied by EAP and EAP methods.
   * IP address pre-configuration requirement changed.
   * EAP lower layer requirements section added.
   * Location of PAA further clarified (link vs. subnet vs. IP hops).
   * PAA-to-EP protocol section added.
   Version 04
   * Minor Editorial corrections.
   * Inserted the PANA model appendix.
   Version 03


Yegin (Editor), et.al.        Expires Nov 2003              [Page 11]


Internet Draft             PANA Requirements                 May 2003
   * In section 4.2.2 the requirement for a heartbeat mechanism to
   provide disconnect indication was removed.  Rewording of the
   section was done.
   * In section 4.2.3 and 4.1.2 rewording was done to account for the
   separation of PAA and EP and the protocol between them.
   * In section 4.2.4 new text was added to account for the possibility
   to rely on the high layer protocol (EAP) to meet the requirements
   stated.
   * In section 4.5 new text was added to allow reliability and
   congestion control to be provided by the payload protocol, e.g.,
   EAP.
7. Acknowledgements
   We would like to thank Subir Das, Lionel Morand, Mohan
   Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan
   Forsberg, and the PANA Working Group members for their valuable
   contributions to the discussions and preparation of this document.
8. References
8.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, "Extensible
   Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-03.txt,
   May 2003. Work in progress.
8.2. Informative References
   [8021X] "IEEE Standards for Local and Metropolitan Area Networks:
   Port Based Network Access Control", IEEE Draft 802.1X/D11, March
   2001.
   [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol",
   RFC 2716, October 1999.

Yegin (Editor), et.al.        Expires Nov 2003              [Page 12]


Internet Draft             PANA Requirements                 May 2003
   [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.
   [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.
   [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration
   Protocol for IPv6", November 2002. Work in progress.
   [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless
   Address Autoconfiguration in IPv6", RFC 3041, January 2001.
9. 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

Yegin (Editor), et.al.        Expires Nov 2003              [Page 13]


Internet Draft             PANA Requirements                 May 2003
      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
      Cliff Wang
      Smart Pipes
      565 Metro Place South
      Dublin, OH, 43017
      USA
      Phone: +1 614 923 6241
      Email: cwang@smartpipes.com
10. 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

Yegin (Editor), et.al.        Expires Nov 2003              [Page 14]


Internet Draft             PANA Requirements                 May 2003
   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.
   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 are
   to be distributed to respective enforcement points so that the
   corresponding device on which PaC is authenticated must be able to
   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.

Yegin (Editor), et.al.        Expires Nov 2003              [Page 15]


Internet Draft             PANA Requirements                 May 2003
           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
   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.
11. Full Copyright Statement
   "Copyright (C) The Internet Society (2002). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for

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


Internet Draft             PANA Requirements                 May 2003
   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 Nov 2003              [Page 17]