Internet-Draft                                   Yoshihiro Ohba (Editor)
Expires: December, 2002                                        Subir Das
                                                         Basavaraj Patil
                                                          Hesham Soliman


                                                           June 17, 2002


               Problem Space and Usage Scenarios for PANA

                <draft-ietf-pana-usage-scenarios-02.txt>


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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

   Most of the commercial networks today require users (or devices on
   behalf of users) to provide their authentication information, such as
   identity, device identifier, etc., before being allowed access to
   network resources.  Resources here include basic access to the
   network, specific value added services, different grade of services
   etc.  While such networks are available in the market place, the
   authentication process and access control mechanisms depend upon the
   type of network that a user is attaching to and in most cases it is
   specific to an access technology.  Due to the rapid proliferation of
   access technologies, wireless devices and next generation services
   offerings, a flexible authentication (which is independent of
   underlying access technologies) and access control mechanisms are
   deemed necessary.  This document therefore attempts to describe
   several such scenarios where existing mechanisms are not sufficient
   and finally argue the need for a new higher layer protocol called
   PANA (Protocol for carrying Authentication for Network Access).  It
   also helps to understand the problem space clearly and facilitate the
   discussion for PANA requirements and framework.




                         Expires December, 2002                 [Page 1]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


Table of Contents

   1         Terms ................................................... 2
   1.1.      Acronyms ................................................ 2
   1.2.      Terminology ............................................. 2
   2.        Problem Space ........................................... 4
   3.        PANA Model .............................................. 6
   3.1.      Simple PANA Model ....................................... 6
   3.2.      Advanced PANA model ..................................... 7
   3.2.1.    PAA Co-located with Access Router ....................... 8
   3.2.2.    PAA Separated from Access Router ........................ 9
   4.        Usage Scenarios ......................................... 9
   4.1.      Initial Authentication Timing ........................... 9
   4.2.      Multiple Access Routers ................................ 10
   4.3.      Multiple-Interface Device .............................. 10
   4.4.      PANA as a Per-packet Protection Enabler ................ 11
   5.        Security Consideration ................................. 11
   6.        Acknowledgments ........................................ 12
   7.        References ............................................. 12
   8.        Authors' Information ................................... 12


1  Terms

1.1.  Acronyms

   AAA: Authentication, Authorization and Accounting

   AP: Access Point

   AR: Access Router

   DSL: Digital Subscriber Line

   EAP: Extensible Authentication Protocol

   GPRS: General Packet Radio Service

   LSA: Local Security Association

   PDP: Packet Data Protocol

   NAS: Network Access Server

   PAA: PANA Authentication Agent

   PaC: PANA Client

   PPP: Point-to-Point Protocol


1.2.  Terminology

   Following terminologies are defined for this document.  See also
   [PANAREQ].





                         Expires December, 2002                 [Page 2]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


     Device

       A network element (namely notebook computers, PDAs, etc.) that
       requires access to a provider's network.

     Device Identifier (DI)

       The identifier used by the network as a handle to control and
       police the network access of a PANA client. Depending on the
       access technology, identifier might contain any of IP address,
       link-layer address, switch port number, etc. of a device. PANA
       authentication agent keeps a table for binding device identifiers
       to the PANA clients.

     Edge Subnet

       The immediate IP subnet that is available to an interface of the
       device for network access.

     PANA Client (PaC)

       An entity in the edge subnet who is wishing to obtain network
       access from a PANA authentication agent within a network. A PANA
       client is associated with a device and a set of credentials to
       prove its identity within the scope of PANA.

     PANA Authentication Agent (PAA)

       An entity in the edge subnet 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.


     Access Point

       A first-hop wireless L2 attachment point from the device in the
       edge subnet.

     Access Router

       A router in the edge subnet.

     Local Security Association (LSA)

       A temporary security association between a PaC and a PAA, which
       is derived from credentials of the PaC during initial
       authentication.

     Initial Authentication

       Authentication performed when a device enters into the edge
       subnet and provides the credentials to be authorized for network
       access without having any a priori authorization information.
       This will require a PAA to verify the credentials either locally
       or by using a back-end authentication infrastructure.




                         Expires December, 2002                 [Page 3]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


     Re-authentication

       Authentication that occurs when a device needs to extend the
       authorization lifetime, changes attributes such as, IP address
       and/or MAC address, etc., for the same network access after
       successful initial authentication.  This may require a PAA to
       verify the credentials (used for initial authentication) either
       locally or by using a back-end authentication infrastructure.

     Local re-authentication

       A type of re-authentication that occurs locally between a PaC and
       a PAA by using the LSA established between them.  In this type of
       re-authentication, the PaC does not use the same credentials as
       used for initial authentication.

     Higher Layer

       A layer that is higher than layer two.


2.  Problem Space

   Today's technologies mostly rely on access specific authentication
   mechanisms (i.e., L2 authentication mechanisms) for network access.
   For example, PPP has a built-in mechanism for peer authentication
   [RFC1661] and IEEE 802 networks define a port-based network access
   control with peer authentication in point-to-point LAN segments
   [802.1X].  However, it is not guaranteed that L2 authentication is
   always available in the edge subnet as long as authentication for
   establishing L2 connectivity is not a mandatory part in the
   specification of an L2 protocol.  For example, the best current
   practice of Ethernet links that are composed of legacy hubs and
   switches does not use 802.1X authentication.  This leads to the
   following need:

   i) Need for authentication over L2 links that do not support an
      appropriate authentication mechanism.

      In order to satisfy this need where authentication for network
      access is required, a higher layer protocol for authentication is
      appropriate.  PPP over Ethernet [PPPoE] is currently used for both
      client authentication and IP packet encapsulation over Ethernet
      over DSL, however, it was not intended to be used for
      authentication over multi-access links, and more appropriate
      authentication carrier protocol that does not require PPP
      encapsulation over multi-access links is deemed necessary.


   It is a common practice to use higher-layer authentication on top of
   link-layer authentication.  For example in 3GPP and 3GPP2, PPP is
   used for authentication after link-layer authentication succeeds.
   Or, http-redirect method is used as a higher-layer user
   authentication in some other network access architectures.  This
   leads to the following need:





                         Expires December, 2002                 [Page 4]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


   ii) Need for L3 authentication separated from L2 authentication

      Multi-layer authentication is necessary when each authentication
      layer is associated with a different level of network access
      authorization.  For example, when an ASP (Access Service Provider)
      provides hot-spot wireless access service from which a user device
      can connect to its own ISP(s), it is possible to use L2
      authentication to access one of the ASPs in the hot-spot area, but
      higher layer authentication is needed when connecting to one of
      its ISPs.


   Due to the rapid proliferation of access technologies, wireless
   devices are becoming very popular.  On the other hand, these
   technologies demands different kinds of authentication, such as:

   iii) Need for local re-authentication

      Re-authentication is necessary at least in the following
      situations:

      a) If the underlying access network does not have a capability to
         detect physical disconnection of devices, periodical re-
         authentication is necessary for minimizing the impact of
         attacks (e.g., free riding) due to IP address and/or MAC
         address spoofing, which would possibly occur when the device is
         shutdown or the user leaves the edge subnet with the device
         without performing explicit log-off from the local network.

      b) If there is a change in attributes (e.g., IP address and/or MAC
         address) of a device, re-authentication is necessary in order
         to make sure that the proper change is informed by the entity
         that was once authenticated successfully.


      It is also important that re-authentication is performed locally
      between the PaC and the PAA without involving other network
      entities.  However, there might be some instances where re-
      authentication with help of back-end authentication infrastructure
      is necessary in addition to local re-authentication, considering
      security for accounting such as non-repudiation.


      With regard to case (a), considering mobile and wireless
      environments, it is possible that a device has multiple wireless
      interfaces and switches frequently from one interface to another
      in the same administrative domain.  This type of switching can
      occur with or without changing an IP address based on variable
      requirements (e.g., power saving vs. throughput).  In this
      scenario, re-authentication is necessary for the new interface to
      be authorized for network access, and it is important that re-
      authentication is performed locally between the PaC and the PAA
      for fast interface switching.  The need for local re-
      authentication for interface switching immediately leads to a need
      for another access-independent authentication mechanism that
      supports:




                         Expires December, 2002                 [Page 5]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


      o  an access technology independent authentication protocol for
         providing a generic method for local re-authentication among
         different interfaces, AND

      o  an access independent PaC identifier for associating the
         different interfaces with the same LSA that is used for local
         re-authentication.

   Local authentication described above should be taken into account
   when designing and implementing an L3 authentication carrier protocol
   (and any sort of authentication carrier protocol as well).


   In conclusion, we anticipate that a higher layer protocol like PANA
   (Protocol carrying Authentication for Network Access) will satisfy
   all of the above needs that are emerging.


