6. Acknowledgements
Authors would like to thank Bernard Aboba, Derek Atkins, Steven
Bellovin, 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.
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. Some DSL deployments do
not use PPP [RFC1661] 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 left either 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. It also 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 in removing 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. The 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). This
enables the use of a mobility-specific protocol for an unrelated
functionality.
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 and is 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.
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 occur as well.
The following five 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). Note that PAA may or may not use AAA
infrastructure to verify the credentials of PaC in order 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).
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 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 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 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 ----- 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 but
separated from PAA. PAA still resides on the same IP link as ARs.
After 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.
References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC4016] Parthasarathy, M., "Protocol for Carrying
Authentication and Network Access (PANA) Threat
Analysis and Security Requirements", RFC 4016, March
2005.
Informative References
[FMIPv4] Malki, K., "Low Latency Handoffs in Mobile IPv4", 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.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[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.
[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.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", Work
in Progress.
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
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
Juniper Networks
10 Technology Park Drive
Westford, MA 01886-3146
USA
EMail: rpenno@juniper.net
George Tsirtsis
Flarion
Bedminster One
135 Route 202/206 South
Bedminster, NJ 07921
USA
Phone: +44 20 88260073
EMail: G.Tsirtsis@Flarion.com
Cliff Wang
ARO/NCSU
316 Riggsbee Farm
Morrisville, NC 27560
USA
Phone: +1 919 548 4207
EMail: cliffwangmail@yahoo.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.