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

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4058

Network Working Group                                      A. Yegin, Ed.
Internet-Draft                                               Samsung AIT
Expires: December 9, 2004                                        Y. Ohba
                                                                 Toshiba
                                                                R. Penno
                                                         Nortel Networks
                                                             G. Tsirtsis
                                                                 Flarion
                                                                 C. Wang
                                                                ARO/NCSU
                                                           June 10, 2004


     Protocol for Carrying Authentication for Network Access (PANA)
                              Requirements
                  draft-ietf-pana-requirements-08.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on December 9, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   It is expected that future IP devices will have a variety of access



Yegin, et al.           Expires December 9, 2004                [Page 1]

Internet-Draft             PANA Requirements                   June 2004


   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1   Authentication . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1   Authentication of Client . . . . . . . . . . . . . . .  6
       4.1.2   Authorization, Accounting and Access Control . . . . .  7
       4.1.3   Authentication Backend . . . . . . . . . . . . . . . .  8
       4.1.4   Identifiers  . . . . . . . . . . . . . . . . . . . . .  8
     4.2   IP Address Assignment  . . . . . . . . . . . . . . . . . .  9
     4.3   EAP Lower Layer Requirements . . . . . . . . . . . . . . .  9
     4.4   PAA-to-EP Protocol . . . . . . . . . . . . . . . . . . . .  9
     4.5   Network  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.5.1   Multi-access . . . . . . . . . . . . . . . . . . . . . 10
       4.5.2   Disconnect Indication  . . . . . . . . . . . . . . . . 10
       4.5.3   Location of PAA  . . . . . . . . . . . . . . . . . . . 10
       4.5.4   Secure Channel . . . . . . . . . . . . . . . . . . . . 11
     4.6   Interaction with Other Protocols . . . . . . . . . . . . . 11
     4.7   Performance  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.8   Congestion Control . . . . . . . . . . . . . . . . . . . . 11
     4.9   IP Version Independence  . . . . . . . . . . . . . . . . . 12
     4.10  Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
     4.11  Client Identity Privacy  . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 16
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   A.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . . 19
   B.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 24




Yegin, et al.           Expires December 9, 2004                [Page 2]

Internet-Draft             PANA Requirements                   June 2004


1.  Introduction

   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.
   See Appendix for the associated problem statement.

   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 [RFC2284]
   [I-D.ietf-eap-rfc2284bis].  In particular, the requirements do not
   mandate the need to define new authentication protocols (e.g.,
   EAP-TLS [RFC2716]), 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 [RFC3344].  A Mobile IPv4 registration
   request message is used as a carrier for authentication extensions
   (MN-FA [RFC3344] or MN-AAA [RFC3012]) 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.

   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.







Yegin, et al.           Expires December 9, 2004                [Page 3]

Internet-Draft             PANA Requirements                   June 2004


2.  Requirements notation

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














































Yegin, et al.           Expires December 9, 2004                [Page 4]

Internet-Draft             PANA Requirements                   June 2004


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 [RFC2794] 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, et al.           Expires December 9, 2004                [Page 5]

Internet-Draft             PANA Requirements                   June 2004


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



Yegin, et al.           Expires December 9, 2004                [Page 6]

Internet-Draft             PANA Requirements                   June 2004


   router discovery  [RFC1256], neighbor discovery [RFC2461], and
   address resolution protocols [RFC1982] is outside the scope as well.

   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
   [I-D.ietf-pana-threats-eval].  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 by 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.




Yegin, et al.           Expires December 9, 2004                [Page 7]

Internet-Draft             PANA Requirements                   June 2004


   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 the 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
   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
   [I-D.ietf-pana-threats-eval].  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



Yegin, et al.           Expires December 9, 2004                [Page 8]

Internet-Draft             PANA Requirements                   June 2004


   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.
   PaC MUST configure an IP address before running 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 [I-D.ietf-eap-rfc2284bis] 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 end of a
   successful PANA exchange without the EP ever sending a request.





Yegin, et al.           Expires December 9, 2004                [Page 9]

Internet-Draft             PANA Requirements                   June 2004


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 the 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.  A
   PAA can be on the NAS (network access server) or WLAN access point or
   first hop router.  The use of PANA when the PAA is multiple IP hops
   away from the PaC is outside the scope of PANA.

   A PaC may 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.




Yegin, et al.           Expires December 9, 2004               [Page 10]

Internet-Draft             PANA Requirements                   June 2004


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 [RFC3344],
   Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols
   [I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff],
   and other standard protocols like IPv6 stateless address
   auto-configuration  [RFC2461] (including privacy extensions
   [RFC3041]), and DHCP [RFC2131][RFC3315].  It MUST NOT make any
   assumptions on the protocols or mechanisms used for IP address
   configuration of the PaC.

4.7  Performance

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

4.8  Congestion Control

   PANA MUST provide congestion control for the protocol messaging.
   Under certain conditions PaCs might unintentionally get synchronized
   when sending their requests to the PAA (e.g., upon recovering from a
   power outage on the access network).  The network congestion
   generated from such events can be avoided by using techniques like



Yegin, et al.           Expires December 9, 2004               [Page 11]

Internet-Draft             PANA Requirements                   June 2004


   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.






























Yegin, et al.           Expires December 9, 2004               [Page 12]

Internet-Draft             PANA Requirements                   June 2004


5.  IANA Considerations

   This document has no actions for IANA.
















































Yegin, et al.           Expires December 9, 2004               [Page 13]

Internet-Draft             PANA Requirements                   June 2004


6.  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
   [I-D.ietf-pana-threats-eval].  Security threats identified in that
   document are already included in this general PANA requirements
   document.









































Yegin, et al.           Expires December 9, 2004               [Page 14]

Internet-Draft             PANA Requirements                   June 2004


7.  Acknowledgements

   Authors would like to thank Bernard Aboba, Derek Atkins, Julien
   Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann,
   Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil,
   Hesham Soliman, and the PANA Working Group members for their valuable
   contributions to the discussions and preparation of this document.












































Yegin, et al.           Expires December 9, 2004               [Page 15]

Internet-Draft             PANA Requirements                   June 2004


8.  References

8.1  Normative References

   [I-D.ietf-pana-threats-eval]
              Parthasarathy, M., "PANA Threat Analysis and security
              requirements", draft-ietf-pana-threats-eval-04 (work in
              progress), May 2003.

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

   [RFC2284]  Blunk, L. and J. Vollbrecht, "PPP Extensible
              Authentication Protocol (EAP)", RFC 2284, March 1998.

8.2  Informative References

   [I-D.ietf-eap-rfc2284bis]
              Blunk, L., "Extensible Authentication Protocol (EAP)",
              draft-ietf-eap-rfc2284bis-09 (work in progress), February
              2004.

   [I-D.ietf-mipshop-fast-mipv6]
              Koodli, R., "Fast Handovers for Mobile IPv6",
              draft-ietf-mipshop-fast-mipv6-01 (work in progress),
              February 2004.

   [I-D.ietf-mobileip-ipv6]
              Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
              in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress),
              July 2003.

   [I-D.ietf-mobileip-lowlatency-handoff]
              Malki, K., "Low latency Handoffs in Mobile IPv4",
              draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in
              progress), June 2004.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X, September 2001.

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

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




Yegin, et al.           Expires December 9, 2004               [Page 16]