3.  PANA Model

   Following sub-sections capture the PANA usage model in different
   network architectures with reference to its placement of logical
   elements such as, PANA Client (PaC) and PANA Authentication Agent
   (PAA).


3.1.  Simple PANA Model

   Figure 1 describes a simple architecture in which PAA resides on the
   first hop access router (AR) and PaC on behalf of a device (D1, D2,..
   etc) communicates with PAA for network access.  As shown in figure,
   PaC can use different L2 interfaces to connect to the first hop
   access router.  PAA may or may not use AAA infrastructure to verify
   the credentials of PaC and grants or deny the device (belongs to that
   particular PaC) to access the network resources.  PANA in this case
   provides a means to transport the authentication parameters from the
   PaC to PAA securely.  PAA understands how to verify the credentials.
   After verification, PAA sends back the success or failure to PaC.
   Although the AR would be the access control enforcement point in this
   case, PANA does not play any explicit role in performing access
   control except that it provides a hook to access control mechanisms.



















                         Expires December, 2002                 [Page 6]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


        <============== PANA ===============>
     +-----------------------------+
     |       An edge IP subnet     |
     |                             |
     |  D1 ----[DSLAM]---------+   |
     | [PaC]                   |   |
     |                         |   |         (AAA infrastructure)
     |                         |   |            .
     |  D2 ----[Ethernet Hub]--+   |           .
     | [PaC]                   |   |          .
     |                         +-------------AR---------(Internet)
     |                         |   |        [PAA]
     |  D3 ----[802.11a/b AP]--+   |
     | [PaC]                   |   |
     |                         |   |
     |                         |   |
     |  D4  ----[Cellular AP]--+   |
     | [PaC]                       |
     +-----------------------------+

             Figure 1: An example of simple PANA model


3.2.  Advanced PANA model

   Figure 2 presents an advanced architecture where, multiple routers
   are placed in an edge subnet and the device has one or more
   interfaces.  For simplicity, optional connection to AAA
   infrastructure is not shown in the figures of this section.  Each
   interface of a device supports a specific L2 type.  Thus the edge IP
   subnet consists of one or more L2 segments, where those segments can
   be different L2 types.  PANA can support this advanced architecture
   in two different ways: (i) co-location of PAA with access router and
   (ii) separation of PAA from access router.  Although this section
   describes generic models, more detailed issues on multiple access
   routers and multiple-interface devices are provided in section "Usage
   Scenarios".























                         Expires December, 2002                 [Page 7]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


   +------------------------------+
   |       An edge IP subnet      |
   |                              |
   | D1------[DSLAM]----------+   |
   |                          |   |
   |                          +--------- AR
   |                          |   |       \
   | D2------[Ethernet Hub]---+   |        \
   |                          |   |         \
   |                          +--------- AR--+---------(Internet)
   |                          |   |         /
   | D3--+---[802.11a/b AP]---+   |        /
   |     |                    |   |       /
   |     |                    +--------- AR
   |     |                    |   |
   |     +---[Cellular AP]----+   |
   |                              |
   +------------------------------+

           Figure 2: An example of Advanced Architecture


3.2.1.  PAA Co-located with Access Router


   In this scenario (Figure 3), multiple PAAs can co-exist especially
   when there are multiple access routers in the edge subnet.  PAAs are
   co-located with these access routers on which access control is
   performed. When a PaC needs to be authenticated and authorized for
   network access it exchanges PANA messages (as described above) with a
   PAA.


    <============== PANA ================>
   +------------------------------+
   |       An edge IP subnet      |
   |                              |
   | D1------[DSLAM]----------+   |
   |[PaC]                     |   |
   |                          +---------- AR
   |                          |   |     [PAA]\
   | D2------[Ethernet Hub]---+   |           \
   |[PaC]                     |   |            \
   |                          +---------- AR----+--------(Internet)
   |                          |   |     [PAA]  /
   | D3--+---[802.11a/b AP]---+   |           /
   |[PaC]|                    |   |          /
   |     |                    +-----------AR
   |     |                    |   |     [PAA]
   |     +---[Cellular AP]----+   |
   |                              |
   +------------------------------+

           Figure 3: An example of Advanced  PANA Model
                     [PAA co-located with AR]





                         Expires December, 2002                 [Page 8]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


