[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Internet-Draft                                   Yoshihiro Ohba (Editor)
Expires: April, 2003                                           Subir Das
                                                         Basavaraj Patil
                                                          Hesham Soliman
                                                             Alper Yegin


                                                        October 25, 2002


             Problem Statement and Usage Scenarios for PANA

                <draft-ietf-pana-usage-scenarios-03.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

   This document addresses a set of problems which a network layer
   protocol called PANA (Protocol for carrying Authentication for
   Network Access) is trying to solve in the area of network access
   authentication and describes several usage scenarios where PANA is
   applicable.  It also helps to facilitate the discussion for PANA
   requirements and security threat analysis that are used as basis of
   actual PANA protocol design.














                           Expires April, 2003                  [Page 1]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


Table of Contents

   1         Introduction ............................................ 2
   2.        Terminology ............................................. 2
   3.        Problem Statement ....................................... 3
   4.        Usage Scenarios ......................................... 4
   4.1.      PANA with Physical Layer Security ....................... 5
   4.2.      PANA with Link Layer Security ........................... 5
   4.3.      PANA in the Absence of Any Lower Layer Security ......... 6
   4.4.      Mobile IP ............................................... 7
   4.5.      Personal Area Networks .................................. 7
   4.6.      Limited Free Access ..................................... 8
   4.7.      Multiple-Interface Device ............................... 9
   5.        Acronyms ................................................ 9
   6.        Acknowledgments ........................................ 10
   7.        References ............................................. 10
   8.        Authors' Information ................................... 10


1  Introduction

   Network access in most cases requires some form of authentication.
   Generally authentication is performed at the time of link
   establishment. Authentication for network access is usually tied to
   the access technology itself. As a result specific authentication
   schemes are implemented depending on the type of network being
   accessed. An example would be the use of 802.1x for authenticating to
   an 802.11 network and PPP authentication in the case of a dial-up
   connection to an ISP. Authentication for network access may be
   performed at a higher layer, either IP or at the application layer.
   This has the advantage of decoupling the association of
   authentication from the access technology. The assumption here is of
   course that link layer connectivity is provided by the access network
   operator.

   This I-D discusses various scenarios where a network or higher layer
   authentication protocol may be deployed.


2.  Terminology

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


     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



                           Expires April, 2003                  [Page 2]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


       to the PANA clients.  At most one PANA client should be
       associated with a DI on a PANA authentication agent.


     Enforcement Point (EP)

       A node where decisions on per-packet enforcement policy are
       enforced for devices by using Device Identifier information
       indicated by a PAA.  Per-packet enforcement includes per-packet
       filtering and may include cryptographic per-packet protection as
       well.


     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 within the scope of PANA.


     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.


     Access Point

       A first-hop L2 attachment point from a PaC device.

     Access Router

       A first-hop router from a PaC device.


3.  Problem Statement

   Access networks which are not physically secured from unintended
   usage usually require clients to go through an authentication and
   authorization process. Network access authentication of clients
   require a protocol between the client and the network to execute one
   or more authentication methods (e.g., CHAP, TLS, SIM, etc.). In the
   light of proliferation of various access technologies (e.g., GPRS,
   IEEE 802.11, DSL, etc.), it is important that the authentication
   methods are not tied to the underlying link-layer. Authentication
   protocol must be able to carry various authentication methods
   regardless of the underlying access technologies.

   An important aspect of an authentication protocol is the ability to
   provide dynamic service provider selection to the clients. Regardless
   of their network access provider (NAP), clients should be able to
   select an Internet access provider (ISP) of their choice. This is
   usually achieved by clients presenting an identifier which carries
   domain information during the authentication process. For example an



                           Expires April, 2003                  [Page 3]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   NAI[RFC2486]: john@anyisp.com. The authentication agent in the access
   network would consult the backend authentication servers in the given
   domain, and the respective ISP service will be used once access is
   authorized. This is also essential in providing roaming service to
   clients. Separation of NAP from ISP, and a single NAP providing
   service for clients from multiple ISPs are made possible by this
   feature.

   Support for various authentication methods, including the ones that
   can provide dynamic service provider selection and roaming can be
   achieved by using an authentication protocol that can carry EAP
   [RFC2284]. EAP acts as an encapsulation of arbitrary authentication
   methods, but it still requires a transport between the client and the
   access network. Among all the link-layers, only IEEE 802 defines how
   to carry EAP on the link-layer [802.1X]. Any other link-layer has to
   resort to using PPP/PPPoE [RFC1661,RFC2516] as a link-layer agnostic
   way of carrying EAP. Inserting this additional layer(s) between the
   link-layer and network-layer to achieve this goal is an inadequate
   method. Using PPP just for client authentication incurs extra round-
   trips, generates overhead of PPP processing for data packets, and
   forces the network topology into a point-to-point model.

   Defining a network-layer transport for EAP would provide a cleaner
   solution to this problem. Such a solution would not only provide
   support of various authentication methods, dynamic service provider
   selection and roaming by carrying EAP, but it will also define a
   link-layer agnostic carrier for this protocol. This goal will be
   achieved without having to incur additional costs and limitations of
   inserting another layer in the stack as in the case of PPP.

   Meanwhile, in the absence of such a standard solution, some
   architectures are forced to design their own ad-hoc solutions to the
   problem. One such solution is the application-layer authentication
   method implemented by http redirects and web-based login. In addition
   to being a non-standard solution, this provides an incomplete network
   access authentication with well-known vulnerabilities, and therefore
   regarded as a stop-gap solution.

   Another method designed to provide network access authentication is
   based on overloading an existing network-layer protocol. Mobile IPv4
   [RFC3344] protocol has a built-in authentication mechanism.
   Regardless of whether mobile nodes need to use a foreign agent in an
   access network, registration via a foreign agent can be required by
   using an appropriate flag in the agent advertisements. This forces
   the nodes to register with a foreign agent, and therefore utilizes
   Mobile IPv4 protocol for network access authentication. Such a
   solution has very limited applicability as a link-layer agnostic
   method since it relies on use of Mobile IPv4 protocol.


4.  Usage Scenarios

   The first three subsections describe PANA usage scenarios categorized
   in terms of lower layer security.  Other subsections describe
   scenarios that are not categorized in terms of lower layer security.





                           Expires April, 2003                  [Page 4]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


4.1.  PANA with Physical Layer Security

   In the networks where a certain degree of security is provided at
   physical layer, authenticating the client is still essential since
   physical layer does not provide information on the client, but per-
   packet authentication and encryption may not necessarily be provided
   at higher layers.  DSL networks that are implemented on top of point-
   to-point phone lines are such an example.  In this type of networks,
   PANA is just used for client authentication and a hook to an
   appropriate access control.

   In DSL networks, there are a number of deployment scenarios with
   regard to client configuration and client authentication.  In DSL
   networks where PPP is used for both configuration and authentication
   (and IP encapsulation), the providers may not require to migrate to
   use PANA.  On the other hand, there are some DSL networks that use
   some configuration method other than PPP, i.e., DHCP or static
   configuration.  Those networks use either an ad-hoc network access
   authentication method such as http-redirect with web-based login or
   no authentication method at all.  A standard, L2 agnostic network
   access authentication is needed for this type of DSL networks and
   PANA can be used to fill the demand.


4.2.  PANA with Link Layer Security

   In certain networks, link layers may be secured by means outside the
   scope of an authentication protocol. A higher layer authentication
   protocol in such cases will provide access authorization. For
   example, web-based login in current Wi-Fi networks. One can enable
   WEP security to protect the authentication messages. However, it is
   also possible that the link layer can be secured following a
   successful authentication by virtue of key exchange or other means.

   Wireless data networks such as, CDMA2000 networks require the
   user/device authentication with the MSC/VLR before providing access
   to the data network. This authentication which is specific to the
   technology.  Hence the link layer is secured following this
   authentication.

   CDMA2000 networks offer two types of data services namely simple IP
   and Mobile IP. Simple IP requires the user to provide authentication
   data via PPP. Radius based AAA is used in the backend to verify the
   credentials provided by the user before allowing network access.
   Currently CDMA2000 networks include PPP as part of the protocol stack
   between the MN and the PDSN (Packet Data serving Node - equivalent to
   the Access Router), and hence are able to rely on PPP functionality
   to authenticate a user accessing the data network. However it is
   possible that future releases of the standard may not use PPP but
   adopt simple framing schemes such as HDLC or variants. In such a
   scenario network access authentication can be done using a protocol
   such as PANA.

   When the MN chooses Mobile IPv4 service, authentication is done by
   the Foreign agent in the PDSN which interacts with the AAA server.
   Authentication data as well as the MNs identity, which is the NAI is
   included in the Mobile IPv4 Registration Request message and the



                           Expires April, 2003                  [Page 5]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   foreign agent then uses the NAI and the data from the MN-AAA auth
   extension in the Radius request message. Only after a successful
   response message from the Radius server is the registration request
   message forwarded to the home agent. This model is combining an IP
   mobility scheme with network access authentication. A better approach
   would be to separate network access and Mobile IPv4. PANA would be
   used to authenticate the user for network access and Mobile IPv4
   messages would be sent after authentication has completed. Such a
   model would enable different authentication schemes to be supported
   since EAP is used rather than relying on just HMAC-MD5 which is the
   default algorithm for the MN-AAA auth extension.  Authentication for
   network access and authentication/authorization for enabling IP
   Mobility should be separated. This can be accomplished by using PANA
   for network access while allowing Mobile IP implementations to adhere
   to the specification [RFC3344].

   The IP mobility solution for IPv6 networks is slightly different from
   the IPv4 networks. When Mobile IPv6 is deployed in such networks, the
   FA would no longer exist and hence the current scheme used would no
   longer work. In such a scenario the MN will have to authenticate
   using another mechanism and PANA is a possible solution.

   Since link layer security is enabled as a result of authentication to
   the MSC/VLR, authentication at an upper layer is an acceptable
   technique.


4.3.  PANA in the Absence of Any Lower Layer Security

   Ethernet links composed of legacy hubs and switches and early
   deployment of Wi-Fi networks (802.11b) do not use link layer
   authentication or security mechanisms such as, 802.1X.  In absence of
   such lower layer security not only providers are unable to control
   the unauthorized use of their networks but also users feel insecure
   while exchanging sensitive information.  In order to support
   authentication functionality in such legacy systems, many providers
   today use a higher-layer authentication scheme, such as http-redirect
   commonly known as web-based login.  In this method, once the link is
   established, users' traffic are re-directed to a web server which in
   turn generates a web-based login forcing users to provide the
   authentication information.  While this method solves the problem
   partially by allowing only authorized users to access the network it
   does not enable the lower layer security such as, per-packet
   authentication and encryption, etc. Moreover, it is a non-standard ad
   hoc solution.

   In such scenarios, a standard network layer solution such as, PANA is
   suitable since it provides link-layer agnostic network access
   authentication.  In fact, PANA can provide support of various
   authentication schemes and also capable of enabling lower layer
   security.  For example, a link can be protected by negotiating
   encryption keys between PaC and PAA after successful authentication.
   Although PANA does not define key distribution protocol or 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.
   This is achievable if authentication carrier protocol that is used by
   PANA supports key distribution mechanism.  Hence, for legacy networks



                           Expires April, 2003                  [Page 6]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   where lower layer authentication and key distribution mechanisms are
   absent PANA could be very useful.  So in a way, PANA can help
   bootstrapping L2 authentication without a pre-shared secret."


4.4.  Mobile IP

   Mobile IPv4 defines its own authentication extensions to authenticate
   and authorize mobile nodes at the foreign agents and home agents. One
   of the possible modes of Mobile IPv4 is when the mobile node uses a
   co-located care-of address and doesn't rely on any mobility
   management functionality of the foreign agent on the access network.
   In this case, mobile node can send its registration request directly
   to the home agent.

   Even in the co-located care-of address case, the protocol has a way
   to require mobile nodes to register with a foreign agent by setting
   Registration-Required bit in the agent advertisements. This forces
   mobile nodes to send their registration requests via foreign agent,
   and therefore gives the foreign agent a chance to authenticate and
   authorize the node for network access.

   This method can only be used in IPv4 networks where every client
   implements mobile node functionality. Even for IPv4 clients, a better
   approach would be to replace this protocol-specific authentication
   method by a common authentication protocol such as PANA. PANA can be
   used with any client regardless of Mobile IPv4 support.

   PANA can also be used with IPv6 clients, or dual-stack clients.
   Mobile IPv6 protocol doesn't define a foreign agent in the access
   networks, therefore it cannot provide any protocol support for access
   authentication. Network access authentication can be handled by PANA
   regardless of IP version of the clients and independent of whether
   they support or use Mobile IP.


4.5.  Personal Area Networks

   A Personal Area Network would consist of one or more routers
   connecting one or more hosts to the Internet. Hosts may also
   communicate directly to each other (e.g. if a shared link is used).
   Communicating through the mobile router is inefficient and could
   waste scarce battery power in such device. This should be limited to
   cases where two hosts do not support the same link layer. It is also
   important that hosts are authorized to communicate to other hosts in
   a PAN or gain access to the Internet via the mobile router. Such
   authentication should be independent of the underlying link layer
   (e.g. more than one link layer may be used in a PAN), but maybe be
   used to bootstrap link layer or IP layer authentication for further
   communication.

   Current cellular systems lack a single authentication mechanism that
   can be used to allow hosts in a PAN (behind a mobile router) to gain
   access to other hosts in a PAN or (simultaneously)to the Internet via
   the mobile router.

   The current 3GPP architecture assumes that a split User Equipment



                           Expires April, 2003                  [Page 7]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   (UE) TE and MT [RFC3314] are possible when PPP is run between them
   for authentication and access control. If more than one device (e.g.
   laptop, PDA ...etc) needs to be connected to the MT (typically mobile
   phone), each one would need to setup a PPP connection to the MT. This
   is a typical case of a Personal Area Network (PAN) trying to connect
   to the Internet via 3GPP network. However, this configuration is
   inefficient; if devices behind the MT need to communicate with each
   other, they can only do so via the MT. Unless some PPP switching is
   done in the MT, packets between these devices will need to go over
   the air interface (WCDMA) and get routed through the network and back
   to the MT. This adds significant cost as a result of bandwidth
   inefficiency and battery consumption in the MT. All these issues
   point towards the need to evolve this architecture towards having a
   multi-access link between the MT and various TEs. Different multi-
   access link layers can be utilized for this scenario. A link layer
   agnostic authentication protocol (PANA) is the main enabler for this
   scenario, as it would allow hosts connected to the MT to authenticate
   themselves to the MT (The MT implements an IP stack) and gain access
   to both, the PAN and the Internet via the MT.

   The use of PANA in this scenario would imply that hosts have a PaC
   function that allows them to authenticate themselves to gain network
   access. A router on this subnet (i.e. the MT interfacing to the 3GPP
   network) would contain a PAA server. In this scenario, there would be
   no need for authorizing devices through consultation with a backend
   AAA server; pre-configured secrets would suffice for such a small
   network.

   Although IKE (with shared secrets or public keys) can be used for
   network access authentication in this scenario with some
   implementation specifics and limitations, it is not designed by
   nature for network access authentication and would require the use of
   IPsec tunnel mode for access control, which is not desired in many
   cases where layer 2 encryption exists.  Using a standardized (layer 2
   independent) protocol specialized for network access (i.e., PANA)
   will better fit this scenario.


4.6.  Limited Free Access

   Certain networks might allow clients to access a limited topology
   without any explicit authentication and authorization. However, the
   policy may be such that an access beyond this topology requires
   authentication and authorization. For example, in an airport network,
   information such as, flight arrival and departure gate numbers,
   airport shops and restaurants, etc., are offered as free services by
   the airlines or airport authorities for their passengers. In order to
   access such information, users can simply plug in their devices into
   the network without performing any authentication. On the other hand,
   access to further services or sites using such local networks
   requires authentication and authorization.  The access network can
   detect such an attempt and initiate authentication. Once users
   perform the authentication it will be allowed to go beyond the free
   access zone.  PANA can be an enabler to such limited free access
   scenarios since PANA authentication is not performed before IP
   address configuration and it also allows the network to initiate the
   authentication whenever appropriate.



                           Expires April, 2003                  [Page 8]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


4.7.  Multiple-Interface Device

   A device can have multiple interfaces of homogeneous or heterogeneous
   technologies.  PANA can be used by such a device as a unified higher-
   layer network access authentication carrier that is independent of
   the types of the interfaces.  There are two possible scenarios for
   PANA: simultaneous activation and interface switching.

   In case of simultaneous activation, the multiple interfaces of a
   device may be activated at the same time for various requirements
   such as increased bandwidth, load balancing and reliability.

   In case of interface switching, one of the multiple interfaces of a
   device is activated at a time and the device may switch from one
   interface to another.

   In both cases, each interface may or may not be connected to the same
   IP subnet.  When each interface is connected to a distinct IP subnet,
   each IP subnet may not be owned by the same service provider, which
   indicates that the simultaneous activation case is related to host
   multihoming.


5.  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

   HDLC: High-level Data Link Control

   MSC: Mobile Switching Center

   MN: Mobile Node

   MT: Mobile Termination

   NAI: Network Access Identifier

   PAA: PANA Authentication Agent

   PaC: PANA Client

   PPP: Point-to-Point Protocol

   TE: Terminal Equipment

   UE: User Equipment




                           Expires April, 2003                  [Page 9]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   VLR: Visiting Location Register


6.  Acknowledgments

   The authors would like to thank James Carlson, Jacques Caron, Paal
   Engelstad, Henry Haverinen, Prakash Jayaraman, James Kempf, Thomas
   Narten, Erik Nordmark, Reinaldo Penno, Phil Roberts, David Spence,
   Barani Subbiah, George Tsirtsis, Cliff Wang 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.

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

   [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.

   [RFC2486] B. Aboba, et al., "The Network Access Identifier", RFC 2486,
       January 1999.

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

   [RFC3314] M. Wasserman et al., "Recommendations for IPv6 in Third
       Generation Partnership Project (3GPP) Standards", RFC 3314, September
       2002.

   [RFC3344] C. Perkins, "IP Mobility Support for IPv4", RFC 3344,
       August 2002.


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
   Email: yohba@tari.toshiba.com

   Subir Das
   MCC 1D210R, Telcordia Technologies
   445 South Street, Morristown, NJ 07960
   Phone: +1 973 829 4959



                           Expires April, 2003                 [Page 10]


Internet-Draft            PANA Usage Scenarios          October 25, 2002


   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
   Email: Hesham.Soliman@era.ericsson.se

   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


































                           Expires April, 2003                 [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/