One document matched: draft-ietf-pana-requirements-07.txt
Differences from draft-ietf-pana-requirements-06.txt
IETF PANA Working Group Alper E. Yegin, Editor
INTERNET-DRAFT Yoshihiro Ohba
Expires: December 2003 Reinaldo Penno
George Tsirtsis
Cliff Wang
June 2003
Protocol for Carrying Authentication for
Network Access (PANA) Requirements
draft-ietf-pana-requirements-07.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 (Editor), et. al. Expires Dec 2003 [Page 1]
Internet Draft PANA Requirements June 2003
Table of Contents
Abstract..........................................................1
Table of Contents.................................................2
1. Introduction...................................................3
2. Key Words......................................................4
3. Terminology....................................................4
4. Requirements...................................................5
4.1. Authentication...............................................5
4.1.1. Authentication of Client...................................5
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.................................8
4.4. PAA-to-EP Protocol...........................................8
4.5. Network......................................................9
4.5.1. Multi-access...............................................9
4.5.2. Disconnect Indication......................................9
4.5.3. Location of PAA............................................9
4.5.4. Secure Channel............................................10
4.6. Interaction with Other Protocols............................10
4.7. Performance.................................................10
4.8. Congestion Control..........................................11
4.9. IP Version Independence.....................................11
4.10. Denial of Service Attacks..................................11
4.11. Client Identity Privacy....................................11
5. Security Considerations.......................................11
6. Acknowledgements..............................................11
7. References....................................................12
7.1. Normative References........................................12
7.2. Informative References......................................12
8. Authors' Addresses............................................13
9. Appendix......................................................14
10. Full Copyright Statement.....................................16
Yegin (Editor), et.al. Expires Dec 2003 [Page 2]
Internet Draft PANA Requirements June 2003
1. Introduction
Providing 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.
Link-layer authentication mechanisms are used as enablers of secure
network access. A higher-layer authentication protocol is deemed
necessary when link-layer authentication mechanisms either do not
exist in terms of specifications/standards for a specific technology
or present deployment difficulties; when link-layer mechanisms are
not able to meet the overall authentication and security
requirements; or when multi-layer (e.g., link-layer and
network-layer) authentication is needed. Currently there is no
standard network-layer solution for authenticating clients for
network access. In the absence of such a solution, some inadequate
standards-based solutions are deployed or non-standard ad-hoc
solutions are invented. The usage scenarios Internet-Draft [USAGE]
describes the problem statement in detail.
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. It will also be applicable to any
network topology.
The intent is not to invent new security protocols and mechanisms
but to reuse existing mechanisms such as EAP [EAP]. In particular,
the requirements do not mandate the need to define new
authentication protocols (e.g., EAP-TLS [EAPTLS]), 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.
As an example, the Mobile IP Working Group has already defined such
a carrier for Mobile IPv4 [MIPV4]. A Mobile IPv4 registration
request message is used as a carrier for authentication extensions
(MN-FA [MIPv4] or MN-AAA [MNAAA]) that allow 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 it will rely on other
specifications for the definition of authentication payloads.
Yegin (Editor), et.al. Expires Dec 2003 [Page 3]
Internet Draft PANA Requirements June 2003
This document defines the common terminology and identifies the
requirements of a protocol for PANA. These terminology and
requirements will be used to define and limit the scope of the work
to be done in this group.
2. Key Words
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 [KEYWORDS].
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 [NAI]
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 any of IP address,
link-layer address, 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.
Yegin (Editor), et.al. Expires Dec 2003 [Page 4]
Internet Draft PANA Requirements June 2003
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 granting
separate access to multiple simultaneous users of the device. Once
the network access is granted to the device, the methods used by the
device on arbitrating which one of its users 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 [EAP] is a candidate protocol that
satisfies many of the 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 presence of
cryptographic keying material at PaC and EP. Although PANA does not
deal with key derivation or distribution, it enables this by the
virtue of carrying EAP and allowing appropriate EAP method
selection. Various EAP methods are capable of generating basic
keying material. The keying material produced by EAP methods cannot
be directly used with IPsec as it lacks the properties of an IPsec
SA (security association) which include 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 also securing
router discovery [RDISC], neighbor discovery [NDISC], and address
resolution protocols [ARP] is outside the scope as well.
Yegin (Editor), et.al. Expires Dec 2003 [Page 5]
Internet Draft PANA Requirements June 2003
Some access networks might require or allow their clients to get
authenticated and authorized by the NAP (network access provider)
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 it is outside the scope of PANA.
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 [SECTHREAT]. 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 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., Diameter) 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 which services are 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 access network. Access
control can involve setting access control lists on the EPs.
Identification of clients that are authorized to access the network
is done by the PANA protocol exchange. If IPsec-based access control
Yegin (Editor), et.al. Expires Dec 2003 [Page 6]
Internet Draft PANA Requirements June 2003
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.
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, NAI, 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
[SECTHREAT]. The keying material required by the cryptographic
methods needs to be indexed by the DI. The binding between DI and
PaCI is used for access control and accounting in the network as
described in section 4.1.2.
4.2. IP Address Assignment
Assigning an IP address to the client is outside the scope of PANA.
PANA protocol design MAY require the PaC to configure an IP address
before using this protocol. Allocating IP addresses to
unauthenticated PaCs may create security vulnerabilities, such as IP
Yegin (Editor), et.al. Expires Dec 2003 [Page 7]
Internet Draft PANA Requirements June 2003
address depletion attacks on the access network [SECTHREAT]. IPv4
networks with limited address space are the main targets of such
attacks. Launching a successful attack that can deplete the
addresses in an IPv6 network is relatively harder.
This threat can be mitigated by allowing the protocol to run without
an IP address configured on the PaC (i.e., using unspecified source
address). Such a design choice might limit the re-use of existing
security mechanisms, and impose additional implementation
complexity. This trade off should be taken into consideration in
designing PANA.
4.3. EAP Lower Layer Requirements
The EAP protocol itself imposes various requirements on its
transport protocols. These requirements are based on the nature of
the EAP protocol, and they need to be satisfied for correct
operation. Please see [EAP] for the generic transport requirements
that MUST be satisfied by PANA as well.
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, there needs to be another transport for
client provisioning. This transport is needed to create access
control lists 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. This task is similar to what the
MIDCOM Working Group is trying to achieve, therefore some of that
working group's output might be useful here.
It is assumed that the communication between PAA and EP(s) is
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
Yegin (Editor), et.al. Expires Dec 2003 [Page 8]
Internet Draft PANA Requirements June 2003
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 the PaC has only one network interface, or the access
network has only one first hop router, or 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 cleanup 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 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 happen due to various reasons such as
network systems going down, or a change in access policy.
In case the clients cannot send explicit disconnect messages to the
PAA, PAA 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
techniques can place two nodes just exactly one IP hop away from
each other although they might be connected to separate physical
links. Furthermore, two nodes on the same IP subnet do not
necessarily satisfy this requirement, as they can be more than one
hop away from each other [MULTILINK]. A PAA can be on the NAS
(network access server) 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.
Yegin (Editor), et.al. Expires Dec 2003 [Page 9]
Internet Draft PANA Requirements June 2003
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 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 its design
does not contain vulnerabilities that can be exploited when it is
used over insecure channels. PANA MAY provide a secure channel by
deploying a two-phase authentication. The first phase can be used
for creation of the secure channel, and the second phase is 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 [MIPV4],
Mobile IPv6 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and
other standard protocols like IPv6 stateless address
auto-configuration [ADDRCONF] (including privacy extensions
[PRIVACY]), and DHCP [DHCPV4, DHCPV6]. It MUST NOT make any
assumptions on the protocols or mechanisms used for IP address
configuration of the PaC.
4.7. Performance
PANA design SHOULD give consideration to efficient handling of the
authentication process. This is important for gaining network access
with minimum latency. As an example, a method like minimizing the
protocol signaling by creating local security associations can be
used for this purpose.
Yegin (Editor), et.al. Expires Dec 2003 [Page 10]
Internet Draft PANA Requirements June 2003
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 that 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
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 document
[SECTHREAT]. Security threats identified in that document are
already included in this general PANA requirements document.
6. Acknowledgements
We would like to thank Subir Das, Lionel Morand, Mohan
Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan
Forsberg, Francis Dupont, Bernard Aboba and the PANA Working Group
members for their valuable contributions to the discussions and
preparation of this document.
Yegin (Editor), et.al. Expires Dec 2003 [Page 11]
Internet Draft PANA Requirements June 2003
7. References
7.1. Normative References
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem
Statement and Usage Scenarios for PANA",
draft-ietf-pana-usage-scenarios-06.txt, April 2003. Work in
progress.
[SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security
Requirements", draft-ietf-pana-threats-04.txt, May 2003. Work in
progress.
[EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz,
"Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-04.txt, June 2003. Work in progress.
7.2. Informative References
[8021X] "IEEE Standards for Local and Metropolitan Area Networks:
Port Based Network Access Control", IEEE Std 802.1X-2001.
[EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work
in progress.
[PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC
3344, August 2002.
[MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress.
[MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC3012, November 2000.
[NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)",RFC 2461, December 1998.
[ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, November 1982.
Yegin (Editor), et.al. Expires Dec 2003 [Page 12]
Internet Draft PANA Requirements June 2003
[FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in
Mobile IPv4", November 2001. Work in progress.
[FMIPV6] R. Koodli (editor), et. al., "Fast Handovers for Mobile
IPv6", March 2003. Work in progress.
[DHCPV4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[DHCPV6] R. Droms (editor), et. al., "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", November 2002. Work in progress.
[PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
8. Authors' Addresses
Alper E. Yegin
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA, 95110
USA
Phone: +1 408 451 4743
Email: alper@docomolabs-usa.com
Yoshihiro Ohba
Toshiba America Research, Inc.
P.O. Box 136
Convent Station, NJ, 07961-0136
USA
Phone: +1 973 829 5174
Email: yohba@tari.toshiba.com
Reinaldo Penno
Nortel Networks
600 Technology Park
Billerica, MA, 01821
USA
Phone: +1 978 288 8011
Email: rpenno@nortelnetworks.com
George Tsirtsis
Flarion Technologies
Bedminster One
135 Route 202/206 South
Bedminster, NJ, 07921
USA
Phone : +44 20 88260073
E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com
Yegin (Editor), et.al. Expires Dec 2003 [Page 13]
Internet Draft PANA Requirements June 2003
Cliff Wang
Smart Pipes
565 Metro Place South
Dublin, OH, 43017
USA
Phone: +1 614 923 6241
Email: cwang@smartpipes.com
9. Appendix
A. PANA Model
Following sub-sections 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). Four different scenarios are described in
following sub-sections. Note that PAA may or may not use AAA
infrastructure to verify the credentials of PaC to authorize network
access.
A.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. PaCs communicate with
the PAA for network access on behalf of a device (D1, D2, etc.).
PANA in this case provides a means to transport the authentication
parameters from the PaC to PAA. PAA knows how to verify the
credentials. After verification, PAA sends back the success or
failure response to PaC. However, PANA does not play any explicit
role in performing access control except that it provides a hook to
access control mechanisms. This might be the case where PAA is
co-located with the access point (an IP-capable L2 access device).
PaC -----EP/PAA--+
[D1] |
+------ AR ----- (AAA)
|
PaC -----EP/PAA--+
[D2]
Figure 1: PAA co-located with EP but separated from AR.
Yegin (Editor), et.al. Expires Dec 2003 [Page 14]
Internet Draft PANA Requirements June 2003
A.2. PAA Co-located with AR but Separated from EP
Figure 2 describes this model. In this scenario, PAA is not
co-located with EPs but it 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. PaC exchanges the same messages with PAA as
discussed earlier. The difference here is when the initial
authentication for the PaC succeeds, access control parameters have
to be distributed to respective enforcement points so that the
corresponding device on which PaC is authenticated can access to the
network. Similar to the earlier case, PANA does not play any
explicit role in performing access control except that it provides a
hook to access control mechanisms. However, a separate protocol is
needed between PAA and EP to carry access control parameters.
PaC ----- EP --+
[D1] |
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
[D2]
Figure 2: PAA co-located with AR but separated from EP.
A.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 exchanges the
same messages with PAA and PAA performs similar functionalities as
before. PANA in this case also does not play any explicit role in
performing access control except that it provides a hook to access
control mechanisms.
PaC ----- EP/PAA/AR--+
[D1] |
+-------(AAA)
|
PaC ----- EP/PAA/AR--+
[D2]
Figure 3: PAA co-located with EP and AR.
A.4. PAA Separated from EP and AR
Figure 4 represents this model. In this scenario, PAA is neither
co-located with EPs nor with ARs. It still resides on the same IP
link as ARs. PaC does similar exchanges with PAA as discussed
Yegin (Editor), et.al. Expires Dec 2003 [Page 15]
Internet Draft PANA Requirements June 2003
earlier. Similar to model in A.2, 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 separated from EP and AR.
10. Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Yegin (Editor), et.al. Expires Dec 2003 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 18:38:56 |