3.2.2.  PAA Separated from Access Router


   Figure 4 describes this model.  In this scenario, PAA is not co-
   located with AR but resides on the edge subnet.  PaC exchanges the
   same messages with PAA as discussed earlier.  The difference here is
   when initial authentication for the PaC is successful, access control
   parameters are to be distributed to all access routers residing in
   the edge subnet so that the device that PaC resides is authorized at
   all the access routers.  However, PANA does not provide any mechanism
   how access control parameters are to be distributed. This is in fact
   outside the scope of PANA.

    <============== PANA =================>
   +------------------------------+
   |       An edge IP subnet      |
   |                              |
   | D1------[DSLAM]----------+-----------PAA
   |[PaC]                     |   |
   |                          +---------- AR
   |                          |   |         \
   | D2------[Ethernet Hub]---+   |          \
   |[PaC]                     |   |           \
   |                          +---------- AR---+---------(Internet)
   |                          |   |           /
   | D3--+---[802.11a/b AP]---+   |          /
   |[PaC]|                    |   |         /
   |     |                    +-----------AR
   |     |                    |   |
   |     +---[Cellular AP]----+   |
   |                              |
   +------------------------------+

          Figure 4: An example of Advanced  PANA Model
                    [PAA separated from AR]



4.  Usage Scenarios


4.1.  Initial Authentication Timing

   There are two possible scenarios with regard to the timing at which
   initial authentication occurs, i.e., initial authentication can occur
   before or after IP address configuration.  Note that "IP address
   configuration" in this document means configuration of an IP address
   that needs to be authorized for network access, and thus configuring
   an IPv6 link local address or any temporal IP address that is used
   only for authentication purpose and not necessarily authorized for
   network access is excluded from the definition of "IP address
   configuration."

   There are a number of situations where authentication before IP
   address configuration would be important, for example:

      a) If strict access control is required or the IP address resource



                         Expires December, 2002                 [Page 9]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


         used for network access is scarce, authentication should occur
         before IP address configuration.

      b) If an AP supports multiple VLANs and it is possible to
         dynamically associate a device with one of the VLANs depending
         on the authentication and authorization result, initial
         authentication should occur before IP address configuration.

      c) If a distinct IPv6 64-bit prefix can be assigned to each PDP
         context in GPRS[GPRS] or to each subscriber of DSL or cable
         internet, initial authentication should occur before IP address
         configuration.

   On the other hand, initial authentication after IP address
   configuration would be useful for providing a network access service
   in which access to local information such as local-area map and
   flight information for free of charge, while access to specific
   external web-sites is subject to charge.


4.2.  Multiple Access Routers


   In multi-access environments, such as IEEE 802 networks, it is
   possible for multiple ARs to coexist on the same shared media.  In
   such a scenario, it would be desirable to use multiple ARs in a way
   that traffic coming from and going to a specific device always goes
   through a single AR for ease of access control, but traffic from
   different devices diverges over multiple ARs for the purpose of load
   balancing and redundancy.  If such a routing control is performed, it
   would be desired to perform authentication via the same AR.  This is
   one scenario where Figure 3 of the advanced PANA model is applied.
   On the other hand, there are some cases in which such a routing
   control would not be possible.

   For example, if we consider to use "ICMP Redirect or IPv6 Host to
   Router Load Sharing" [Hinden] mechanism, either Figure 3 or Figure 4
   of the advanced PANA model would be applied.  Anyway, additional
   mechanisms would be required for distributing access control
   parameters from one PAA to other access router(s) that are not
   physically co-located with the PAA.  In other words, the types of
   routing control would affect the location of PAA as well as the way
   of access control in multi-AR environments.

   The multi-AR scenario also addresses the issue of multiple providers
   on the same shared media, i.e., each AR may not be administered by
   the same provider.  In this case, it would be necessary for PANA to
   have a mechanism to provide the identity of PAA(s) for a PaC so that
   the PaC can choose an appropriate provider to access.


4.3.  Multiple-Interface Device

   A device can have multiple interfaces of homogeneous or heterogeneous
   technologies.  Thus, there are two possible scenarios for PANA:
   multi-homing and interface switching.




                         Expires December, 2002                [Page 10]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


   In case of multi-homing, the multiple interfaces of a device may be
   activated at the same time for various requirements such as increased
   bandwidth, load balancing and reliability.  PANA should provide a way
   for the PaC of the device to perform initial authentication and local
   re-authentication for each interface.

   In case of interface switching, it is important to use an access-
   independent authentication mechanism (as described in section 2).
   This access-independent authentication mechanism allows a PaC to
   perform local re-authentication with a PAA when interface switching
   occurs.



