draft-ietf-pana-requirements-09.txt   rfc4058.txt 
Network Working Group A. Yegin, Ed. Network Working Group A. Yegin, Ed.
Internet-Draft Samsung AIT Request for Comments: 4058 Samsung AIT
Expires: February 28, 2005 Y. Ohba Category: Informational Y. Ohba
Toshiba Toshiba
R. Penno R. Penno
Nortel Networks Juniper Networks
G. Tsirtsis G. Tsirtsis
Flarion Flarion
C. Wang C. Wang
ARO/NCSU ARO/NCSU
August 30, 2004 May 2005
Protocol for Carrying Authentication for Network Access (PANA) Protocol for Carrying Authentication for Network Access (PANA)
Requirements Requirements
draft-ietf-pana-requirements-09.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable Status of This Memo
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on February 28, 2005. 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
It is expected that future IP devices will have a variety of access It is expected that future IP devices will have a variety of access
technologies to gain network connectivity. Currently there are technologies to gain network connectivity. Currently there are
access-specific mechanisms for providing client information to the access-specific mechanisms for providing client information to the
network for authentication and authorization purposes. In addition network for authentication and authorization purposes. In addition
to being limited to specific access media (e.g., 802.1X for IEEE 802 to being limited to specific access media (e.g., 802.1X for IEEE 802
links), some of these protocols are limited to specific network links), some of these protocols are limited to specific network
topologies (e.g., PPP for point-to-point links). The goal of this topologies (e.g., PPP for point-to-point links). The goal of this
document is to identify the requirements for a link-layer agnostic document is to identify the requirements for a link-layer agnostic
protocol that allows a host and a network to authenticate each other protocol that allows a host and a network to authenticate each other
for network access. This protocol will run between a client's device 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 and an agent in the network where the agent might be a client of the
AAA infrastructure. AAA infrastructure.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation ...........................................3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology .....................................................4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements ....................................................4
4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication .............................................4
4.1.1 Authentication of Client . . . . . . . . . . . . . . . 6 4.1.1. Authentication of Client ............................4
4.1.2 Authorization, Accounting and Access Control . . . . . 7 4.1.2. Authorization, Accounting, and Access Control .......6
4.1.3 Authentication Backend . . . . . . . . . . . . . . . . 8 4.1.3. Authentication Backend ..............................7
4.1.4 Identifiers . . . . . . . . . . . . . . . . . . . . . 8 4.1.4. Identifiers .........................................7
4.2 IP Address Assignment . . . . . . . . . . . . . . . . . . 9 4.2. IP Address Assignment ......................................7
4.3 EAP Lower Layer Requirements . . . . . . . . . . . . . . . 9 4.3. EAP Lower Layer Requirements ...............................7
4.4 PAA-to-EP Protocol . . . . . . . . . . . . . . . . . . . . 9 4.4. PAA-to-EP Protocol .........................................8
4.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Network ....................................................8
4.5.1 Multi-access . . . . . . . . . . . . . . . . . . . . . 10 4.5.1. Multi-access ........................................8
4.5.2 Disconnect Indication . . . . . . . . . . . . . . . . 10 4.5.2. Disconnect Indication ...............................8
4.5.3 Location of PAA . . . . . . . . . . . . . . . . . . . 10 4.5.3. Location of PAA .....................................9
4.5.4 Secure Channel . . . . . . . . . . . . . . . . . . . . 11 4.5.4. Secure Channel ......................................9
4.6 Interaction with Other Protocols . . . . . . . . . . . . . 11 4.6. Interaction with Other Protocols ..........................10
4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Performance ...............................................10
4.8 Congestion Control . . . . . . . . . . . . . . . . . . . . 11 4.8. Congestion Control ........................................10
4.9 IP Version Independence . . . . . . . . . . . . . . . . . 12 4.9. IP Version Independence ...................................10
4.10 Denial of Service Attacks . . . . . . . . . . . . . . . . 12 4.10. Denial of Service Attacks ................................10
4.11 Client Identity Privacy . . . . . . . . . . . . . . . . . 12 4.11. Client Identity Privacy ..................................10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations ........................................11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements ...............................................11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 A. Problem Statement ..............................................12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 B. Usage Scenarios ................................................13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 References ........................................................16
A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 Normative References ...........................................16
B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21 Informative References .........................................16
Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
Secure network access service requires access control based on the Secure network access service requires access control based on the
authentication and authorization of the clients and the access authentication and authorization of the clients and the access
networks. Initial and subsequent client-to-network authentication networks. Initial and subsequent client-to-network authentication
provides parameters that are needed to police the traffic flow provides parameters that are needed to police the traffic flow
through the enforcement points. A protocol is needed to carry through the enforcement points. A protocol is needed to carry
authentication parameters between the client and the access network. authentication parameters between the client and the access network.
See Appendix for the associated problem statement. See Appendix A for the associated problem statement.
The protocol design will be limited to defining a messaging protocol The protocol design will be limited to defining a messaging protocol
(i.e., a carrier) that will allow authentication payload to be (i.e., a carrier) that will allow authentication payload to be
carried between the host/client and an agent/server in the access carried between the host/client and an agent/server in the access
network for authentication and authorization purposes regardless of network for authentication and authorization purposes regardless of
the AAA infrastructure that may (or may not) reside on the network. the AAA infrastructure that may (or may not) reside on the network.
As a network-layer protocol, it will be independent of the underlying As a network-layer protocol, it will be independent of the underlying
access technologies. It will also be applicable to any network access technologies and applicable to any network topology.
topology.
The intent is not to invent new security protocols and mechanisms but The intent is not to invent new security protocols and mechanisms but
to reuse existing mechanisms such as EAP [RFC2284] to reuse existing mechanisms such as EAP [RFC3748]. In particular,
[I-D.ietf-eap-rfc2284bis]. In particular, the requirements do not the requirements do not mandate the need to define new authentication
mandate the need to define new authentication protocols (e.g., protocols (e.g., EAP-TLS [RFC2716]), key distribution or key
EAP-TLS [RFC2716]), key distribution or key agreement protocols, or agreement protocols, or key derivation methods. The desired protocol
key derivation methods. The desired protocol can be viewed as the can be viewed as the front-end of the AAA protocol or any other
front-end of the AAA protocol or any other protocol/mechanisms the protocol/mechanisms the network is running at the background to
network is running at the background to authenticate its clients. It authenticate its clients. It will act as a carrier for an already
will act as a carrier for an already defined security protocol or defined security protocol or mechanism.
mechanism.
As an example, the Mobile IP Working Group has already defined such a An example of a protocol being extended for use in authenticating a
carrier for Mobile IPv4 [RFC3344]. A Mobile IPv4 registration host for network access is Mobile IPv4. A Mobile IPv4 registration
request message is used as a carrier for authentication extensions request message is used as a carrier for authentication extensions
(MN-FA [RFC3344] or MN-AAA [RFC3012]) that allow a foreign agent to (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allows a foreign agent to
authenticate mobile nodes before providing forwarding service. The authenticate mobile nodes before providing forwarding service. The
goal of PANA is similar in that it aims to define a network-layer goal of PANA is similar in that it aims to define a network-layer
transport for authentication information; however, PANA will be transport for authentication information. However, PANA will be
decoupled from mobility management and it will rely on other decoupled from mobility management and will rely on other
specifications for the definition of authentication payloads. specifications for the definition of authentication payloads.
This document defines the common terminology and identifies the This document defines common terminology and identifies requirements
requirements of a protocol for PANA. These terminology and of a protocol for PANA that will be used to define and limit the
requirements will be used to define and limit the scope of the work scope of the work to be done in this group.
to be done in this group.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
PANA Client (PaC) PANA Client (PaC)
The client side of the protocol that resides in the host device The client side of the protocol that resides in the host device
skipping to change at page 5, line 23 skipping to change at page 4, line 23
PANA Client Identifier (PaCI) PANA Client Identifier (PaCI)
The identifier that is presented by the PaC to the PAA for network The identifier that is presented by the PaC to the PAA for network
access authentication. A simple username and NAI [RFC2794] are access authentication. A simple username and NAI [RFC2794] are
examples of PANA client identifiers. examples of PANA client identifiers.
Device Identifier (DI) Device Identifier (DI)
The identifier used by the network as a handle to control and The identifier used by the network as a handle to control and
police the network access of a client. Depending on the access police the network access of a client. Depending on the access
technology, this identifier might contain any of IP address, technology, this identifier might contain an IP address, a link-
link-layer address, switch port number, etc. of a connected layer address, or a switch port number, etc. of a connected
device. device.
PANA Authentication Agent (PAA) PANA Authentication Agent (PAA)
The access network side entity of the protocol whose The access network side entity of the protocol whose
responsibility is to verify the credentials provided by a PANA responsibility is to verify the credentials provided by a PANA
client and grant network access service to the device associated client and grant network access service to the device associated
with the client and identified by a DI. with the client and identified by a DI.
Enforcement Point (EP) Enforcement Point (EP)
A node on the access network where per-packet enforcement policies A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of (i.e., filters) are applied on the inbound and outbound traffic of
client devices. Information such as DI and (optionally) client devices. Information such as DI and (optionally)
cryptographic keys are provided by PAA per client for constructing cryptographic keys are provided by PAA per client for constructing
filters on the EP. filters on the EP.
4. Requirements 4. Requirements
4.1 Authentication 4.1. Authentication
4.1.1 Authentication of Client 4.1.1. Authentication of Client
PANA MUST enable authentication of PaCs for network access. A PaC's PANA MUST enable authentication of PaCs for network access. A PaC's
identity can be authenticated by verifying the credentials (e.g., identity can be authenticated by verifying the credentials (e.g.,
identifier, authenticator) supplied by one of the users of the device identifier, authenticator) supplied by one of the users of the device
or the device itself. PANA MUST only grant network access service to or the device itself. PANA MUST only grant network access service to
the device identified by the DI, rather than granting separate access the device identified by the DI, rather than separate access to
to multiple simultaneous users of the device. Once the network multiple simultaneous users of the device. Once network access is
access is granted to the device, the methods used by the device on granted to the device, methods used by the device on arbitrating
arbitrating which one of its users can access the network is outside which user can access the network is outside the scope of PANA.
the scope of PANA.
PANA MUST NOT define new security protocols or mechanisms. Instead, PANA MUST NOT define new security protocols or mechanisms. Instead,
it MUST be defined as a "carrier" for such protocols. PANA MUST it MUST be defined as a "carrier" for such protocols. PANA MUST
identify which specific security protocol(s) or mechanism(s) it can identify which specific security protocol(s) or mechanism(s) it can
carry (the "payload"). EAP is a candidate protocol that satisfies carry (the "payload"). EAP is a candidate protocol that satisfies
many of the requirements for authentication. PANA would be a carrier many requirements for authentication. PANA would be a carrier
protocol for EAP. If the PANA Working Group decides that extensions protocol for EAP. If the PANA Working Group decides that extensions
to EAP are needed, it will define requirements for the EAP WG instead to EAP are needed, it will define requirements for the EAP WG instead
of designing such extensions. of designing such extensions.
Providing authentication, integrity and replay protection for data Providing authentication, integrity and replay protection for data
traffic after a successful PANA exchange is outside the scope of this traffic after a successful PANA exchange is outside the scope of this
protocol. In networks where physical layer security is not present, protocol. In networks where physical layer security is not present,
link-layer or network-layer ciphering (e.g., IPsec) can be used to link-layer or network-layer ciphering (e.g., IPsec) can be used to
provide such security. These mechanisms require presence of provide such security. These mechanisms require the presence of
cryptographic keying material at PaC and EP. Although PANA does not cryptographic keying material at PaC and EP. Although PANA does not
deal with key derivation or distribution, it enables this by the deal with key derivation or distribution, it enables this by carrying
virtue of carrying EAP and allowing appropriate EAP method selection. EAP and allowing appropriate EAP method selection. Various EAP
Various EAP methods are capable of generating basic keying material. methods are capable of generating basic keying material that cannot
The keying material produced by EAP methods cannot be directly used be directly used with IPsec because it lacks the properties of an
with IPsec as it lacks the properties of an IPsec SA (security IPsec SA (security association) including secure cipher suite
association) which include secure cipher suite negotiation, mutual negotiation, mutual proof of possession of keying material, freshness
proof of possession of keying material, freshness of transient of transient session keys, key naming, etc. These basic (initial)
session keys, key naming, etc. These basic (initial) EAP keys can be EAP keys can be used with an IPsec key management protocol, like IKE,
used with an IPsec key management protocol like IKE to generate the to generate the required security associations. A separate protocol,
required security associations. A separate protocol, called secure called secure association protocol, is required to generate IPsec SAs
association protocol, is required to generate IPsec SAs based on the based on the basic EAP keys. This protocol MUST be capable of
basic EAP keys. This protocol MUST be capable of enabling enabling IPsec-based access control on the EPs. IPsec SAs MUST
IPsec-based access control on the EPs. IPsec SAs MUST enable enable authentication, integrity and replay protection of data
authentication, integrity and replay protection of data packets as packets as they are sent between the EP and PaC.
they are sent between the EP and PaC.
Providing a complete secure network access solution by also securing Providing a complete secure network access solution by securing
router discovery [RFC1256], neighbor discovery [RFC2461], and router discovery [RFC1256], neighbor discovery [RFC2461], and
address resolution protocols [RFC1982] is outside the scope as well. address resolution protocols [RFC826] is outside the scope as well.
Some access networks might require or allow their clients to get Some access networks might require or allow their clients to get
authenticated and authorized by the NAP (network access provider) and authenticated and authorized by the network access provider (NAP) and
ISP before the clients gain network access. NAP is the owner of the ISP before the clients gain network access. NAP is the owner of the
access network who provides physical and link-layer connectivity to access network who provides physical and link-layer connectivity to
the clients. PANA MUST be capable of enabling two independent the clients. PANA MUST be capable of enabling two independent
authentication operations (i.e., execution of two separate EAP authentication operations (i.e., execution of two separate EAP
methods) for the same client. Determining the authorization methods) for the same client. Determining the authorization
parameters as a result of two separate authentications is an parameters as a result of two separate authentications is an
operational issue and therefore it is outside the scope of PANA. operational issue and therefore outside the scope of PANA.
Both the PaC and the PAA MUST be able to perform mutual Both the PaC and the PAA MUST be able to perform mutual
authentication for network access. Providing only the capability of authentication for network access. Providing only the capability of
a PAA authenticating the PaC is not sufficient. Mutual a PAA authenticating the PaC is not sufficient. Mutual
authentication capability is required in some environments but not in authentication capability is required in some environments but not in
all of them. For example, clients might not need to authenticate the all of them. For example, clients might not need to authenticate the
access network when physical security is available (e.g., dial-up access network when physical security is available (e.g., dial-up
networks). networks).
PANA MUST be capable of carrying out both periodic and on-demand PANA MUST be capable of carrying out both periodic and on-demand re-
re-authentication. Both the PaC and the PAA MUST be able to initiate authentication. Both the PaC and the PAA MUST be able to initiate
both the initial authentication and the re-authentication process. both the initial authentication and the re-authentication process.
Certain types of service theft are possible when the DI is not Certain types of service theft are possible when the DI is not
protected during or after the PANA exchange protected during or after the PANA exchange [RFC4016]. PANA MUST
[I-D.ietf-pana-threats-eval]. PANA MUST have the capability to have the capability to exchange DI securely between the PaC and PAA
exchange DI securely between the PAC and PAA where the network is where the network is vulnerable to man-in-the-middle attacks. While
vulnerable to man-in-the-middle attacks. While PANA MUST provide PANA MUST provide such a capability, its utility relies on the use of
such a capability, its utility relies on the use of an authentication an authentication method that can generate keys for cryptographic
method that can generate keys for cryptographic computations on PaC computations on PaC and PAA.
and PAA.
4.1.2 Authorization, Accounting and Access Control 4.1.2. Authorization, Accounting, and Access Control
After a device is authenticated by using PANA, it MUST be authorized After a device is authenticated by using PANA, it MUST be authorized
for "network access." That is, the core requirement of PANA is to 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 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 receive any IP packets. It may also be possible to provide finer
granularity authorization, such as authorization for QoS or granularity authorization, such as authorization for QoS or
individual services (e.g., http vs. ssh). However, while a backend individual services (e.g., http vs. ssh). However, while a backend
authorization infrastructure (e.g., Diameter) might provide such authorization infrastructure (e.g., RADIUS or Diameter based AAA
indications to the PAA, explicit support for them is outside the infra) might provide such indications to the PAA, explicit support
scope of PANA. For instance, PANA is not required to carry any for them is outside the scope of PANA. For instance, PANA is not
indication of which services are authorized for the authenticated required to carry any indication of the services authorized for the
device. authenticated device.
Providing access control functionality in the network is outside the Providing access control functionality in the network is outside the
scope of PANA. Client access authentication SHOULD be followed by scope of PANA. Client access authentication SHOULD be followed by
access control to make sure only authenticated and authorized clients access control to make sure only authenticated and authorized clients
can send and receive IP packets via the access network. Access can send and receive IP packets via the access network. Access
control can involve setting access control lists on the EPs. control can involve setting access control lists on the EPs. PANA
Identification of clients that are authorized to access the network protocol exchange identifies clients that are authorized to access
is done by the PANA protocol exchange. If IPsec-based access control the network. If IPsec-based access control is deployed in an access
is deployed in an access network, PaC and EPs should have the network, PaC and EPs should have the required IPsec SA in place.
required IPsec SA in place. Generating the IPsec SAs based on EAP Generating the IPsec SAs based on EAP keys is outside the scope of
keys is outside the scope of PANA protocol. This transformation MUST PANA protocol. This transformation MUST be handled by a separate
be handled by a separate secure association protocol (see section secure association protocol (see section 4.1.1).
4.1.1).
Carrying accounting data is outside the scope of PANA. Carrying accounting data is outside the scope of PANA.
4.1.3 Authentication Backend 4.1.3. Authentication Backend
PANA protocol MUST NOT make any assumptions on the backend PANA protocol MUST NOT make any assumptions on the backend
authentication protocol or mechanisms. A PAA MAY interact with authentication protocol or mechanisms. A PAA MAY interact with
backend AAA infrastructures such as RADIUS or Diameter, but it is not backend AAA infrastructures such as RADIUS or Diameter, but it is not
a requirement. When the access network does not rely on an a requirement. When the access network does not rely on an IETF-
IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use defined AAA protocol (e.g., RADIUS, Diameter), it can still use a
a proprietary backend system, or rely on the information locally proprietary backend system, or rely on the information locally stored
stored on the authentication agents. on the authentication agents.
The interaction between the PAA and the backend authentication The interaction between the PAA and the backend authentication
entities is outside the scope of PANA. entities is outside the scope of PANA.
4.1.4 Identifiers 4.1.4. Identifiers
PANA SHOULD allow various types of identifiers to be used as the PaCI PANA SHOULD allow various types of identifiers to be used as the PaCI
(e.g., username, NAI, FQDN, etc.). This requirement generally relies (e.g., username, Network Access Identifier (NAI), Fully Qualified
on the client identifiers supported by various EAP methods. 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 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, (e.g., IP address, link-layer address, port number of a switch,
etc.). etc.).
A PAA MUST be able to create a binding between the PaCI and the 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 associated DI upon successful PANA exchange. This can be achieved by
PANA communicating the PaCI and DI to the PAA during the protocol PANA communicating the PaCI and DI to the PAA during the protocol
exchange. The DI can be carried either explicitly as part of the exchange. The DI can be carried either explicitly as part of the
PANA payload, or implicitly as the source of the PANA message, or PANA payload, or implicitly as the source of the PANA message, or
both. Multi-access networks also require use of a cryptographic both. Multi-access networks also require use of a cryptographic
protection along with DI filtering to prevent unauthorized access protection along with DI filtering to prevent unauthorized access
[I-D.ietf-pana-threats-eval]. The keying material required by the [RFC4016]. The keying material required by the cryptographic methods
cryptographic methods needs to be indexed by the DI. The binding needs to be indexed by the DI. As described in section 4.1.2, the
between DI and PaCI is used for access control and accounting in the binding between DI and PaCI is used for access control and accounting
network as described in section 4.1.2. in the network.
4.2 IP Address Assignment 4.2. IP Address Assignment
Assigning an IP address to the client is outside the scope of PANA. Assigning an IP address to the client is outside the scope of PANA.
PaC MUST configure an IP address before running PANA. PaC MUST configure an IP address before running PANA.
4.3 EAP Lower Layer Requirements 4.3. EAP Lower Layer Requirements
The EAP protocol itself imposes various requirements on its transport The EAP protocol imposes various requirements on its transport
protocols. These requirements are based on the nature of the EAP protocols that are based on the nature of the EAP protocol, and need
protocol, and they need to be satisfied for correct operation. to be satisfied for correct operation. Please see [RFC3748] for the
Please see [I-D.ietf-eap-rfc2284bis] for the generic transport generic transport requirements that MUST be satisfied by PANA.
requirements that MUST be satisfied by PANA as well.
4.4 PAA-to-EP Protocol 4.4. PAA-to-EP Protocol
PANA does not assume that the PAA is always co-located with the 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 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), 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 or on another subnet in the access domain (e.g., gateway to the
Internet, depending on the network architecture). When the PAA and Internet, depending on the network architecture). When the PAA and
the EP(s) are separated, there needs to be another transport for the EP(s) are separated, another transport for client provisioning is
client provisioning. This transport is needed to create access necessary. This transport is needed to create access control lists
control lists to allow authenticated and authorized clients' traffic in order to allow authenticated and authorized clients' traffic
through the EPs. PANA Working Group will preferably identify an through the EPs. PANA Working Group will preferably identify an
existing protocol solution that allows the PAA to deliver the existing protocol solution that allows the PAA to deliver the
authorization information to one or more EPs when the PAA is authorization information to one or more EPs when the PAA is
separated from EPs. Possible candidates include but are not limited separated from EPs. Possible candidates include, but are not limited
to COPS, SNMP, Diameter, etc. This task is similar to what the to COPS, SNMP, Diameter, etc.
MIDCOM Working Group is trying to achieve, therefore some of that
working group's output might be useful here.
The communication between PAA and EP(s) MUST be secure. The The communication between PAA and EP(s) MUST be secure. The
objective of using a PAA-to-EP protocol is to provide filtering rules 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 to EP(s) for allowing network access of a recently authenticated and
authorized PaC. The chosen protocol MUST be capable of carrying DI authorized PaC. The chosen protocol MUST be capable of carrying DI
and cryptographic keys for a given PaC from PAA to EP. Depending on 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., 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 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), 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 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 EP allows the PANA traffic to pass through even for unauthenticated
PaCs, the EP should also allow and expect the PAA to send the PaCs, the EP should also allow and expect the PAA to send the
filtering information at the end of a successful PANA exchange filtering information at the end of a successful PANA exchange
without the EP ever sending a request. without the EP ever sending a request.
4.5 Network 4.5. Network
4.5.1 Multi-access 4.5.1. Multi-access
PANA MUST support PaCs with multiple interfaces, and networks with PANA MUST support PaCs with multiple interfaces, and networks with
multiple routers on multi-access links. In other words, PANA MUST multiple routers on multi-access links. In other words, PANA MUST
NOT assume the PaC has only one network interface, or the access NOT assume that the PaC has only one network interface, that the
network has only one first hop router, or the PaC is using a access network has only one first hop router, or that the PaC is
point-to-point link. using a point-to-point link.
4.5.2 Disconnect Indication 4.5.2. Disconnect Indication
PANA MUST NOT assume that the link is connection-oriented. Links may PANA MUST NOT assume that the link is connection-oriented. Links may
or may not provide disconnect indication. Such notification is or may not provide disconnect indication. Such notification is
desirable in order for the PAA to cleanup resources when a client desirable in order for the PAA to cleanup resources when a client
moves away from the network (e.g., inform the enforcement points that moves away from the network (e.g., inform the enforcement points that
the client is no longer connected). PANA SHOULD have a mechanism to the client is no longer connected). PANA SHOULD have a mechanism to
provide disconnect indication. PANA MUST be capable of securing provide disconnect indication. PANA MUST be capable of securing
disconnect messages in order to prevent malicious nodes from disconnect messages in order to prevent malicious nodes from
leveraging this extension for DoS attacks. leveraging this extension for DoS attacks.
This mechanism MUST allow the PAA to be notified about the departure 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 of a PaC from the network. This mechanism MUST also allow a PaC to
be notified about the discontinuation of the network access service. be notified about the discontinuation of the network access service.
Access discontinuation can happen due to various reasons such as Access discontinuation can occur due to various reasons such as
network systems going down, or a change in the access policy. network systems going down or a change in the access policy.
In case the clients cannot send explicit disconnect messages to the In case the clients cannot send explicit disconnect messages to the
PAA, PAA can still detect their departure by relying on periodic PAA, it can still detect their departure by relying on periodic
authentication requests. authentication requests.
4.5.3 Location of PAA 4.5.3. Location of PAA
The PAA and PaC MUST be exactly one IP hop away from each other. 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 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 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 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 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 might be connected to separate physical links. A PAA can be on the
NAS (network access server) or WLAN access point or first hop router. 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 The use of PANA when the PAA is multiple IP hops away from the PaC is
outside the scope of PANA. outside the scope of PANA.
A PaC may or may not be pre-configured with the IP address of PAA. 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. 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 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 of discovery techniques that could be used (e.g., multicast or
anycast) by the PaC to find out the address of the PAA. anycast) by the PaC to find out the address of the PAA.
4.5.4 Secure Channel 4.5.4. Secure Channel
PANA MUST NOT assume presence of a secure channel between the PaC and PANA MUST NOT assume the presence of a secure channel between the PaC
the PAA. PANA MUST be able to provide authentication especially in and the PAA. PANA MUST be able to provide authentication especially
networks which are not protected against eavesdropping and spoofing. in networks which are not protected against eavesdropping and
PANA MUST enable protection against replay attacks on both PaCs and spoofing. PANA MUST enable protection against replay attacks on both
PAAs. PaCs and PAAs.
This requirement partially relies on the EAP protocol and the EAP This requirement partially relies on the EAP protocol and the EAP
methods carried over PANA. Use of EAP methods that provide mutual methods carried over PANA. Use of EAP methods that provide mutual
authentication and key derivation/distribution is essential for authentication and key derivation/distribution is essential for
satisfying this requirement. EAP does not make a secure channel satisfying this requirement. EAP does not make a secure channel
assumption, and supports various authentication methods that can be assumption, and supports various authentication methods that can be
used in such environments. Additionally, PANA MUST ensure its design used in such environments. Additionally, PANA MUST ensure that its
does not contain vulnerabilities that can be exploited when it is design does not contain vulnerabilities that can be exploited when it
used over insecure channels. PANA MAY provide a secure channel by is used over insecure channels. PANA MAY provide a secure channel by
deploying a two-phase authentication. The first phase can be used deploying a two-phase authentication. The first phase can be used
for creation of the secure channel, and the second phase is for for creation of the secure channel, and the second phase for client
client and network authentication. and network authentication.
4.6 Interaction with Other Protocols 4.6. Interaction with Other Protocols
Mobility management is outside the scope of PANA. However, PANA MUST Mobility management is outside the scope of PANA. However, PANA MUST
be able to co-exist and MUST NOT unintentionally interfere with be able to co-exist and MUST NOT unintentionally interfere with
various mobility management protocols, such as Mobile IPv4 [RFC3344], various mobility management protocols, such as Mobile IPv4 [RFC3344],
Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols Mobile IPv6 [RFC3775], fast handover protocols [FMIPv6] [FMIPv4], and
[I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff], other standard protocols like IPv6 stateless address auto-
and other standard protocols like IPv6 stateless address configuration [RFC2461] (including privacy extensions [RFC3041]), and
auto-configuration [RFC2461] (including privacy extensions [RFC3041]), DHCP [RFC2131] [RFC3315]. PANA MUST NOT make any assumptions on the
and DHCP [RFC2131][RFC3315]. It MUST NOT make any assumptions on the
protocols or mechanisms used for IP address configuration of the PaC. protocols or mechanisms used for IP address configuration of the PaC.
4.7 Performance 4.7. Performance
PANA design SHOULD give consideration to efficient handling of the PANA design SHOULD efficiently handle the authentication process in
authentication process. This is important for gaining network access order to gain network access with minimum latency. For example, it
with minimum latency. As an example, a method like minimizing the may minimize the protocol signaling by creating local security
protocol signaling by creating local security associations can be associations.
used for this purpose.
4.8 Congestion Control 4.8. Congestion Control
PANA MUST provide congestion control for the protocol messaging. PANA MUST provide congestion control for the protocol messaging.
Under certain conditions PaCs might unintentionally get synchronized Under certain conditions PaCs might unintentionally get synchronized
when sending their requests to the PAA (e.g., upon recovering from a when sending their requests to the PAA (e.g., upon recovering from a
power outage on the access network). The network congestion power outage on the access network). The network congestion
generated from such events can be avoided by using techniques like generated from such events can be avoided by using techniques like
delayed initialization and exponential back off. delayed initialization and exponential back off.
4.9 IP Version Independence 4.9. IP Version Independence
PANA MUST work with both IPv4 and IPv6. PANA MUST work with both IPv4 and IPv6.
4.10 Denial of Service Attacks 4.10. Denial of Service Attacks
PANA MUST be robust against a class of DoS attacks such as blind PANA MUST be robust against a class of DoS attacks such as blind
masquerade attacks through IP spoofing that would swamp the PAA, masquerade attacks through IP spoofing. These attacks would swamp
causing it to spend resources and prevent network access by the PAA, causing it to spend resources and prevent network access by
legitimate clients. legitimate clients.
4.11 Client Identity Privacy 4.11. Client Identity Privacy
Some clients might prefer hiding their identity from visited access Some clients might prefer hiding their identity from visited access
networks for privacy reasons. Providing identity protection for networks for privacy reasons. Providing identity protection for
clients is outside the scope of PANA. Note that some authentication clients is outside the scope of PANA. Note that some authentication
methods may already have this capability. Where necessary, identity methods may already have this capability. Where necessary, identity
protection can be achieved by letting PANA carry such authentication protection can be achieved by letting PANA carry such authentication
methods. methods.
5. IANA Considerations 5. Security Considerations
This document has no actions for IANA.
6. Security Considerations
This document identifies requirements for the PANA protocol design. This document identifies requirements for the PANA protocol design.
Due to the nature of this protocol most of the requirements are Due to the nature of this protocol, most of the requirements are
security related. The actual protocol design is not specified in security related. The actual protocol design is not specified in
this document. A thorough discussion on PANA security threats can be this document. A thorough discussion on PANA security threats can be
found in PANA Threat Analysis and Security Requirements document found in PANA Threat Analysis and Security Requirements [RFC4016].
[I-D.ietf-pana-threats-eval]. Security threats identified in that Security threats identified in that document are already included in
document are already included in this general PANA requirements this general PANA requirements document.
document.
7. Acknowledgements 6. Acknowledgements
Authors would like to thank Bernard Aboba, Derek Atkins, Steven Authors would like to thank Bernard Aboba, Derek Atkins, Steven
Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg,
Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy,
Basavaraj Patil, Hesham Soliman, and the PANA Working Group members Basavaraj Patil, Hesham Soliman, and the PANA Working Group members
for their valuable contributions to the discussions and preparation for their valuable contributions to the discussions and preparation
of this document. of this document.
8. References
8.1 Normative References
[I-D.ietf-pana-threats-eval]
Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access Threat Analysis and Security
Requirements", draft-ietf-pana-threats-eval-07 (work in
progress), August 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
8.2 Informative References
[I-D.ietf-eap-rfc2284bis]
Blunk, L., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-09 (work in progress), February
2004.
[I-D.ietf-mipshop-fast-mipv6]
Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-02 (work in progress), July
2004.
[I-D.ietf-mobileip-ipv6]
Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress),
July 2003.
[I-D.ietf-mobileip-lowlatency-handoff]
Malki, K., "Low latency Handoffs in Mobile IPv4",
draft-ietf-mobileip-lowlatency-handoffs-v4-09 (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.
[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.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[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.
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
Nortel Networks
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 8011
EMail: rpenno@nortelnetworks.com
George Tsirtsis
Flarion
Bedminster One
135 Route 202/206 South
Bedminster, NJ 07921
USA
Phone: +44 20 88260073
EMail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com
Cliff Wang
ARO/NCSU
316 Riggsbee Farm
Morrisville, NC 27560
USA
Phone: +1 919 548 4207
EMail: cliffwangmail@yahoo.com
Appendix A. Problem Statement Appendix A. Problem Statement
Access networks in most cases require some form of authentication in Access networks in most cases require some form of authentication in
order to prevent unauthorized usage. In the absence of physical order to prevent unauthorized usage. In the absence of physical
security (and sometimes in addition to it) a higher layer (L2+) security (and sometimes in addition to it) a higher layer (L2+)
access authentication mechanism is needed. Depending on the access authentication mechanism is needed. Depending on the
deployment scenarios, a number of features are expected from the deployment scenarios, a number of features are expected from the
authentication mechanism. For example, support for various authentication mechanism. For example, support for various
authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming,
network service provider discovery and selection, separate network service provider discovery and selection, separate
skipping to change at page 19, line 26 skipping to change at page 12, line 26
In the absence of a link-layer authentication mechanism that can In the absence of a link-layer authentication mechanism that can
satisfy these needs, operators are forced to either use non-standard satisfy these needs, operators are forced to either use non-standard
ad-hoc solutions at layers above the link, insert additional shim ad-hoc solutions at layers above the link, insert additional shim
layers for authentication, or misuse some of the existing protocols layers for authentication, or misuse some of the existing protocols
in ways that were not intended by design. PANA will be developed to in ways that were not intended by design. PANA will be developed to
fill this gap by defining a standard network-layer access fill this gap by defining a standard network-layer access
authentication protocol. As a network-layer access authentication authentication protocol. As a network-layer access authentication
protocol, PANA can be used over any link-layer that supports IP. protocol, PANA can be used over any link-layer that supports IP.
DSL networks are a specific example where PANA has the potential for DSL networks are a specific example where PANA has the potential for
addressing some of the deployment scenarios therein. Some DSL addressing some of the deployment scenarios. Some DSL deployments do
deployments do not use PPP as the access link-layer (IP is carried not use PPP [RFC1661] as the access link-layer (IP is carried over
over ATM and the subscriber device is either statically- or ATM and the subscriber device is either statically or DHCP-
DHCP-configured). The operators of these networks are either left configured). The operators of these networks are left either using
with using an application-layer web-based login (captive portal) an application-layer web-based login (captive portal) scheme for
scheme for subscriber authentication, or providing a best-effort subscriber authentication, or providing a best-effort service only as
service only as they cannot perform subscriber authentication they cannot perform subscriber authentication required for the
required for the differentiated services. The captive portal scheme differentiated services. The captive portal scheme is a non-standard
is a non-standard solution that has various limitations and security solution that has various limitations and security flaws.
flaws.
PPP-based authentication can provide some of the required PPP-based authentication can provide some of the required
functionality. But using PPP only for authentication is not a good functionality. But using PPP only for authentication is not a good
choice, as it incurs additional messaging during the connection setup choice, as it incurs additional messaging during the connection setup
and extra per-packet processing, and it forces the network topology and extra per-packet processing. It also forces the network topology
to a point-to-point model. Aside from resistance to incorporating to a point-to-point model. Aside from resistance to incorporating
PPP into an architecture unless it is absolutely necessary, there is PPP into an architecture unless it is absolutely necessary, there is
even interest in the community to remove PPP from some of the even interest in the community in removing PPP from some of the
existing architectures and deployments (e.g., 3GPP2, DSL). existing architectures and deployments (e.g., 3GPP2, DSL).
Using Mobile IPv4 authentication with a foreign agent instead of Using Mobile IPv4 authentication with a foreign agent instead of
proper network access authentication is an example of protocol proper network access authentication is an example of protocol
misuse. Registration Required flag allows a foreign agent to force misuse. The Registration Required flag allows a foreign agent to
authentication even when the agent is not involved in any Mobile IPv4 force authentication even when the agent is not involved in any
signalling (co-located care-of address case), hence enabling the use Mobile IPv4 signalling (co-located care-of address case). This
of a mobility-specific protocol for an unrelated functionality. enables the use of a mobility-specific protocol for an unrelated
functionality.
PANA will carry EAP above IP in order to enable any authentication 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 method on any link-layer. EAP can already be carried by [IEEE-
and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, 802.1X] and PPP. IEEE 802.1X can only be used on unbridged IEEE 802
hence it only applies to limited link types. Inserting PPP between links, hence it only applies to limited link types. Inserting PPP
IP and a link-layer can be perceived as a way to enable EAP over that between IP and a link-layer can be perceived as a way to enable EAP
particular link-layer, but using PPP for this reason has the over that particular link-layer, but using PPP for this reason has
aforementioned drawbacks, hence not a good choice. While IEEE 802.1X the aforementioned drawbacks and is not a good choice. While IEEE
and PPP can continue to be used in their own domains, they do not 802.1X and PPP can continue to be used in their own domains, they do
take away the need to have a protocol like PANA. not take away the need to have a protocol like PANA.
Appendix B. Usage Scenarios Appendix B. Usage Scenarios
PANA will be applicable to various types of networks. Based on the PANA will be applicable to various types of networks. Based on the
presence of lower-layer security prior to running PANA, the following presence of lower-layer security prior to running PANA, the following
types cover all possibilities: types cover all possibilities:
a) Physically secured networks (e.g., DSL networks). Although data a) Physically secured networks (e.g., DSL networks). Although data
traffic is always carried over a physically secured link, the client traffic is always carried over a physically secured link, the
might need to be authenticated and authorized when accessing the IP client might need to be authenticated and authorized when
services. accessing the IP services.
b) Networks where L1-L2 is already cryptographically secured before b) Networks where L1-L2 is already cryptographically secured before
enabling IP (e.g., cdma2000 networks). Although the client is enabling IP (e.g., cdma2000 networks). Although the client is
authenticated on the radio link before enabling ciphering, it authenticated on the radio link before enabling ciphering, it
additionally needs to get authenticated and authorized for accessing additionally needs to get authenticated and authorized for
the IP services. accessing the IP services.
c) No lower-layer security present before enabling IP. PANA is run c) No lower-layer security present before enabling IP. PANA is run
in an insecure network. PANA-based access authentication is used to in an insecure network. PANA-based access authentication is used
bootstrap cryptographic per-packet authentication and integrity to bootstrap cryptographic per-packet authentication and integrity
protection. protection.
PANA is applicable to not only large-scale operator deployments with PANA is applicable to not only large-scale operator deployments with
full AAA infrastructure, but also to small disconnected deployments full AAA infrastructure, but also to small disconnected deployments
like home networks and personal area networks. like home networks and personal area networks.
Since PANA enables decoupling AAA from the link-layer procedures, Since PANA enables decoupling AAA from the link-layer procedures,
network access authentication does not have to take place during the network access authentication does not have to take place during the
link establishment. This allows deferring client authentication link establishment. This allows deferring client authentication
until the client attempts to access differentiated services (e.g., until the client attempts to access differentiated services (e.g.,
high bandwidth, unlimited access, etc.) in some deployments. high bandwidth, unlimited access, etc.) in some deployments.
Additionally multiple simultaneous network access sessions over the Additionally, multiple simultaneous network access sessions over the
same link-layer connection can be realized as well. same link-layer connection can occur as well.
Following scenarios capture the PANA usage model in different network The following five scenarios capture the PANA usage model in
architectures with reference to its placement of logical elements different network architectures with reference to its placement of
such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) logical elements such as the PANA Client (PaC) and the PANA
with respect to the Enforcement Point (EP) and the Access Router Authentication Agent (PAA) with respect to the Enforcement Point (EP)
(AR). Five different scenarios are described in following and the Access Router (AR). Note that PAA may or may not use AAA
sub-sections. Note that PAA may or may not use AAA infrastructure to infrastructure to verify the credentials of PaC in order to authorize
verify the credentials of PaC to authorize network access. network access.
Scenario 1: PAA co-located with EP but separated from AR Scenario 1: PAA co-located with EP but separated from AR
In this scenario (Figure 1), PAA is co-located with the enforcement In this scenario (Figure 1), PAA is co-located with the enforcement
point on which access control is performed. This might be the case 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 where PAA is co-located with the L2 access device (e.g., an IP-
IP-capable switch). capable switch).
PaC -----EP/PAA--+ PaC -----EP/PAA--+
| |
+------ AR ----- (AAA) +------ AR ----- (AAA)
| |
PaC -----EP/PAA--+ PaC -----EP/PAA--+
Figure 1: PAA co-located with EP but separated from AR. Figure 1: PAA co-located with EP but separated from AR.
Scenario 2: PAA co-located with AR but separated from EP Scenario 2: PAA co-located with AR but separated from EP
In this scenario, PAA is not co-located with EPs but it is placed on In this scenario, PAA is not co-located with EPs but is placed on the
the AR. Although we have shown only one AR here there could be AR. Although we have shown only one AR here, there could be multiple
multiple ARs, one of which is co-located with the PAA. Access ARs, one of which is co-located with the PAA. Access control
control parameters have to be distributed to the respective parameters have to be distributed to the respective enforcement
enforcement points so that the corresponding device on which PaC is points so that the corresponding device on which PaC is authenticated
authenticated can access to the network. A separate protocol is can access the network. A separate protocol is needed between PAA
needed between PAA and EP to carry access control parameters. and EP to carry access control parameters.
PaC ----- EP --+ PaC ----- EP --+
| |
+------ AR/PAA --- (AAA) +------ AR/PAA --- (AAA)
| |
PaC ----- EP --+ PaC ----- EP --+
Figure 2: PAA co-located with AR but separated from EP Figure 2: PAA co-located with AR but separated from EP
Scenario 3: PAA co-located with EP and AR Scenario 3: PAA co-located with EP and AR
In this scenario (Figure 3), PAA is co-located with the EP and AR on In this scenario (Figure 3), PAA is co-located with the EP and AR on
which access control and routing are performed. which access control and routing are performed.
PaC ----- EP/PAA/AR--+ PaC ----- EP/PAA/AR--+
| |
+-------(AAA) +-------(AAA)
| |
PaC ----- EP/PAA/AR--+ PaC ----- EP/PAA/AR--+
skipping to change at page 22, line 47 skipping to change at page 15, line 20
| |
+-------(AAA) +-------(AAA)
| |
PaC ----- EP/PAA/AR--+ PaC ----- EP/PAA/AR--+
Figure 3: PAA co-located with EP and AR. Figure 3: PAA co-located with EP and AR.
Scenario 4: Separated PAA, EP, and AR Scenario 4: Separated PAA, EP, and AR
In this scenario, PAA is neither co-located with EPs nor with ARs. In this scenario, PAA is neither co-located with EPs nor with ARs.
It still resides on the same IP link as ARs. After the successful It still resides on the same IP link as ARs. After successful
authentication, access control parameters will be distributed to authentication, access control parameters will be distributed to
respective enforcement points via a separate protocol and PANA does respective enforcement points via a separate protocol and PANA does
not play any explicit role in this. not play any explicit role in this.
PaC ----- EP -----+--- AR ---+ PaC ----- EP -----+--- AR ---+
| | | |
PaC ----- EP --- -+ | PaC ----- EP --- -+ |
| | | |
PaC ----- EP -----+--- AR -- + ----(AAA) PaC ----- EP -----+--- AR -- + ----(AAA)
| |
+--- PAA +--- PAA
Figure 4: PAA, EP and AR separated. Figure 4: PAA, EP and AR separated.
Scenario 5: PAA separated from co-located EP and AR Scenario 5: PAA separated from co-located EP and AR
In this scenario, EP and AR are co-located with each other bu 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. separated from PAA. PAA still resides on the same IP link as ARs.
After the successful authentication, access control parameters will After successful authentication, access control parameters will be
be distributed to respective enforcement points via a separate distributed to respective enforcement points via a separate protocol
protocol and PANA does not play any explicit role in this. and PANA does not play any explicit role in this.
PaC --------------+--- AR/EP ---+ PaC --------------+--- AR/EP ---+
| | | |
PaC --------------+ | PaC --------------+ |
| | | |
PaC --------------+--- AR/EP -- + ----(AAA) PaC --------------+--- AR/EP -- + ----(AAA)
| |
+--- PAA +--- PAA
Figure 5: PAA separated from EP and AR. Figure 5: PAA separated from EP and AR.
Intellectual Property Statement 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.com
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/