From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5193.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc5193.txt (limited to 'doc/rfc/rfc5193.txt') 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] + -- cgit v1.2.3