4.4.  PANA as a Per-packet Protection Enabler

   Although PANA itself does not define key distribution protocol and
   mechanism, it is possible to use PANA to enable per-packet protection
   mechanism (such as IPsec and WEP) to secure communication in the edge
   subnet, if the authentication carrier protocol that is used by PANA
   supports key distribution mechanism.  Note that using PANA for WEP
   key distribution would be useful (if implemented appropriately) when
   L2 authentication is null or does not have key distribution
   capability.


5.  Security Consideration

   We anticipate following security issues or concerns relating to a
   higher layer protocol such as PANA.

   o  Consideration for Eavesdropping

      Since PANA protocol carries authentication information,
      consideration is necessary for preventing confidential part of the
      credentials of a PaC from being known by eavesdroppers in the edge
      subnet.  The eavesdroppers include users and operators in the
      local network.

   o  Consideration for Denial of Service Attacks

      Since PANA protocol is used for authentication, consideration is
      necessary for preventing authentication of a legitimate PaC from
      being denied as a result of processing PANA messages sent from
      attackers.  Next, since both initial authentication and re-
      authentication would require cryptographic computation on both PaC
      and PAA, consideration is necessary for both PaC and PAA not to
      spend CPU and memory resources for processing PANA messages sent
      from an attacker more than that is spent by the attacker to
      attack.  The attackers may or may not be on the same link as the
      PaC or PAA.

      Additionally, since during initial authentication PAA may use
      back-end authentication infrastructure, consideration is necessary
      to prevent the authentication infrastructure from being attacked
      via PAA while using PANA.




                         Expires December, 2002                [Page 11]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


   o  Consideration for Man-In-The-Middle Attacks

      Consideration is necessary for preventing the communication
      between PaC and PAA from being spoofed by an attacker in between.
      The attacker could be on the same edge subnet as PaC and PAA,
      e.g., by putting a bogus access point between a PaC and a PAA in
      the edge subnet.


6.  Acknowledgments

   The authors would like to thank James Carlson, Jacques Caron, Paal
   Engelstad, Henry Haverinen, James Kempf, Thomas Narten, Erik
   Nordmark, Phil Roberts, David Spence, Barani Subbiah, George
   Tsirtsis, Cliff Wang, Alper Yegin and the rest of the PANA Working
   Group for the ideas and support they have given to this document.


7.  References

   [802.1X] IEEE Standard for Local and Metropolitan Area Networks,
       "Port-Based Network Access Control", IEEE Std 802.1X-2001.

   [EAPSRP] J. Carlson, et al., "EAP SRP-SHA1 Authentication Protocol",
       Internet-Draft, Work in progress, July 2001.

   [GPRS] R. Bates, "GPRS", McGraw-Hill TELECOM, ISBN 007138188, 2002.

   [Hinden] R. Hinden, "IPv6 Host to Router Load Sharing",
       Internet-Draft, Work in progress, January 2002.

   [Keywords] S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.

   [PANAREQ] A. Yegin, et al., "Protocol for Carrying Authentication for
       Network Access (PANA) Requirements and Terminology", Internet-Draft,
       Work in progress, February 2001.

   [PPPoE] L. Mamakos, et al., "A Method for Transmitting PPP Over
       Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661
       (STD 51), July 1994.

   [RFC2284] L. Blunk, et. al., "PPP Extensible Authentication Protocol
       (EAP)", RFC 2284, March 1998.


8.  Authors' Information

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ 07961-0136
   USA
   Phone: +1 973 829 5174
   Fax:   +1 973 829 5601



                         Expires December, 2002                [Page 12]


Internet-Draft  Problem Space & Usage Scenarios for PANA   June 17, 2002


   Email: yohba@tari.toshiba.com

   Subir Das
   MCC 1D210R, Telcordia Technologies
   445 South Street, Morristown, NJ 07960
   Phone: +1 973 829 4959
   email: subir@research.telcordia.com

   Basavaraj Patil
   Nokia
   6000 Connection Dr.
   Irving, TX. 75039
   USA
   Phone:  +1 972-894-6709
   Email:  Basavaraj.Patil@nokia.com

   Hesham Soliman
   Ericsson Radio Systems AB
   Torshamnsgatan 29,
   Kista, Stockholm 16480
   Sweden
   Phone:  +46 8 4046619
   Fax:    +46 8 4047020
   E-mail: Hesham.Soliman@era.ericsson.se




































                         Expires December, 2002                [Page 13]