Internet-Draft             PANA Requirements                   June 2004


   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

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

   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
              Protocol", RFC 2716, October 1999.

   [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
              Identifier Extension for IPv4", RFC 2794, March 2000.

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

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.

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


Authors' Addresses

   Alper E. Yegin (editor)
   Samsung Advanced Institute of Technology
   75 West Plumeria Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 544 5656
   EMail: alper.yegin@samsung.com










Yegin, et al.           Expires December 9, 2004               [Page 17]

Internet-Draft             PANA Requirements                   June 2004


   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5305
   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
   Bedminster One
   135 Route 202/206 South
   Bedminster, NJ  07921
   USA

   Phone: +44 20 88260073
   EMail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com


   Cliff Wang
   ARO/NCSU
   316 Riggsbee Farm
   Morrisville, NC  27560
   USA

   Phone: +1 919 548 4207
   EMail: cliffwangmail@yahoo.com












Yegin, et al.           Expires December 9, 2004               [Page 18]

Internet-Draft             PANA Requirements                   June 2004


Appendix A.  Problem Statement

   Access networks in most cases require some form of authentication in
   order to prevent unauthorized usage.  In the absence of physical
   security (and sometimes in addition to it) a higher layer (L2+)
   access authentication mechanism is needed.  Depending on the
   deployment scenarios, a number of features are expected from the
   authentication mechanism.  For example, support for various
   authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming,
   network service provider discovery and selection, separate
   authentication for access (L1+L2) service provider and ISP (L3), etc.
   In the absence of a link-layer authentication mechanism that can
   satisfy these needs, operators are forced to either use non-standard
   ad-hoc solutions at layers above the link, insert additional shim
   layers for authentication, or misuse some of the existing protocols
   in ways that were not intended by design.  PANA will be developed to
   fill this gap by defining a standard network-layer access
   authentication protocol.  As a network-layer access authentication
   protocol, PANA can be used over any link-layer that supports IP.

   DSL networks are a specific example where PANA has the potential for
   addressing some of the deployment scenarios therein.  Some DSL
   deployments do not use PPP as the access link-layer (IP is carried
   over ATM and the subscriber device is either statically- or
   DHCP-configured).  The operators of these networks are either left
   with using an application-layer web-based login (captive portal)
   scheme for subscriber authentication, or providing a best-effort
   service only as they cannot perform subscriber authentication
   required for the differentiated services.  The captive portal scheme
   is a non-standard solution that has various limitations and security
   flaws.

   PPP-based authentication can provide some of the required
   functionality.  But using PPP only for authentication is not a good
   choice, as it incurs additional messaging during the connection setup
   and extra per-packet processing, and it forces the network topology
   to a point-to-point model.  Aside from resistance to incorporating
   PPP into an architecture unless it is absolutely necessary, there is
   even interest in the community to remove PPP from some of the
   existing architectures and deployments (e.g., 3GPP2, DSL).

   Using Mobile IPv4 authentication with a foreign agent instead of
   proper network access authentication is an example of protocol
   misuse.  Registration Required flag allows a foreign agent to force
   authentication even when the agent is not involved in any Mobile IPv4
   signalling (co-located care-of address case), hence enabling the use
   of a mobility-specific protocol for an unrelated functionality.




Yegin, et al.           Expires December 9, 2004               [Page 19]

Internet-Draft             PANA Requirements                   June 2004


   PANA will carry EAP above IP in order to enable any authentication
   method on any link-layer.  EAP can already be carried by IEEE 802.1X
   and PPP.  IEEE 802.1X can only be used on unbridged IEEE 802 links,
   hence it only applies to limited link types.  Inserting PPP between
   IP and a link-layer can be perceived as a way to enable EAP over that
   particular link-layer, but using PPP for this reason has the
   aforementioned drawbacks, hence not a good choice.  While IEEE 802.1X
   and PPP can continue to be used in their own domains, they do not
   take away the need to have a protocol like PANA.










































Yegin, et al.           Expires December 9, 2004               [Page 20]

Internet-Draft             PANA Requirements                   June 2004


Appendix B.  Usage Scenarios

   PANA will be applicable to various types of networks.  Based on the
   presence of lower-layer security prior to running PANA, the following
   types cover all possibilities:

   a) Physically secured networks (e.g., DSL networks).  Although data
   traffic is always carried over a physically secured link, the client
   might need to be authenticated and authorized when accessing the IP
   services.

   b) Networks where L1-L2 is already cryptographically secured before
   enabling IP (e.g., cdma2000 networks).  Although the client is
   authenticated on the radio link before enabling ciphering, it
   additionally needs to get authenticated and authorized for accessing
   the IP services.

   c) No lower-layer security present before enabling IP.  PANA is run
   in an insecure network.  PANA-based access authentication is used to
   bootstrap cryptographic per-packet authentication and integrity
   protection.

   PANA is applicable to not only large-scale operator deployments with
   full AAA infrastructure, but also to small disconnected deployments
   like home networks and personal area networks.

   Since PANA enables decoupling AAA from the link-layer procedures,
   network access authentication does not have to take place during the
   link establishment.  This allows deferring client authentication
   until the client attempts to access differentiated services (e.g.,
   high bandwidth, unlimited access, etc.) in some deployments.
   Additionally multiple simultaneous network access sessions over the
   same link-layer connection can be realized as well.

   Following scenarios 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).  Five 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.

   Scenario 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.  This might be the case
   where PAA is co-located with the L2 access device (e.g., an
   IP-capable switch).



Yegin, et al.           Expires December 9, 2004               [Page 21]

Internet-Draft             PANA Requirements                   June 2004


               PaC -----EP/PAA--+
                                |
                                +------ AR ----- (AAA)
                                |
               PaC -----EP/PAA--+

        Figure 1: PAA co-located with EP but separated from AR.

   Scenario 2: PAA co-located with AR but separated from EP

   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.  Access
   control parameters have to be distributed to the respective
   enforcement points so that the corresponding device on which PaC is
   authenticated can access to the network.  A separate protocol is
   needed between PAA and EP to carry access control parameters.

              PaC  ----- EP --+
                              |
                              +------ AR/PAA --- (AAA)
                              |
              PaC  ----- EP --+

         Figure 2: PAA co-located with AR but separated from EP

   Scenario 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 ----- EP/PAA/AR--+
                                   |
                                   +-------(AAA)
                                   |
              PaC ----- EP/PAA/AR--+

                Figure 3: PAA co-located with EP and AR.

   Scenario 4: Separated PAA, EP, and AR

   In this scenario, PAA is neither co-located with EPs nor with ARs.
   It still resides on the same IP link as ARs.  After the 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.





Yegin, et al.           Expires December 9, 2004               [Page 22]

Internet-Draft             PANA Requirements                   June 2004


                PaC ----- EP -----+--- AR ---+
                                  |          |
                PaC ----- EP --- -+          |
                                  |          |
                PaC ----- EP -----+--- AR -- + ----(AAA)
                                  |
                                  +--- PAA

                  Figure 4: PAA, EP and AR separated.

   Scenario 5: PAA separated from co-located EP and AR

   In this scenario, EP and AR are co-located with each other bu
   separated from PAA.  PAA still resides on the same IP link as ARs.
   After the 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 --------------+--- AR/EP ---+
                                  |             |
                PaC --------------+             |
                                  |             |
                PaC --------------+--- AR/EP -- + ----(AAA)
                                  |
                                  +--- PAA

                Figure 5: PAA separated from EP and AR.
























Yegin, et al.           Expires December 9, 2004               [Page 23]

Internet-Draft             PANA Requirements                   June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Yegin, et al.           Expires December 9, 2004               [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/