PANA Working Group                               Alper E. Yegin,                               Reinaldo Penno, Editor
INTERNET-DRAFT                                           Yoshihiro Ohba                                           Alper E. Yegin
Date: March June 2002                                         Reinaldo Penno                                          Yoshihiro Ohba
Expires: September December 2002                                  George Tsirtsis
                                                             Cliff Wang

                 Protocol for Carrying Authentication for
                           Network Access (PANA)
                       Requirements and Terminology
                   <draft-ietf-pana-requirements-01.txt>
                   <draft-ietf-pana-requirements-02.txt>

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   It is expected that future IP devices will have a variety of access
   technologies to gain network connectivity. Currently there are
   access-specific mechanisms for providing client information to the
   network for authentication and authorization purposes. In addition
   to being limited to specific access media (e.g., 802.1x for IEEE 802
   links), some of these protocols are limited to specific network
   topologies (e.g., PPP for point-to-point links). The goal of the
   PANA Working Group is to design provide a general network-layer layer two agnostic and IPv4/IPv6 compatible
   client-server protocol that allows a host to
   authenticate clients to the networks. be authenticated for
   network access. The protocol will run between a client's device
   and an agent device in the network where the agent might be a client
   of the AAA infrastructure. The protocol should be
   independent of the underlying access-type and not be limited to
   specific network topologies. This document defines the common
   terminology and identifies the requirements for PANA.

 Yegin (Editor), et. al.         Expires Sep 2002             [Page 1]

Table of Contents

   Status of this Memo...............................................1
   Abstract..........................................................1
   Table of Contents.................................................2
   1. Introduction...................................................2
   2. Key Words......................................................3
   3. Terminology....................................................4
   4. Requirements...................................................4
   4.1. Authentication...............................................4
   4.1.1. Authentication of Client...................................4
   4.1.2. Authorization, Accounting and Access Control...............5
   4.1.3. Authentication Backend.....................................5
   4.1.4. Identifiers................................................5
   4.2. Network......................................................6
   4.2.1. Multi-access...............................................6
   4.2.2. Disconnect Indication......................................6
   4.2.3. Location of PAA............................................6
   4.2.4. Secure Channel.............................................6
   4.3. Interaction with Other Protocols.............................6
   4.4. Performance..................................................7
   4.5. Reliability and Congestion Control...........................7
   4.6. Miscellaneous................................................7
   4.6.1. IP Version Independence....................................7
   4.6.2. Denial of Service Attacks..................................7
   4.6.3. Location Privacy...........................................7
   Acknowledgements..................................................7
   References........................................................8
   Authors∆
   Authors' Addresses................................................9
   Full Copyright Statement.........................................10

