Internet Engineering Task Force Alper E. Yegin (Editor)
Internet Draft Yoshihiro Ohba
draft-ietf-pana-requirements-00.txt Reinaldo Penno
Expires: August 3, 2002 George Tsirtsis
Cliff Wang
February 3, 2002
Protocol for Carrying Authentication for
Network Access (PANA)
Requirements and Terminology
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 medias (e.g., 802.1x for IEEE
802 links), some of these protocols are also sub-optimal (e.g., PPP
due to its mandatory framing which is not always needed). The goal
of the PANA Working Group is to design a general network-layer
protocol to authenticate clients to the networks. 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
overloaded with other aspects of the network access (e.g., framing).
This document defines the common terminology and identifies the
requirements for PANA.
Yegin (Editor), et. al. Expires Aug 2002 [Page 1]
Internet Draft PANA Requirements and Terminology Feb 2002
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Key Words.......................................................4
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. Re-authentication...........................................5
4.1.5. Mutual Authentication.......................................6
4.1.6. Identifiers.................................................6
4.2. Network.......................................................6
4.2.1. Multi-access................................................6
4.2.2. Disconnect Indication.......................................6
4.2.3. Location of PAA.............................................6
4.3. Interaction with Other Protocols..............................6
4.4. Performance...................................................7
4.5. Miscellaneous.................................................7
4.5.1. IP Version Independence.....................................7
4.5.2. Reliability and Congestion..................................7
4.5.3. Denial of Service Attacks...................................7
Acknowledgements...................................................7
References.........................................................8
AuthorsÆ Addresses.................................................9
Full Copyright Statement..........................................10
Yegin (Editor), et.al. Expires Aug 2002 [Page 2]
Internet Draft PANA Requirements and Terminology Feb 2002
1. Introduction
Currently there are a variety of access technologies available to
the network clients. While most of the clients currently have single
interface, it is expected that in the future they will have multiple
interfaces of different types to access the network.
An authentication mechanism is needed in order to provide secure
network access to the legitimate clients. Some of the current
authentication mechanisms are access technology specific. For
example 802.1x [8021X] only works for IEEE 802 link layers. If a
client can have more than one type of interface, using access-
specific authentication mechanisms leads to running a collection of
protocols on the client for the same purpose. It is clearly
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 is not
limited to authenticating the clients. It also provides mandatory
PPP framing. Since framing is already supported by certain link
types, having to use this extra framing creates sub-optimal network
access solutions.
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 design a protocol between a
client's device and an agent device in the network where the agent
might be a client of the AAA infrastructure. As a network-layer
protocol, it will be independent of the underlying access
technologies. The protocol design will also be limited to defining a
messaging protocol (i.e., a carrier) for providing the clients'
information to the network for authentication and authorization
purposes. It will not deal with the other aspects of network access
such as framing.
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
Yegin (Editor), et.al. Expires Aug 2002 [Page 3]
Internet Draft PANA Requirements and Terminology Feb 2002
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].
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
Yegin (Editor), et.al. Expires Aug 2002 [Page 4]
Internet Draft PANA Requirements and Terminology Feb 2002
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 a carrier would be the
registration request message of Mobile IPv4 [MIPV4] that carries MN-
FA authentication extension.
Authentication and encryption of data traffic sent to and from an
authenticated PaC is outside the scope of PANA. Providing a complete
secure network access solution by also securing router discovery
[RDISC], neighbor discovery [NDISC], and address resolution
protocols [ARP] is outside the scope as well.
4.1.2. Authorization, Accounting and Access Control
In addition to carrying authentication information, PANA MUST also
carry a binary result (i.e., success or failure) of authorization
for network access to the PaC. Providing finer granularity
authorization is outside the scope of PANA.
Providing access control functionality in the network is outside the
scope of PANA. PAA MAY communicate the DI associated with a PaC to
other entities in the network to setup packet filters and access
control state. This interaction is outside the scope of PANA as
well.
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 authentication protocol or mechanisms.
The interaction between the PAA and the backend authentication
entities is outside the scope of PANA.
4.1.4. Re-authentication
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.
Yegin (Editor), et.al. Expires Aug 2002 [Page 5]
Internet Draft PANA Requirements and Terminology Feb 2002
4.1.5. Mutual Authentication
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.
4.1.6. Identifiers
PANA SHOULD allow various types of identifiers to be used for the
PaC (e.g., NAI, IP address, FQDN, etc.)
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. This binding is used
for access control and accounting in the network as described
in section 4.1.2.
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. PANA SHOULD define a "disconnect"
indication 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
PAA MAY be one or more hop away from the PaC.
4.3. Interaction with Other Protocols
PANA MUST NOT handle mobility management of the PaC. But, it 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
Yegin (Editor), et.al. Expires Aug 2002 [Page 6]
Internet Draft PANA Requirements and Terminology Feb 2002
privacy extensions [PRIVACY]), and DHCP [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. Miscellaneous
4.5.1. IP Version Independence
PANA MUST work for both IPv4 and IPv6.
4.5.2. Reliability and Congestion
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.5.3. 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Æ attempts of
network access. The required robustness is no worse than that for
TCP SYN attack.
Acknowledgements
We would like to thank Basavaraj Patil and Subir Das for their
valuable contributions to the discussions and preparation of this
document.
Yegin (Editor), et.al. Expires Aug 2002 [Page 7]
Internet Draft PANA Requirements and Terminology Feb 2002
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.
[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", draft-ietf-mobileip-lowlatency-handoffs-v4-03,
November 2001.
[FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile
IPv6", draft-ietf-mobileip-fast-mipv6-03.txt, July 2001.
[DHCP] R. Droms (editor), et. al., ôDynamic Host Configuration
Protocol for IPv6ö, draft-ietf-dhc-dhcpv6-22.txt, December 2001.
[PRIVACY] T. Narten, R. Draves, ôPrivacy Extensions for Stateless
Address Autoconfiguration in IPv6ö, RFC 3041, January 2001.
Yegin (Editor), et.al. Expires Aug 2002 [Page 8]
Internet Draft PANA Requirements and Terminology Feb 2002
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
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 Aug 2002 [Page 9]
Internet Draft PANA Requirements and Terminology Feb 2002
Full Copyright Statement
"Copyright (C) The Internet Society (2001). 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 Aug 2002 [Page 10]
