summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5193.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5193.txt')
-rw-r--r--doc/rfc/rfc5193.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5193.txt b/doc/rfc/rfc5193.txt
new file mode 100644
index 0000000..3a12f0e
--- /dev/null
+++ b/doc/rfc/rfc5193.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group P. Jayaraman
+Request for Comments: 5193 Net.Com
+Category: Informational R. Lopez
+ Univ. of Murcia
+ Y. Ohba, Ed.
+ Toshiba
+ M. Parthasarathy
+ Nokia
+ A. Yegin
+ Samsung
+ May 2008
+
+
+Protocol for Carrying Authentication for Network Access (PANA) Framework
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ This document defines the general Protocol for Carrying
+ Authentication for Network Access (PANA) framework functional
+ elements, high-level call flow, and deployment environments.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Specification of Requirements ..............................2
+ 2. General PANA Framework ..........................................2
+ 3. Call Flow .......................................................5
+ 4. Environments ....................................................6
+ 5. Security Considerations .........................................8
+ 6. Acknowledgments .................................................8
+ 7. References ......................................................8
+ 7.1. Normative References .......................................8
+ 7.2. Informative References .....................................9
+
+
+
+
+
+
+
+
+
+
+
+
+Jayaraman, et al. Informational [Page 1]
+
+RFC 5193 PANA Framework May 2008
+
+
+1. Introduction
+
+ PANA (Protocol for carrying Authentication for Network Access) is a
+ link-layer agnostic network access authentication protocol that runs
+ between a client that wants to gain access to the network and a
+ server on the network side. PANA defines a new Extensible
+ Authentication Protocol (EAP) [RFC3748] lower layer that uses IP
+ between the protocol end points.
+
+ The motivation to define such a protocol and the requirements are
+ described in [RFC4058]. Protocol details are documented in
+ [RFC5191]. Upon following a successful PANA authentication, per-
+ data-packet security can be achieved by using physical security,
+ link-layer ciphering, or IPsec [PANA-IPSEC]. The server
+ implementation of PANA may or may not be colocated with the entity
+ enforcing the per-packet access control function. When the server
+ for PANA and per-packet access control entities are separate, a
+ protocol (e.g., [ANCP-PROTO]) may be used to carry information
+ between the two nodes.
+
+ PANA is intended to be used in any access network regardless of the
+ underlying security. For example, the network might be physically
+ secured, or secured by means of cryptographic mechanisms after the
+ successful client-network authentication. While it is mandatory for
+ a PANA deployment to implement behavior that ensures the integrity of
+ PANA messages when the EAP method produces MSK, it is not mandatory
+ to implement support for network security at the link-layer or
+ network-layer.
+
+ This document defines the general framework for describing how these
+ various PANA and other network access authentication elements
+ interact with each other, especially considering the two basic types
+ of deployment environments (see Section 4).
+
+1.1. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized. 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].
+
+2. General PANA Framework
+
+ PANA is designed to facilitate the authentication and authorization
+ of clients in access networks. PANA is an EAP [RFC3748] lower layer
+ that carries EAP authentication methods encapsulated inside EAP
+ between a client node and a server in the access network. While PANA
+
+
+
+Jayaraman, et al. Informational [Page 2]
+
+RFC 5193 PANA Framework May 2008
+
+
+ enables the authentication process between the two entities, it is
+ only a part of an overall AAA (Authentication, Authorization and
+ Accounting) and access control framework. A AAA and access control
+ framework using PANA is comprised of four functional entities.
+
+ Figure 1 illustrates these functional entities and the interfaces
+ (protocols, APIs) among them.
+
+ RADIUS,
+ Diameter,
+ +-----+ PANA +-----+ LDAP, API, etc. +-----+
+ | PaC |<----------------->| PAA |<------------------->| AS |
+ +-----+ +-----+ +-----+
+ ^ ^
+ | |
+ | +-----+ |
+ IKE, +-------->| EP |<--------+ ANCP, API, etc.
+ 4-way handshake, +-----+
+ etc. .
+ .
+ .
+ v
+ Data traffic
+
+ Figure 1: PANA Functional Model
+
+ PANA Client (PaC):
+
+ The PaC is the client implementation of PANA. This entity resides
+ on the node that is requesting network access. PaCs can be end
+ hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers
+ that are connected to a network via a wired or wireless interface.
+ A PaC is responsible for requesting network access and engaging in
+ the authentication process using PANA.
+
+ PANA Authentication Agent (PAA):
+
+ The PAA is the server implementation of PANA. A PAA is in charge
+ of interfacing with the PaCs for authenticating and authorizing
+ them for the network access service.
+
+ The PAA consults an authentication server in order to verify the
+ credentials and rights of a PaC. If the authentication server
+ resides on the same node as the PAA, an API is sufficient for this
+ interaction. When they are separated (a much more common case in
+ public access networks), a protocol needs to run between the two.
+ AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
+ commonly used for this purpose.
+
+
+
+Jayaraman, et al. Informational [Page 3]
+
+RFC 5193 PANA Framework May 2008
+
+
+ The PAA is also responsible for updating the access control state
+ (i.e., filters) depending on the creation and deletion of the
+ authorization state. The PAA communicates the updated state to
+ the Enforcement Points (EPs) in the network. If the PAA and EP
+ are residing on the same node, an API is sufficient for this
+ communication. Otherwise, a protocol is required to carry the
+ authorized client attributes from the PAA to the EP.
+
+ The PAA resides on a node that is typically called a NAS (network
+ access server) in the access network. For example, on a BRAS
+ (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
+ (Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may
+ be one or more IP hops away from the PaCs.
+
+ Authentication Server (AS):
+
+ The server implementation that is in charge of verifying the
+ credentials of a PaC that is requesting the network access
+ service. The AS receives requests from the PAA on behalf of the
+ PaCs, and responds with the result of verification together with
+ the authorization parameters (e.g., allowed bandwidth, IP
+ configuration, etc). This is the server that terminates the EAP
+ and the EAP methods. The AS might be hosted on the same node as
+ the PAA, on a dedicated node on the access network, or on a
+ central server somewhere in the Internet.
+
+ Enforcement Point (EP):
+
+ The access control implementation that is in charge of allowing
+ access (data traffic) of authorized clients while preventing
+ access by others. An EP learns the attributes of the authorized
+ clients from the PAA.
+
+ The EP uses non-cryptographic or cryptographic filters to
+ selectively allow and discard data packets. These filters may be
+ applied at the link layer or the IP layer [PANA-IPSEC]. When
+ cryptographic access control is used, a secure association
+ protocol [RFC3748] needs to run between the PaC and EP. After
+ completion of the secure association protocol, link- or network-
+ layer per-packet security (for example TKIP, IPsec ESP) is enabled
+ for integrity protection, data origin authentication, replay
+ protection, and optionally confidentiality protection.
+
+ An EP is located between the access network (the topology within
+ reach of any client) and the accessed network (the topology within
+ reach of only authorized clients). It must be located
+ strategically in a local area network to minimize the access of
+ unauthorized clients. It is recommended but not mandated that the
+
+
+
+Jayaraman, et al. Informational [Page 4]
+
+RFC 5193 PANA Framework May 2008
+
+
+ EP be on the path between the PaC and the PAA for the
+ aforementioned reason. For example, the EP can be hosted on the
+ switch that is directly connected to the clients in a wired
+ network. That way the EP can drop unauthorized packets before
+ they reach any other client node or nodes beyond the local area
+ network.
+
+ Some of the entities may be colocated depending on the deployment
+ scenario. For example, the PAA and EP would be on the same node
+ (BRAS) in DSL networks. In that case, a simple API is sufficient
+ between the PAA and EP. In small enterprise deployments, the PAA and
+ AS may be hosted on the same node (access router) that eliminates the
+ need for a protocol run between the two. The decision to colocate
+ these entities or otherwise, and their precise location in the
+ network topology, are deployment decisions that are out of the scope
+ of this document.
+
+3. Call Flow
+
+ Figure 2 illustrates the signaling flow for authorizing a client for
+ network access.
+
+ PaC EP PAA AS
+ | | | |
+ IP address ->| | | |
+ config. | PANA | | AAA |
+ |<------------------------------>|<-------------->|
+ | | Provisioning | |
+ (Optional) | |<-------------->| |
+ IP address ->| | | |
+ reconfig. | Sec.Assoc. | | |
+ |<------------->| | |
+ | | | |
+ | Data traffic | | |
+ |<-----------------> | |
+ | | | |
+
+ Figure 2: PANA Signaling Flow
+
+ The EP on the access network allows general data traffic from any
+ authorized PaC, whereas it allows only a limited type of traffic
+ (e.g., PANA, DHCP, router discovery, etc.) for the unauthorized PaCs.
+ This ensures that the newly attached clients have the minimum access
+ service to engage in PANA and get authorized for the unlimited
+ service.
+
+ The PaC dynamically or statically configures an IP address prior to
+ running PANA. After the successful PANA authentication, depending on
+
+
+
+Jayaraman, et al. Informational [Page 5]
+
+RFC 5193 PANA Framework May 2008
+
+
+ the deployment scenario, the PaC may need to re-configure its IP
+ address or configure additional IP address(es). For example, a
+ link-local IPv6 address may be used for PANA and the PaC may be
+ allowed to configure additional global IPv6 address(es) upon
+ successful authentication. Another example: A PaC may be limited to
+ using an IPv4 link-local address during PANA, and allowed to
+ reconfigure its interface with a non-link-local IPv4 address after
+ the authentication. General-purpose applications cannot use the
+ interface until PANA authentication succeeds and appropriate IP
+ address configuration takes place.
+
+ An initially unauthorized PaC starts PANA authentication by
+ discovering the PAA, followed by the EAP exchange over PANA. The PAA
+ interacts with the AS during this process. Upon receiving the
+ authentication and authorization result from the AS, the PAA informs
+ the PaC about the result of its network access request.
+
+ If the PaC is authorized to gain access to the network, the PAA also
+ sends the PaC-specific attributes (e.g., IP address, cryptographic
+ keys, etc.) to the EP by using another protocol. The EP uses this
+ information to alter its filters to allow data traffic from and to
+ the PaC to pass through.
+
+ In case cryptographic access control needs to be enabled after PANA
+ authentication, a secure association protocol runs between the PaC
+ and the EP. Dynamic parameters required for that protocol (e.g.,
+ endpoint identity, shared secret) are derived from successful PANA
+ authentication; these parameters are used to authenticate the PaC to
+ the EP and vice-versa as part of creating the security association.
+ For example, see [PANA-IPSEC] for how it is done for IKE [RFC2409]
+ [RFC4306] based on using a key-generating EAP method for PANA between
+ the PaC and PAA. The secure association protocol exchange produces
+ the required security associations between the PaC and the EP to
+ enable cryptographic data traffic protection. Per-packet
+ cryptographic data traffic protection introduces additional per-
+ packet overhead but the overhead exists only between the PaC and EP
+ and will not affect communications beyond the EP.
+
+ Finally, filters that are installed at the EP allow general purpose
+ data traffic to flow between the PaC and the intranet/Internet.
+
+4. Environments
+
+ PANA can be used on any network environment whether there is a
+ lower-layer secure channel between the PaC and the EP prior to PANA,
+ or one has to be enabled upon successful PANA authentication.
+
+
+
+
+
+Jayaraman, et al. Informational [Page 6]
+
+RFC 5193 PANA Framework May 2008
+
+
+ With regard to network access authentication, two types of networks
+ need to be considered:
+
+ a. Networks where a secure channel is already available prior to
+ running PANA
+
+ This type of network is characterized by the existence of
+ protection against spoofing and eavesdropping. Nevertheless, user
+ authentication and authorization is required for network
+ connectivity.
+
+ a.1. One example is a DSL network where lower-layer security is
+ provided by a physical means. Physical protection of the
+ network wiring ensures that practically there is only one
+ client that can send and receive IP packets on the link.
+
+ a.2. Another example is a cdma2000 network where the lower-layer
+ security is provided by means of cryptographic protection.
+ By the time the client requests access to the network-layer
+ services, it is already authenticated and authorized for
+ accessing the radio channel, and link-layer ciphering is
+ enabled.
+
+ The presence of a secure channel before the PANA exchange
+ eliminates the need for executing a secure association protocol
+ after PANA. The PANA session can be associated with the
+ communication channel it was carried over. Also, the choice of
+ EAP authentication method depends on the presence of this security
+ while PANA is running.
+
+ b. Networks where a secure channel is created after running PANA
+
+ These are the networks where there is no lower-layer protection
+ prior to running PANA. Successful PANA authentication enables the
+ generation of cryptographic keys that are used with a secure
+ association protocol to enable per-packet cryptographic
+ protection.
+
+ PANA authentication is run on an insecure channel that is
+ vulnerable to eavesdropping and spoofing. The choice of EAP
+ method must be resilient to the possible attacks associated with
+ such an environment. Furthermore, the EAP method must be able to
+ create cryptographic keys that will later be used by the secure
+ association protocol.
+
+
+
+
+
+
+
+Jayaraman, et al. Informational [Page 7]
+
+RFC 5193 PANA Framework May 2008
+
+
+ Whether to use
+
+ b.1. link-layer per-packet security or
+
+ b.2. network-layer per-packet security
+
+ is a deployment decision and outside the scope of this document.
+ This decision also dictates the choice of the secure association
+ protocol. If link-layer protection is used, the protocol would be
+ link-layer specific. If IP-layer protection is used, the secure
+ association protocol would be IKE and the per-packet security
+ would be provided by IPsec AH/ESP regardless of the underlying
+ link-layer technology.
+
+5. Security Considerations
+
+ Security is discussed throughout this document. For protocol-
+ specific security considerations, refer to [RFC4016] and [RFC5191].
+
+6. Acknowledgments
+
+ We would like to thank Bernard Aboba, Yacine El Mghazli, Randy
+ Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko,
+ Pekka Savola, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black,
+ and IEEE 802.11 Working Group for their valuable comments.
+
+7. References
+
+7.1. 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, Ed., "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
+ C. Wang, "Protocol for Carrying Authentication for
+ Network Access (PANA) Requirements", RFC 4058, May 2005.
+
+
+
+
+
+Jayaraman, et al. Informational [Page 8]
+
+RFC 5193 PANA Framework May 2008
+
+
+ [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
+ and A. Yegin, "Protocol for Carrying Authentication for
+ Network Access (PANA)", RFC 5191, May 2008.
+
+ [DSL] DSL Forum Architecture and Transport Working Group, "DSL
+ Forum TR-059 DSL Evolution - Architecture Requirements
+ for the Support of QoS-Enabled IP Services", September
+ 2003.
+
+7.2. Informative References
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000.
+
+ [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+ Arkko, "Diameter Base Protocol", RFC 3588, September
+ 2003.
+
+ [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
+ and Network Access (PANA) Threat Analysis and Security
+ Requirements", RFC 4016, March 2005.
+
+ [ANCP-PROTO] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and
+ N. Voigt, "Protocol for Access Node Control Mechanism in
+ Broadband Networks", Work in Progress, November 2007.
+
+ [PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access
+ Control", Work in Progress, July 2005.
+
+ [3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless
+ IP Network Standard", 3GPP2 P.S0001-B/v2.0, September
+ 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jayaraman, et al. Informational [Page 9]
+
+RFC 5193 PANA Framework May 2008
+
+
+Authors' Addresses
+
+ Prakash Jayaraman
+ Network Equipment Technologies, Inc.
+ 6900 Paseo Padre Parkway
+ Fremont, CA 94555
+ USA
+
+ Phone: +1 510 574 2305
+ EMail: prakash_jayaraman@net.com
+
+
+ Rafa Marin Lopez
+ University of Murcia
+ 30100 Murcia
+ Spain
+
+ Phone: +34 968 398 501
+ EMail: rafa@um.es
+
+
+ Yoshihiro Ohba
+ Toshiba America Research, Inc.
+ 1 Telcordia Drive
+ Piscateway, NJ 08854
+ USA
+
+ Phone: +1 732 699 5305
+ EMail: yohba@tari.toshiba.com
+
+
+ Mohan Parthasarathy
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 408 734 8820
+ EMail: mohanp@sbcglobal.net
+
+
+ Alper E. Yegin
+ Samsung
+ Istanbul,
+ Turkey
+
+ EMail: a.yegin@partner.samsung.com
+
+
+
+
+Jayaraman, et al. Informational [Page 10]
+
+RFC 5193 PANA Framework May 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Jayaraman, et al. Informational [Page 11]
+