1. Introduction

   Currently there are a variety of

   Network access technologies available to for wired and wireless media are
   evolving rapidly. With the network clients. While most rapid growth in the number and type of
   devices and terminals that support IP stacks and can access the clients currently have
   Internet, users can potentially use a single
   interface, it is expected that in device having the future they will have multiple
   interfaces
   capability of attaching via different types to multiple access the network.

   An authentication mechanism is needed in order media and
   technologies to provide secure
   network access interface to the legitimate clients. Some of the current
   authentication mechanisms are access technology specific. For
   example 802.1x [8021X] works for only IEEE 802 link layers. network.

   If a client can have more than one type of interface, using access-
   specific
   access-specific authentication mechanisms leads to running a
   collection of protocols on the client for the same purpose.

   For example, the authentication mechanisms in PPP are being used
   for many wired access scenarios as well as some wireless access,
   which requires using PPP encapsulation for the data packets. Using
   PPP just for client authentication is viewed as a sub-optimal
   solution as it causes extra round-trips, overhead of encapsulation
   and processing,
   and forces the network topology into a point-to-point
   model. A point in case is PPPoE which is used over multi-access
   networks primarily for the purpose of exploiting the authentication
   scheme provided by PPP. Also, IEEE 802 relies on 802.1X which
   provides EAP authentication that is limited to IEEE 802 link layers.

   It is clearly

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 2] advantageous to use a general protocol to authenticate
   the client for network access on any type of technology.

   The most widely used protocol for authenticating clients is the PPP
   [PPP]. This protocol can run on various access types, but it
   provides an inherently point-to-point interface. While it can
   efficiently be applied to such topologies, using PPP with a multi-
   access network creates sub-optimal solutions. Such multi-access
   networks require either a full mesh of PPP links among clients, or a
   designated router as the end-point of PPP links. There is
   currently no general protocol to be used by a client for gaining
   network access, and the PANA Working Group will attempt to
   fill that hole.

   The Working Group will protocol design will be limited to defining a client-server
   messaging protocol between (i.e., a
   client's device carrier) that will allow authentication
   payload to be carried between the host/client (PaC) and an agent device
   agent/server (PAA) in the access network where the agent
   might be a client for authentication and
   authorization purposes regardless of the AAA infrastructure. 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 protocol design will be limited to defining a messaging protocol
   (i.e., a carrier) for providing the clients' information to the
   network for authentication and authorization purposes. The Working Group will not invent new security protocols and
   mechanisms but instead will use the existing mechanisms. In
   particular, the Working Group will not define authentication
   protocols, key distribution or key agreement protocols, or key
   derivation. 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, Mobile IP Working Group has already defined such a
   carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request
   message is used as the carrier for authentication extensions (MN-FA
   [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the
   foreign agents. In that sense, designing the equivalent of Mobile
   IPv4 registration request messages for general network access is the
   goal of this work, but not defining the equivalent of MN-FA or MN-
   AAA extensions.

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

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 3]

3. Terminology

   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, 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. At most one PANA client
         should be associated with a DI on a PANA authentication agent.

   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.

4. Requirements

4.1. Authentication

  4.1.1. Authentication of Client

   PANA MUST authenticate a PaC for network access. A PaC can be
   identified by the credentials (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"). An example of The current thinking is that a carrier sufficient
   solution would be the
   registration request message of Mobile IPv4 [MIPV4] for PANA to carry EAP. If PANA WG decides that carries MN-
   FA authentication extension.
   extensions to EAP are needed, it will define requirements for an
   EAP WG instead of defining these extensions.

   Authentication and encryption of data traffic sent to and from an
   authenticated PaC is outside the scope of PANA. Providing a complete

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 4]
   secure network access solution by also securing router discovery
   [RDISC], neighbor discovery [NDISC], and address resolution
   protocols [ARP] is outside the scope as well.

   Both the PaC and the PAA MUST be able to authenticate each other for
   network access. Providing capability of only PAA authenticating the
   PaC is not sufficient.

   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.

   When the DI is carried explicitly as part of the PANA payload, the
   authentication computation MUST also include this field to provide
   integrity protection for the DI. When the DI is carried implicitly
   as the source of the PANA message, the protocol has to make sure
   that the DI's integrity is protected by some other means (e.g.,
   physical verification of incoming port number of the PANA message in
   the case of switch port number as a DI and PAA co-located with the
   link-layer access device). Protecting PaCs against DI theft is
   outside the scope of PANA.

  4.1.2. Authorization, Accounting and Access Control

   In addition to carrying authentication information, PANA MUST also
   carry
   provides only a binary result (i.e., success or failure) of authorization
   for network access to indicate whether the PaC. PaC
   is allowed to access full IP services on the network. Providing
   finer granularity
   authorization authorization, such as negotiating QoS parameters,
   authorizing individual services (http vs. ssh), individual users
   sharing the same device, etc. is outside the scope of PANA.

   Providing access control functionality in the network is outside the
   scope of PANA. PAA MAY communicate 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 DI associated with a PaC enforcement
   points. Identification of clients which are authorized to
   other entities in access
   the network is done by the PANA protocol exchange. Though,
   transporting the required information to setup access control and accounting
   state. This interaction the enforcement points in
   the network is outside the scope of PANA as well. well since PANA assumes
   the PAA is co-located with the enforcement point.

   Carrying accounting data is outside the scope of PANA.

  4.1.3. Authentication Backend

   PAA MAY use either a AAA backend, some other mechanism or a local
   database to authenticate the PaC.

   PANA protocol MUST NOT make any assumptions on the backend backend
   authentication protocol or mechanisms. PAA may interact with
   backend AAA infrastructures such as RADIUS or Diameter, but it is
   not a requirement. When the access network doesn't rely on a
   IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can
   still use a proprietary backend system, or rely on the information
   locally stored on the authentication protocol or mechanisms. 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 for the
   PaC (e.g., NAI, IP address, FQDN, etc.)

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 5]

   PANA SHOULD allow various types of identifiers to be used as the DI
   (IP address, link-layer address, port number of a switch, etc.)

   PAA MUST be able to create a binding between the PaC and the
   associated DI upon successful PANA exchange. The DI MUST be carried
   either explicitly as part of the PANA payload, or implicitly as the
   source of the PANA message, or both. This binding is used for access
   control and accounting in the network as described in section 4.1.2.

  4.1.5. IP Address Assignment

   PANA does not perform any address assignment functions but MUST
   only be invoked after the client has a usable IP address
   (e.g., a link-local address in IPv6 or a DHCP-learned address
   in IPv4)

4.2. Network

  4.2.1. Multi-access

   Protocol MUST support PaCs with multiple interfaces, and networks
   with multiple routers on multi-access links.

  4.2.2. Disconnect Indication

   PANA MUST NOT assume connection-oriented links. 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 will need to provide a
   hearbeat-type mechanism to provide this functionality. It's
   usage will be optional, depending on the specific L2.

   PANA SHOULD define provide a "disconnect"
   indication hearbeat-type mechanism to allow PaCs to
   notify the PAA of their departure from the network. A similar
   indication SHOULD also be used to let PAA notify a PaC about the
   discontinuation of the network access. Access discontinuation
   can happen due to various reasons such as network systems going
   down, or a change in access policy.

4.2.3. Location of PAA

   The PAA MAY must be one on an IP capable network element on the same
   IP link as the PaC. Hence it can be on the NAS or more WLAN AP or first
   hop away from router (most likely scenario). The use of PANA when the PaC. PAA is
   not on the same link as the PAA is outside the scope of PANA.

   Since a PaC maynot be pre-configured with the IP address of PAA,
   but may have to dynamically discover instead. Therefore PANA MUST
   protocol must define a
   method dynamic discovery method. Given that
   the PAA is on the same link as the PaC, there are number
   of discovery techniques that could be used (e.g., multicast or
   anycast) by PaCs for locating the PAAs PaC to find out the address of the PAA.

   Also, PANA assumes the PAA is co-located with the enforcement
   point. 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 a network. the access domain (e.g., gateway to the
   Internet, depending on the network architecture). When the PAA and
   the enforcement point(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 on the enforcement points. This transport is outside the
   scope of PANA.

4.2.4. Secure Channel

   PANA MUST not assume 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 provide protection against replay attacks on both PaCs and
   PAAs.

4.3. Interaction with Other Protocols

   Mobility management is outside the scope of PANA. Though, PANA MUST
   be able to co-exist and not interfere with various mobility
   management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6
   [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other
   standard protocols like IPv6 stateless address auto-configuration
   [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 6]
   [DHCP]. It MUST NOT make any assumptions on the protocols or
   mechanisms used for IP address configuration of the PaC.

4.4. Performance

   PANA design SHOULD give consideration to efficient handling of
   authentication process. This is important for gaining network access
   with minimum latency. As an example, a method like minimizing the
   protocol signaling by creating local security associations can be
   used for this purpose.

4.5. Reliability and Congestion Control

   PANA MUST provide reliability and congestion control. It can do so
   by using techniques like re-transmissions, cyclic redundancy check,
   delayed initialization and exponential back-off.

4.6. Miscellaneous

  4.6.1. IP Version Independence

   PANA MUST work for both IPv4 and IPv6.

  4.6.2. Denial of Service Attacks

   PANA MUST be robust against a class of DoS attacks such as blind
   masquerade attacks through IP spoofing that swamp the PAA in
   spending much resources and prevent legitimate clients∆ clients› attempts of
   network access. The required robustness is no worse than that for
   TCP SYN attack.

  4.6.3. Location Privacy

   Location privacy is outside the scope of PANA.

Acknowledgements

   We would like to thank Basavaraj Patil, Subir Das, and the PANA
   Working Group members for their valuable contributions to the
   discussions and preparation of this document.

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 7]

References

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

   [8021X] "IEEE Standards for Local and Metropolitan Area Networks:
   Port Based Network Access Control", IEEE Draft 802.1X/D11, March
   2001.

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

   [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002,
   October 1996.

   [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
   draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress.

   [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response
   Extensions", RFC3012, November 2000.

   [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256,
   September 1991.

   [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
   for IP Version 6 (IPv6)",RFC 2461, December 1998.

   [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37,
   RFC 826, November 1982.

   [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in
   Mobile IPv4", November 2001. Work in progress.

   [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile
   IPv6", July 2001. Work in progress.

   [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration
   Protocol for IPv6", December 2001. Work in progress.

   [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless
   Address Autoconfiguration in IPv6", RFC 3041, January 2001.

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 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
   2305 Mission College Boulevard
   4555 Great America Parkway
   Santa Clara, CA, 95054
   USA
   Phone: +1 408 565 3023
   Email: rpenno@nortelnetworks.com

   George Tsirtsis
   Flarion Technologies
   Bedminster One
   135 Route 202/206 South
   Bedminster, NJ, 07921
   USA
   Phone : +44 20 88260073
   E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com

   Cliff Wang
   Smart Pipes
   565 Metro Place South
   Dublin, OH, 43017
   USA
   Phone: +1 614 923 6241
   Email: cwang@smartpipes.com

 Yegin (Editor), et.al.        Expires Sep 2002               [Page 9]

Full Copyright Statement

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