diff options
Diffstat (limited to 'doc/rfc/rfc4058.txt')
| -rw-r--r-- | doc/rfc/rfc4058.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4058.txt b/doc/rfc/rfc4058.txt new file mode 100644 index 0000000..092c637 --- /dev/null +++ b/doc/rfc/rfc4058.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group A. Yegin, Ed. +Request for Comments: 4058 Samsung AIT +Category: Informational Y. Ohba + Toshiba + R. Penno + Juniper Networks + G. Tsirtsis + Flarion + C. Wang + ARO/NCSU + May 2005 + + + Protocol for Carrying Authentication for Network Access (PANA) + Requirements + +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. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + It is expected that future IP devices will have a variety of access + technologies to gain network connectivity. Currently there are + access-specific mechanisms for providing client information to the + network for authentication and authorization purposes. In addition + to being limited to specific access media (e.g., 802.1X for IEEE 802 + links), some of these protocols are limited to specific network + topologies (e.g., PPP for point-to-point links). The goal of this + document is to identify the requirements for a link-layer agnostic + protocol that allows a host and a network to authenticate each other + for network access. This protocol will run between a client's device + and an agent in the network where the agent might be a client of the + AAA infrastructure. + + + + + + + + + + + +Yegin, et al. Informational [Page 1] + +RFC 4058 PANA Requirements May 2005 + + +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 .........................................16 + + + + + + + + + + + + + + + + + + + +Yegin, et al. Informational [Page 2] + +RFC 4058 PANA Requirements May 2005 + + +1. Introduction + + Secure network access service requires access control based on the + authentication and authorization of the clients and the access + networks. Initial and subsequent client-to-network authentication + provides parameters that are needed to police the traffic flow + through the enforcement points. A protocol is needed to carry + authentication parameters between the client and the access network. + See Appendix A for the associated problem statement. + + The protocol design will be limited to defining a messaging protocol + (i.e., a carrier) that will allow authentication payload to be + carried between the host/client and an agent/server in the access + network for authentication and authorization purposes regardless of + the AAA infrastructure that may (or may not) reside on the network. + As a network-layer protocol, it will be independent of the underlying + access technologies and applicable to any network topology. + + The intent is not to invent new security protocols and mechanisms but + to reuse existing mechanisms such as EAP [RFC3748]. In particular, + the requirements do not mandate the need to define new authentication + protocols (e.g., EAP-TLS [RFC2716]), key distribution or key + agreement protocols, or key derivation methods. The desired protocol + can be viewed as the front-end of the AAA protocol or any other + protocol/mechanisms the network is running at the background to + authenticate its clients. It will act as a carrier for an already + defined security protocol or mechanism. + + An example of a protocol being extended for use in authenticating a + host for network access is Mobile IPv4. A Mobile IPv4 registration + request message is used as a carrier for authentication extensions + (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allows a foreign agent to + authenticate mobile nodes before providing forwarding service. The + goal of PANA is similar in that it aims to define a network-layer + transport for authentication information. However, PANA will be + decoupled from mobility management and will rely on other + specifications for the definition of authentication payloads. + + This document defines common terminology and identifies requirements + of a protocol for PANA that will be used to define and limit the + scope of the work to be done in this group. + +2. Requirements Notation + + 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]. + + + + +Yegin, et al. Informational [Page 3] + +RFC 4058 PANA Requirements May 2005 + + +3. Terminology + + PANA Client (PaC) + + The client side of the protocol that resides in the host device + which is responsible for providing the credentials to prove its + identity for network access authorization. + + PANA Client Identifier (PaCI) + + The identifier that is presented by the PaC to the PAA for network + access authentication. A simple username and NAI [RFC2794] are + examples of PANA client identifiers. + + Device Identifier (DI) + + The identifier used by the network as a handle to control and + police the network access of a client. Depending on the access + technology, this identifier might contain an IP address, a link- + layer address, or a switch port number, etc. of a connected + device. + + PANA Authentication Agent (PAA) + + The access network side entity of the protocol whose + responsibility is to verify the credentials provided by a PANA + client and grant network access service to the device associated + with the client and identified by a DI. + + Enforcement Point (EP) + + A node on the access network where per-packet enforcement policies + (i.e., filters) are applied on the inbound and outbound traffic of + client devices. Information such as DI and (optionally) + cryptographic keys are provided by PAA per client for constructing + filters on the EP. + +4. Requirements + +4.1. Authentication + +4.1.1. Authentication of Client + + PANA MUST enable authentication of PaCs for network access. A PaC's + identity can be authenticated by verifying the credentials (e.g., + identifier, authenticator) supplied by one of the users of the device + or the device itself. PANA MUST only grant network access service to + the device identified by the DI, rather than separate access to + + + +Yegin, et al. Informational [Page 4] + +RFC 4058 PANA Requirements May 2005 + + + multiple simultaneous users of the device. Once network access is + granted to the device, methods used by the device on arbitrating + which user can access 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 such protocols. PANA MUST + identify which specific security protocol(s) or mechanism(s) it can + carry (the "payload"). EAP is a candidate protocol that satisfies + many requirements for authentication. PANA would be a carrier + protocol for EAP. If the PANA Working Group decides that extensions + to EAP are needed, it will define requirements for the EAP WG instead + of designing such extensions. + + Providing authentication, integrity and replay protection for data + traffic after a successful PANA exchange is outside the scope of this + protocol. In networks where physical layer security is not present, + link-layer or network-layer ciphering (e.g., IPsec) can be used to + provide such security. These mechanisms require the presence of + cryptographic keying material at PaC and EP. Although PANA does not + deal with key derivation or distribution, it enables this by carrying + EAP and allowing appropriate EAP method selection. Various EAP + methods are capable of generating basic keying material that cannot + be directly used with IPsec because it lacks the properties of an + IPsec SA (security association) including 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 are sent between the EP and PaC. + + Providing a complete secure network access solution by securing + router discovery [RFC1256], neighbor discovery [RFC2461], and + address resolution protocols [RFC826] is outside the scope as well. + + 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 gain network access. NAP is the owner of the + access network who provides physical and link-layer connectivity to + the clients. PANA MUST be capable of enabling two independent + authentication operations (i.e., execution of two separate EAP + methods) for the same client. Determining the authorization + parameters as a result of two separate authentications is an + operational issue and therefore outside the scope of PANA. + + + + +Yegin, et al. Informational [Page 5] + +RFC 4058 PANA Requirements May 2005 + + + Both the PaC and the PAA MUST be able to perform mutual + authentication for network access. Providing only the capability of + a PAA authenticating the PaC is not sufficient. Mutual + authentication capability 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]. 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 utility relies on the use of + an authentication method that can generate keys for cryptographic + computations on PaC and PAA. + +4.1.2. Authorization, Accounting, and Access Control + + After a device is authenticated by using PANA, it MUST be authorized + for "network access." That is, the core requirement of PANA is to + verify the authorization of a PaC so that PaC's device may send and + receive any IP packets. It may also be possible to provide finer + granularity authorization, such as 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 provide such 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 to make sure 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. PANA + protocol exchange identifies clients that are authorized to access + the network. If IPsec-based access control is deployed in an access + network, PaC and EPs should have the required IPsec SA in place. + Generating the IPsec SAs based on EAP keys is outside the scope of + 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. + + + + +Yegin, et al. Informational [Page 6] + +RFC 4058 PANA Requirements May 2005 + + +4.1.3. Authentication Backend + + PANA protocol MUST NOT make any assumptions on the backend + authentication protocol or mechanisms. A PAA MAY interact with + backend AAA infrastructures such as RADIUS or Diameter, but it is not + a requirement. When the access network does not rely on an IETF- + defined AAA protocol (e.g., RADIUS, Diameter), it can still use a + proprietary backend system, or rely on the information locally stored + 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 generally relies on the + client identifiers supported by 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 successful PANA exchange. This can be achieved by + PANA communicating the PaCI and DI to the PAA during the protocol + exchange. The DI can be carried either explicitly as part of the + PANA payload, or implicitly as the source of the PANA message, or + both. Multi-access networks also require use of a cryptographic + protection along with DI filtering to prevent unauthorized access + [RFC4016]. The keying material required by the cryptographic methods + needs 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 + + The EAP protocol imposes various requirements on its transport + protocols that are based on the nature of the EAP protocol, and need + to be satisfied for correct operation. Please see [RFC3748] for the + generic transport requirements that MUST be satisfied by PANA. + + + + +Yegin, et al. Informational [Page 7] + +RFC 4058 PANA Requirements May 2005 + + +4.4. PAA-to-EP Protocol + + PANA does not assume that 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., 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 + in order to allow authenticated and authorized clients' traffic + through the EPs. PANA Working Group will preferably identify an + existing protocol solution that allows the PAA to deliver the + authorization information to one or more EPs when the PAA is + separated from EPs. Possible candidates include, but are not limited + to COPS, SNMP, Diameter, etc. + + The communication between PAA and EP(s) MUST be secure. The + objective of using a PAA-to-EP protocol is to provide filtering rules + to EP(s) for allowing network access of a recently authenticated and + authorized PaC. The chosen protocol MUST be capable of carrying DI + and cryptographic keys for a given PaC from PAA to EP. Depending on + the PANA protocol design, support for either of the pull model (i.e., + EP initiating the PAA-to-EP protocol exchange per PaC) or the push + model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), + or both may be required. For example, if the design is such that the + EP allows the PANA traffic to pass through even for unauthenticated + PaCs, the EP should also allow and expect the PAA to send the + 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 in order for the PAA to clean up resources when a client + moves away from the network (e.g., inform the enforcement points that + the client is no longer connected). PANA SHOULD have a mechanism to + + + + +Yegin, et al. Informational [Page 8] + +RFC 4058 PANA Requirements May 2005 + + + provide disconnect indication. PANA MUST be capable of securing + disconnect messages in order to prevent malicious nodes from + leveraging 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 occur due to various reasons such as + network systems going down or a change in the access policy. + + In case the clients cannot send explicit disconnect messages to the + PAA, it can still detect their departure by relying on periodic + authentication requests. + +4.5.3. Location of PAA + + The PAA and PaC MUST be exactly one IP hop away from each other. + That is, there must be no IP routers between the two. Note that this + does not mean they are on the same physical link. Bridging and + tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two + nodes just exactly one IP hop away from each other although they + might be connected to separate physical links. A PAA can be on the + network access server (NAS) or WLAN access point or first hop router. + The use of PANA when the PAA is multiple IP hops away from the PaC is + outside the scope of PANA. + + A PaC may or may not be pre-configured with the IP address of PAA. + Therefore the PANA protocol MUST define a dynamic discovery method. + Given that the PAA is one hop away from the PaC, there are a number + of discovery techniques that could be used (e.g., multicast or + anycast) by the PaC to find out the address of the PAA. + +4.5.4. Secure Channel + + PANA MUST NOT assume the presence of a secure channel between the PaC + and the PAA. PANA MUST be able to provide authentication especially + in networks which are not protected against eavesdropping and + spoofing. PANA MUST enable protection against replay attacks on both + PaCs and PAAs. + + This requirement partially relies on the EAP protocol and the EAP + methods carried over PANA. Use of EAP methods that provide mutual + authentication and key derivation/distribution is essential for + satisfying this requirement. EAP does not make a secure channel + assumption, and supports various authentication methods that can be + used in such environments. Additionally, PANA MUST ensure that its + design does not contain vulnerabilities that can be exploited when it + is used over insecure channels. PANA MAY provide a secure channel by + + + +Yegin, et al. Informational [Page 9] + +RFC 4058 PANA Requirements May 2005 + + + deploying a two-phase authentication. The first phase can be used + for creation of the secure channel, and the second phase for client + and network authentication. + +4.6. Interaction with Other Protocols + + Mobility management is outside the scope of PANA. However, PANA MUST + be able to co-exist and MUST NOT unintentionally interfere with + various mobility management protocols, such as 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 on the + protocols or mechanisms used for IP address configuration of the PaC. + +4.7. Performance + + PANA design SHOULD efficiently handle the authentication process in + order to gain network access with minimum latency. For example, it + may minimize the protocol signaling by creating local security + associations. + +4.8. Congestion Control + + PANA MUST provide congestion control for the protocol messaging. + Under certain conditions PaCs might unintentionally get synchronized + when sending their requests to the PAA (e.g., upon recovering from a + power outage on the access network). The network congestion + generated from such events can be avoided by using techniques like + delayed initialization and exponential back off. + +4.9. IP Version Independence + + PANA MUST work with both IPv4 and IPv6. + +4.10. Denial of Service Attacks + + PANA MUST be robust against a class of DoS attacks such as blind + masquerade attacks through IP spoofing. These attacks would swamp + the PAA, causing it to spend resources and prevent network access by + legitimate clients. + +4.11. Client Identity Privacy + + Some clients might prefer hiding their identity from visited access + networks for privacy reasons. Providing identity protection for + clients is outside the scope of PANA. Note that some authentication + + + + +Yegin, et al. Informational [Page 10] + +RFC 4058 PANA Requirements May 2005 + + + methods may already have this capability. Where necessary, identity + protection can be achieved by letting PANA carry such authentication + methods. + +5. Security Considerations + + This document identifies requirements for the PANA protocol design. + Due to the nature of this protocol, most of the requirements are + security related. The actual protocol design is not specified in + this document. A thorough discussion on PANA security threats can be + found in PANA Threat Analysis and Security Requirements [RFC4016]. + Security threats identified in that document are already included in + this general PANA requirements document. + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yegin, et al. Informational [Page 11] + +RFC 4058 PANA Requirements May 2005 + + +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. + + + + +Yegin, et al. Informational [Page 12] + +RFC 4058 PANA Requirements May 2005 + + + 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. + + + + + + + + +Yegin, et al. Informational [Page 13] + +RFC 4058 PANA Requirements May 2005 + + + 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 + + + + + + + + + + + +Yegin, et al. Informational [Page 14] + +RFC 4058 PANA Requirements May 2005 + + + 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. + + + +Yegin, et al. Informational [Page 15] + +RFC 4058 PANA Requirements May 2005 + + +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. + + + + + + + + + + + + +Yegin, et al. Informational [Page 16] + +RFC 4058 PANA Requirements May 2005 + + + [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 + + + + + + + + + + + +Yegin, et al. Informational [Page 17] + +RFC 4058 PANA Requirements May 2005 + + + 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 + + + + + + + + + + + + + +Yegin, et al. Informational [Page 18] + +RFC 4058 PANA Requirements May 2005 + + +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. + + + + + + + +Yegin, et al. Informational [Page 19] + |