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]
