RFC 4058
Protocol for Carrying Authentication for Network Access (PANA) Requirements
RFC 4058: Protocol for Carrying Authentication for Network Access (PANA) Requirements 🎀
okay bestie, this one is a requirements doc for PANA, which is a protocol for carrying authentication info so a host and a network can check each other before the network lets the host in 🦋
- Authors: A. Yegin, Ed. (Samsung AIT), Y. Ohba (Toshiba), R. Penno (Juniper Networks), G. Tsirtsis (Flarion), and C. Wang (ARO/NCSU) 👑
- Category: Informational 💖
- Date: May 2005 🌸
- Obsoletes / Updates: the title block doesn't list any Obsoletes or Updates entries 🧚
Status of This Memo 📜
this memo is here to give info to the Internet community. it does not set any Internet standard of any kind. distribution is unlimited, so share it with everyone 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract ✨
okay so future IP devices are gonna have a whole bunch of ways to get online 🌐 right now every access tech has its own little method for telling the network who the client is, for authentication and authorization. 💅 but some of those are stuck to one medium (like 802.1X for IEEE 802 links), and some only work on certain topologies (like PPP for point-to-point links). 🙄
this doc's goal is to figure out what a link-layer agnostic protocol needs to do. the idea is that a host and a network can authenticate each other for network access. this protocol runs between the client's device and an agent in the network, and that agent might be a client of the AAA infrastructure. 🫶
Table of Contents 📚
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
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 .......6
4.1.3. Authentication Backend ..............................7
4.1.4. Identifiers .........................................7
4.2. IP Address Assignment ......................................7
4.3. EAP Lower Layer Requirements ...............................7
4.4. PAA-to-EP Protocol .........................................8
4.5. Network ....................................................8
4.5.1. Multi-access ........................................8
4.5.2. Disconnect Indication ...............................8
4.5.3. Location of PAA .....................................9
4.5.4. Secure Channel ......................................9
4.6. Interaction with Other Protocols ..........................10
4.7. Performance ...............................................10
4.8. Congestion Control ........................................10
4.9. IP Version Independence ...................................10
4.10. Denial of Service Attacks ................................10
4.11. Client Identity Privacy ..................................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
A. Problem Statement ..............................................12
B. Usage Scenarios ................................................13
References ........................................................16
Normative References ...........................................16
Informative References .........................................161. Introduction 🦋
okay so secure network access needs access control, and that access control is built on authenticating the clients and the access networks. ✨ the initial client-to-network authentication (and any follow-up ones) hands over the parameters the network needs to police traffic through its enforcement points. 🔥 we need a protocol that carries those authentication parameters between the client and the access network. the problem statement lives in Appendix A, so go check that if you're curious 🧐
the protocol design is only gonna define a messaging protocol (basically a carrier 🚚). that carrier moves authentication payloads between the host/client and an agent/server in the access network, for authentication and authorization. it doesn't matter whether there's an AAA infrastructure on the network or not 🙈 and since it's a network-layer protocol, it stays independent of the underlying access technologies and works on any network topology. 💜
the whole point is NOT to invent new security protocols or mechanisms. we're gonna reuse what already exists, like EAP [RFC3748]. the requirements don't force anyone to define new authentication protocols (like EAP-TLS [RFC2716]), key distribution or key agreement protocols, or key derivation methods. ✨ PANA can be seen as the front door of the AAA protocol, or of any other protocol or mechanism the network runs in the background to authenticate its clients. it's just a carrier for a security protocol or mechanism that's already defined. 🫶
mobile IPv4 is a good example of a protocol that got extended to authenticate a host for network access. 🌸 a Mobile IPv4 registration request message is used as a carrier for authentication extensions (MN-FA [RFC3344] or MN-AAA [RFC3012]). those extensions let a foreign agent authenticate mobile nodes before it provides forwarding service. PANA has a similar goal, since it also wants a network-layer transport for authentication info. the difference is that PANA is decoupled from mobility management, and it relies on other specs to define the authentication payloads. 🍓
this doc defines the common terminology and lists the requirements for a PANA protocol. the requirements are there to define and limit the scope of the work this group is gonna do 💅
2. Requirements Notation 📝
okay the big requirement words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". they get interpreted exactly the way [RFC2119] describes ✔️
3. Terminology 🌷
- PANA Client (PaC): the client side of the protocol, living in the host device. it's in charge of giving over the credentials that prove its identity for network access authorization. 🎀
- PANA Client Identifier (PaCI): the identifier the PaC shows to the PAA for network access authentication. a simple username and NAI [RFC2794] are both examples of PaCIs. 💜
- Device Identifier (DI): the identifier the network uses as a handle to control and police a client's network access. depending on the access technology, it might contain an IP address, a link-layer address, a switch port number, and so on, of a connected device. 🦋
- PANA Authentication Agent (PAA): the access network side of the protocol. its job is to verify the credentials a PANA client gives it, and then grant network access service to the device tied to that client and identified by a DI. 👑
- Enforcement Point (EP): a node on the access network where per-packet enforcement policies (aka filters) get applied to the inbound and outbound traffic of client devices. info like the DI and (optionally) cryptographic keys is handed over by the PAA, per client, so the EP can build those filters. 🔥
4. Requirements 🧚
4.1. Authentication ✨
4.1.1. Authentication of Client
okay bestie, first up: PANA MUST enable authentication of PaCs for network access 🔐. A PaC's identity can be checked by verifying the credentials (like an identifier or an authenticator) given by one of the device's users or by the device itself 🫶. PANA MUST only grant network access to the device identified by the DI, not separate access for each of the device's users at once 👑. Once the device has network access, how it decides which user gets to use 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 those protocols 🦋. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload") 📦. EAP is a candidate protocol that ticks a lot of the authentication boxes 🔥, so PANA would be a carrier protocol for EAP. If the PANA Working Group decides EAP needs extensions, it will write requirements for the EAP WG instead of designing those extensions itself 🧚.
Protecting data traffic with authentication, integrity and replay protection after a successful PANA exchange is outside the scope of this protocol 🚫. Where there's no physical layer security, link-layer or network-layer ciphering (e.g., IPsec) can do that job 🔒. These mechanisms need cryptographic keying material at the PaC and the EP. PANA doesn't deal with key derivation or distribution itself, but it enables it by carrying EAP and allowing appropriate EAP method selection 💜. Various EAP methods can generate basic keying material, but it can't be used directly with IPsec because it lacks the properties of an IPsec SA (security association), like secure cipher suite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. 🤓 These basic (initial) EAP keys can be used with an IPsec key management protocol, like IKE, to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they're sent between the EP and PaC 🛡️.
Securing router discovery [RFC1256], neighbor discovery [RFC2461], and address resolution protocols [RFC826] is also outside the scope, so don't expect PANA to do that either 🙅.
Some access networks might require or allow their clients to get authenticated and authorized by the network access provider (NAP) and ISP before the clients get network access 🌐. The NAP is the owner of the access network, providing physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., running two separate EAP methods) for the same client 🎀. Working out the authorization parameters from two separate authentications is an operational issue, so it's outside the scope of PANA.
Both the PaC and the PAA MUST be able to perform mutual authentication for network access 🤝. Having only the PAA authenticate the PaC is not sufficient, periodt 💅. Mutual authentication is required in some environments but not in all of them. For example, clients might not need to authenticate the access network when physical security is available (e.g., dial-up networks) 📞.
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 🔁.
Certain types of service theft are possible when the DI is not protected during or after the PANA exchange [RFC4016]. So PANA MUST have the capability to exchange DI securely between the PaC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its usefulness depends on using an authentication method that can generate keys for cryptographic computations on the PaC and PAA 😭🚨.
4.1.2. Authorization, Accounting, and Access Control
After a device is authenticated using PANA, it MUST be authorized for "network access." The core job of PANA is to verify the authorization of a PaC so that the PaC's device may send and receive any IP packets 📬. It may also be possible to provide finer-grained authorization, like authorization for QoS or individual services (e.g., http vs. ssh) 🎯. However, while a backend authorization infrastructure (e.g., RADIUS or Diameter based AAA infra) might pass those indications to the PAA, explicit support for them is outside the scope of PANA. For instance, PANA is not required to carry any indication of the services authorized for the authenticated device 🙃.
Providing access control functionality in the network is outside the scope of PANA 🧱. Client access authentication SHOULD be followed by access control, so that only authenticated and authorized clients can send and receive IP packets via the access network 🚪. Access control can involve setting access control lists on the EPs. The PANA protocol exchange identifies clients that are authorized to access the network 📋. If IPsec-based access control is deployed in an access network, the PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs from EAP keys is outside the scope of the PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1) 🔄.
Carrying accounting data is outside the scope of PANA 🧾.
4.1.3. Authentication Backend
PANA protocol MUST NOT make any assumptions about the backend authentication protocol or mechanisms 🙊. A PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it isn't a requirement. When the access network doesn't rely on an IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use a proprietary backend system, or rely on information stored locally on the authentication agents 🗄️.
The interaction between the PAA and the backend authentication entities is outside the scope of PANA 🫠.
4.1.4. Identifiers
PANA SHOULD allow various types of identifiers to be used as the PaCI (e.g., username, Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), etc.) 🏷️. This requirement mostly relies on the client identifiers supported by the various EAP methods 🧩.
PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.) 🔢.
A PAA MUST be able to create a binding between the PaCI and the associated DI upon a successful PANA exchange 💞. This can be done by PANA communicating the PaCI and DI to the PAA during the protocol exchange. The DI can be carried explicitly as part of the PANA payload, implicitly as the source of the PANA message, or both 📍. Multi-access networks also need cryptographic protection along with DI filtering to prevent unauthorized access [RFC4016] 🚷. The keying material needed by the cryptographic methods has to be indexed by the DI 🗂️. As described in section 4.1.2, the binding between DI and PaCI is used for access control and accounting in the network 💅.
4.2. IP Address Assignment
Assigning an IP address to the client is outside the scope of PANA 🏠. PaC MUST configure an IP address before running PANA 📮.
4.3. EAP Lower Layer Requirements
EAP has a bunch of requirements for the transport protocols it runs over, based on what EAP is, and they need to be met for everything to work properly 🧐. Please see [RFC3748] for the generic transport requirements that MUST be satisfied by PANA 📖.
4.4. PAA-to-EP Protocol
PANA doesn't assume the PAA is always co-located with the EP(s) 🗺️. Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., a gateway to the Internet, depending on the network architecture) 🌍. When the PAA and the EP(s) are separated, another transport for client provisioning is necessary. This transport is needed to create access control lists so authenticated and authorized clients' traffic can pass through the EPs 🛤️. The PANA Working Group will preferably identify an existing protocol solution that lets the PAA deliver the authorization information to one or more EPs when the PAA is separated from them. Possible candidates include, but aren't limited to, COPS, SNMP, Diameter, etc. 🧑🔬
The communication between the PAA and EP(s) MUST be secure 🔐. The whole point of a PAA-to-EP protocol is to give the EP(s) filtering rules for allowing network access of a recently authenticated and authorized PaC ✅. The chosen protocol MUST be capable of carrying the DI and cryptographic keys for a given PaC from the PAA to the EP 🔑. Depending on the PANA protocol design, support for the pull model (i.e., the EP initiating the PAA-to-EP protocol exchange per PaC), the push model (i.e., the PAA initiating the PAA-to-EP protocol exchange per PaC), or both may be required 🎛️. For example, if the design lets the EP allow PANA traffic through even for unauthenticated PaCs, the EP should also allow and expect the PAA to send filtering information at the end of a successful PANA exchange, without the EP ever sending a request 📨.
4.5. Network
4.5.1. Multi-access
PANA MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links 🕸️. In other words, PANA MUST NOT assume that the PaC has only one network interface, that the access network has only one first hop router, or that the PaC is using a point-to-point link 🙅♀️.
4.5.2. Disconnect Indication
PANA MUST NOT assume that the link is connection-oriented 🔌. Links may or may not provide disconnect indication. Such notification is desirable so the PAA can clean up resources when a client moves away from the network (e.g., informing the enforcement points that the client is no longer connected) 🧹. PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST be capable of securing disconnect messages, so malicious nodes can't abuse this extension for DoS attacks 🛑.
This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network 👋. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can happen for various reasons, like network systems going down or a change in the access policy 📉.
In case the clients can't send explicit disconnect messages to the PAA, the PAA can still detect their departure by relying on periodic authentication requests 🕵️♀️✨.
4.5.3. Location of PAA 📍
okay so the PAA and the PaC MUST be exactly one IP hop away from each other 🫶 bestie, that means there can't be any IP routers sitting between them 🙅♀️ but it does NOT mean they have to be on the same physical link. bridging and tunneling (like IP-in-IP, GRE, L2TP, etc.) can put two nodes exactly one IP hop apart even when they're plugged into totally separate physical links 🤯 the PAA can live on the network access server (NAS), a WLAN access point, or the first hop router. and using PANA when the PAA is multiple IP hops away from the PaC? literally outside the scope of PANA, so not our problem 💅
a PaC may or may not be pre-configured with the IP address of the PAA 🤷♀️ so the PANA protocol MUST define a dynamic discovery method. since the PAA is only one hop away, there are a bunch of discovery techniques the PaC could use to find the PAA's address, like multicast or anycast 🔍✨
4.5.4. Secure Channel 🔐
PANA MUST NOT assume a secure channel exists between the PaC and the PAA, bestie, no assumptions 🙅♀️ PANA MUST be able to provide authentication, especially in networks that aren't protected against eavesdropping and spoofing 👀 PANA MUST also enable protection against replay attacks on both PaCs and PAAs 🛡️
this requirement partially relies on EAP and the EAP methods carried over PANA 💖 using EAP methods that provide mutual authentication and key derivation/distribution is essential for meeting it. EAP doesn't assume a secure channel either, and it supports lots of authentication methods that work in these kinda sketchy environments 🌈 plus, PANA MUST ensure its design doesn't have vulnerabilities that can be exploited when it's used over insecure channels 😭 and PANA MAY provide a secure channel by deploying a two-phase authentication. the first phase can create the secure channel, and the second phase handles client and network authentication. iconic layering, ngl 👑
4.6. Interaction with Other Protocols 🤝
mobility management is outside the scope of PANA, but PANA MUST be able to co-exist with various mobility management protocols and MUST NOT unintentionally interfere with them 🦋 that includes Mobile IPv4 [RFC3344], Mobile IPv6 [RFC3775], fast handover protocols [FMIPv6] [FMIPv4], and other standard protocols like IPv6 stateless address auto-configuration [RFC2461] (including privacy extensions [RFC3041]), and DHCP [RFC2131] [RFC3315]. PANA MUST NOT make any assumptions about the protocols or mechanisms used for IP address configuration of the PaC 🙈 hands off, no peeking!
4.7. Performance ⚡
PANA design SHOULD efficiently handle the authentication process so clients get network access with minimum latency 🏃♀️💨 for example, it may cut down on protocol signaling by creating local security associations. speed is a vibe, bestie 🍓
4.8. Congestion Control 🚦
PANA MUST provide congestion control for the protocol messaging, because this can get messy 🙃 under certain conditions, PaCs might accidentally get synchronized when they send their requests to the PAA. imagine everybody's device rushing the network right after a power outage on the access network 😱 the congestion from that kind of moment can be avoided with techniques like delayed initialization and exponential back off ⏳
4.9. IP Version Independence 🌐
PANA MUST work with both IPv4 and IPv6. no picking favorites here 💅💜
4.10. Denial of Service Attacks 💀
PANA MUST be robust against a class of DoS attacks, like blind masquerade attacks through IP spoofing. these attacks would flood the PAA so it spends all its resources and legitimate clients can't get network access 🚫 absolutely not, we're not letting that happen 😤
4.11. Client Identity Privacy 🕶️
some clients might prefer hiding their identity from the visited access networks for privacy reasons, and that's valid 🫶 providing identity protection for clients is outside the scope of PANA. some authentication methods may already have this ability on their own. where it's necessary, identity protection can be achieved by letting PANA carry those authentication methods 🧚
5. Security Considerations 🔒
this document identifies requirements for the PANA protocol design. since this protocol is what it is, most of the requirements are security related 🛡️ the actual protocol design is not specified in this document, though. a thorough discussion of PANA security threats can be found in PANA Threat Analysis and Security Requirements [RFC4016], and the security threats identified in that document are already included in this general PANA requirements document. so it's all covered, bestie, no gaps 💖
6. Acknowledgements 🫶
the authors want 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 to preparing this document. legends, all of them 👑
Appendix A. Problem Statement 🧩✨
access networks in most cases need some form of authentication to prevent unauthorized usage 🚪 without physical security (and sometimes even with it), a higher layer (L2+) access authentication mechanism is needed. depending on the deployment scenario, there are a bunch of features the authentication mechanism is expected to have, like support for various authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, network service provider discovery and selection, and separate authentication for access (L1+L2) service provider and ISP (L3), etc. without a link-layer authentication mechanism that can handle all that, operators are stuck. they either use non-standard ad-hoc solutions at layers above the link, insert extra shim layers for authentication, or misuse existing protocols in ways they were never designed for 😩 so PANA is being 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 could help with some deployment scenarios 💜 some DSL deployments don't 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 using an application-layer web-based login (captive portal) scheme for subscriber authentication, or offering a best-effort service only, because they can't do the subscriber authentication that differentiated services need 😬 the captive portal scheme is a non-standard solution with plenty of limitations and security flaws.
PPP-based authentication can provide some of the required functionality, but using PPP only for authentication isn't a great choice 🙅♀️ it adds extra messaging during connection setup and extra per-packet processing. it also forces the network topology into a point-to-point model. beyond that, there's a general reluctance to bring PPP into an architecture unless it's absolutely necessary, and there's even community interest in removing PPP from some 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 lets a foreign agent force authentication even when the agent isn't involved in any Mobile IPv4 signalling (the co-located care-of address case). that means a mobility-specific protocol is being used for something totally unrelated 🤦♀️
PANA will carry EAP above IP so that any authentication method can run 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, so it only applies to limited link types. inserting PPP between IP and a link-layer might look like a way to enable EAP over that particular link-layer, but using PPP for this reason has the drawbacks mentioned above and isn't a good choice 😭 IEEE 802.1X and PPP can keep being used in their own domains, but they don't take away the need for a protocol like PANA ✨💖
Appendix B. Usage Scenarios 🦋
okay so PANA works on sooo many kinds of networks 🌈 and the first thing to check is what security already exists before PANA even runs. there are three cases that cover literally every possibility:
- a) Physically secured networks (e.g., DSL networks). Even though data traffic always travels over a physically secured link, the client might still need to be authenticated and authorized before it can access the IP services 🔒
- b) Networks where L1-L2 is already cryptographically secured before enabling IP (e.g., cdma2000 networks). The client gets authenticated on the radio link before ciphering is switched on, but it still needs to get authenticated and authorized for accessing the IP services 💜
- c) No lower-layer security present before enabling IP. PANA runs in an insecure network, and PANA-based access authentication is used to bootstrap cryptographic per-packet authentication and integrity protection 🧚
PANA is giving versatile. It's applicable to big operator deployments with full AAA infrastructure, and it's also perfect for small disconnected setups like home networks and personal area networks 🏠✨
Also, since PANA decouples AAA from the link-layer procedures, network access authentication doesn't have to happen during link establishment. Client authentication can be deferred until the client actually tries to reach differentiated services (e.g., high bandwidth, unlimited access, etc.) in some deployments 💅 Multiple simultaneous network access sessions over the same link-layer connection can happen too. main character energy 👑
The next five scenarios show the PANA usage model in different network architectures. They look at where logical elements like the PANA Client (PaC) and the PANA Authentication Agent (PAA) get placed with respect to the Enforcement Point (EP) and the Access Router (AR). Just a heads up: PAA may or may not use AAA infrastructure to verify the credentials of PaC when it authorizes 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 where access control is performed. This might be the case where PAA lives on 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 isn't co-located with the EPs but sits on the AR. We've only drawn one AR here, but 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 device where PaC was authenticated can access the network. A separate protocol is needed between PAA and EP to carry those 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 lives on the same box as the EP and AR, where access control and routing both happen ✨
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 isn't co-located with the EPs or the ARs. It still sits on the same IP link as the ARs. After successful authentication, access control parameters get distributed to the respective enforcement points via a separate protocol, and PANA doesn't play any explicit role in that part 🫶
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAAFigure 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 sits on the same IP link as the ARs. After successful authentication, access control parameters get distributed to the respective enforcement points via a separate protocol, and PANA doesn't play any explicit role in this either 🌈
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAAFigure 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.comFull 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. It also doesn't 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, 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. 💖
📦 where this page comes from
- ietf: rfc4058 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms