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]