draft-ietf-pana-framework-06.txt		draft-ietf-pana-framework-07.txt
PANA Working Group P. Jayaraman		PANA Working Group P. Jayaraman
Internet-Draft Net.Com		Internet-Draft Net.Com
Expires: September 4, 2006 R. Lopez		Expires: February 23, 2007 R. Lopez
Univ. of Murcia		Univ. of Murcia
Y. Ohba (Ed.)		Y. Ohba (Ed.)
Toshiba		Toshiba
M. Parthasarathy		M. Parthasarathy
Nokia		Nokia
A. Yegin		A. Yegin
Samsung		Samsung
March 3, 2006		August 22, 2006
PANA Framework		Protocol for Carrying Authentication for Network Access (PANA) Framework
draft-ietf-pana-framework-06		draft-ietf-pana-framework-07
Status of this Memo		Status of this Memo
By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
Skipping to change at page 1, line 41:
and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006.		This Internet-Draft will expire on February 23, 2007.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
Abstract		Abstract
PANA (Protocol for carrying Authentication for Network Access) design		This document defines the general PANA framework functional elements,
provides support for various types of deployments. Access networks		high-level call flow, and deployment environments.
can differ based on the availability of lower-layer security,
placement of PANA entities, choice of client IP configuration and
authentication methods, etc. This document defines a general
framework for describing how these various deployment choices are
handled by PANA and the access network architectures. Additionally,
two possible deployments are described in detail: using PANA over DSL
networks and wireless LANs.
Table of Contents		Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4		1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. General PANA Framework . . . . . . . . . . . . . . . . . . . . 4
3. General PANA Framework . . . . . . . . . . . . . . . . . . . . 6		3. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Environments . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Environments . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Data Traffic Protection . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. PAA and EP Locations . . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Notification of PaC Presence . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.3. Filter Rule Installation . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
8. Network Selection . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Authentication Method Choice . . . . . . . . . . . . . . . . . 21		Intellectual Property and Copyright Statements . . . . . . . . . . 17
10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. DSL Access Network . . . . . . . . . . . . . . . . . . . . 22
10.1.1. Bridging Mode . . . . . . . . . . . . . . . . . . . . 22
10.1.2. Router Mode . . . . . . . . . . . . . . . . . . . . . 23
10.1.3. PANA and Dynamic ISP Selection . . . . . . . . . . . 24
10.2. Wireless LAN Example . . . . . . . . . . . . . . . . . . . 25
10.2.1. PANA with Bootstrapping IPsec . . . . . . . . . . . . 25
10.2.2. PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 29
10.2.3. Capability Discovery . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction		1. Introduction
PANA (Protocol for carrying Authentication for Network Access) is a		PANA (Protocol for carrying Authentication for Network Access) is a
link-layer agnostic network access authentication protocol that runs		link-layer agnostic network access authentication protocol that runs
between a client that wants to gain access to the network and a		between a client that wants to gain access to the network and a
server on the network side. PANA defines a new EAP [RFC3748] lower		server on the network side. PANA defines a new EAP [RFC3748] lower
layer that uses IP between the protocol end points.		layer that uses IP between the protocol end points.
The motivation to define such a protocol and the requirements are		The motivation to define such a protocol and the requirements are
described in [RFC4058]. Protocol details are documented in		described in [RFC4058]. Protocol details are documented in
[I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes use of IPsec		[I-D.ietf-pana-pana]. Upon following a successful PANA
for access control following PANA-based authentication. IPsec can be		authentication, per-data-packet security can be achieved by using
used for per-packet security, but nevertheless it is not the only way		physical security, link-layer ciphering, or IPsec [I-D.ietf-pana-
to achieve this functionality. Alternatives include reliance on		ipsec]. The server implementation of PANA may or may not be co-
physical security and link-layer ciphering. The server for PANA may		located with the entity enforcing the per-packet access control
or may not be co-located with the entity enforcing the per-packet		function. When the server for PANA and per-packet access control
access control function. When the server for PANA and per-packet		entities are separate, SNMP [I-D.ietf-pana-snmp] may be used to carry
access control entities are separate, SNMP [I-D.ietf-pana-snmp] may		information between the two nodes.
be used to carry information between the two nodes.
PANA design provides support for various types of deployments.
Access networks can differ based on the availability of lower-layer
security, placement of PANA entities, choice of client IP
configuration and authentication methods, etc.
PANA is intended to be used in any access network regardless of the		PANA is intended to be used in any access network regardless of the
underlying security. For example, the network might be physically		underlying security. For example, the network might be physically
secured, or secured by means of cryptographic mechanisms after the		secured, or secured by means of cryptographic mechanisms after the
successful client-network authentication.		successful client-network authentication.
The server for PANA and per-packet access control entities can be		This document defines the general framework for describing how these
placed on various elements in the access network (e.g., access point,		various PANA and other network access authentication elements
access router, dedicated host).		interact with each other, especially considering the two basic types
		of deployment environments.
IP address configuration mechanisms vary as well. Static
configuration, DHCP [RFC2131], stateless address auto-configuration
[RFC2461] are possible mechanisms to choose from. If the client for
PANA configures an IPsec tunnel for enabling per-packet security,
configuring IP addresses inside the tunnel becomes relevant, for
which there are additional choices such as IKE [RFC2409].
This document defines a general framework for describing how these
various deployment choices are handled by PANA and the access network
architectures. Additionally, two possible deployments are described
in detail: PANA over DSL (Digital Subscriber Line) networks and WLANs
(Wireless LANs).
1.1. Specification of Requirements		1.1. Specification of Requirements
In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
2. Terminology		2. General PANA Framework
Pre-PANA address (PRPA)
This is an IP address configured on a client for PANA before
starting the PANA exchange with a server for PANA. This address
may be unconfigured after a post-PANA address is configured.
Post-PANA address (POPA)
This is an IP address that is optionally configured on a client
for PANA after successful authentication. This address may be
used for communicating with a server of PANA or any node in the
Internet.
IPsec Tunnel Inner Address (IPsec-TIA)
This is an IP address configured on a client for PANA as the inner
address of an IPsec tunnel mode SA (Security Association)
established between the client and a per-packet access control
element for IPsec-based access control.
IPsec Tunnel Outer Address (IPsec-TOA)
This is the address configured on a client for PANA as the outer
address of an IPsec tunnel mode SA between the client and a per-
packet access control element for IPsec-based access control.
Secure Association Protocol
A protocol that runs between a client for PANA and a per-packet
access control element to provide a cryptographic binding between
the initial entity authentication (and authorization) exchange to
the subsequent exchange of data packets. Examples of secure
association protocols include the 4-way handshake in IEEE 802.11i
[802.11i], and IKE [RFC2409] in IPsec-based access control.
3. General PANA Framework
PANA is designed to facilitate authentication and authorization of		PANA is designed to facilitate authentication and authorization of
clients in access networks. PANA is an EAP [RFC3748] lower-layer		clients in access networks. PANA is an EAP [RFC3748] lower-layer
that carries EAP authentication methods encapsulated inside EAP		that carries EAP authentication methods encapsulated inside EAP
between a client node and an agent in the access network. While PANA		between a client node and a server in the access network. While PANA
enables the authentication process between the two entities, it is		enables the authentication process between the two entities, it is
only a part of an overall AAA (Authentication Authorization and		only a part of an overall AAA (Authentication, Authorization and
Accounting) and access control framework. A AAA and access control		Accounting) and access control framework. A AAA and access control
framework using PANA is comprised of four functional entities.		framework using PANA is comprised of four functional entities.
Figure 1 illustrates these functional entities and the interfaces		Figure 1 illustrates these functional entities and the interfaces
(protocols, APIs) among them. Note that PANA will not define API.		(protocols, APIs) among them.
RADIUS/		RADIUS/
Diameter/		Diameter/
+-----+ PANA +-----+ LDAP/ API +-----+		+-----+ PANA +-----+ LDAP/ API +-----+
| PaC |<----------------->| PAA |<---------------->| AS |		| PaC |<----------------->| PAA |<---------------->| AS |
+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
^ ^		^ ^
| |		| |
| +-----+ |		| +-----+ |
IKE/ +-------->| EP |<--------+ SNMP/ API		IKE/ +-------->| EP |<--------+ SNMP/ API
Skipping to change at page 7, line 12:
public access networks), a protocol needs to run between the two.		public access networks), a protocol needs to run between the two.
AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are		AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
commonly used for this purpose.		commonly used for this purpose.
The PAA is also responsible for updating the access control state		The PAA is also responsible for updating the access control state
(i.e., filters) depending on the creation and deletion of the		(i.e., filters) depending on the creation and deletion of the
authorization state. The PAA communicates the updated state to		authorization state. The PAA communicates the updated state to
the Enforcement Points in the network. If the PAA and EP are		the Enforcement Points in the network. If the PAA and EP are
residing on the same node, an API is sufficient for this		residing on the same node, an API is sufficient for this
communication. Otherwise, a protocol is required to carry the		communication. Otherwise, a protocol is required to carry the
authorized client attributes from the PAA to the EP. While not		authorized client attributes from the PAA to the EP. Separated
prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]		PAA and EPs MUST implement SNMP [I-D.ietf-pana-snmp], although the
is suggested for this task.		use of this protocol is optional (i.e., a substitute PAA-to-EP
		protocol may be used).
The PAA resides on a node that is typically called a NAS (network		The PAA resides on a node that is typically called a NAS (network
access server) in the access network. For example on a BRAS		access server) in the access network. For example on a BRAS
(Broadband Remote Access Server) [DSL] in DSL networks, or PDSN		(Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
(Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may		(Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may
be one or more IP hops away from the PaCs.		be one or more IP hops away from the PaCs.
Authentication Server (AS):		Authentication Server (AS):
The server implementation that is in charge of verifying the		The server implementation that is in charge of verifying the
Skipping to change at page 7, line 45:
The access control implementation that is in charge of allowing		The access control implementation that is in charge of allowing
access (data traffic) of authorized clients while preventing		access (data traffic) of authorized clients while preventing
access by others. An EP learns the attributes of the authorized		access by others. An EP learns the attributes of the authorized
clients from the PAA.		clients from the PAA.
The EP uses non-cryptographic or cryptographic filters to		The EP uses non-cryptographic or cryptographic filters to
selectively allow and discard data packets. These filters may be		selectively allow and discard data packets. These filters may be
applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec].		applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec].
When cryptographic access control is used, a secure association		When cryptographic access control is used, a secure association
protocol needs to run between the PaC and EP. After completion of		protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run
the secure association protocol, link or network layer per-packet		between the PaC and EP. After completion of the secure
security (for example TKIP, IPsec ESP) is enabled for integrity		association protocol, link or network layer per-packet security
protection, data origin authentication, replay protection and		(for example TKIP, IPsec ESP) is enabled for integrity protection,
optionally confidentiality protection.		data origin authentication, replay protection and optionally
		confidentiality protection.
An EP must be located strategically in a local area network to		An EP must be located strategically in a local area network to
minimize the access of unauthorized clients to the network. For		minimize the access of unauthorized clients to the network. It is
example, the EP can be hosted on the switch that is directly		recommended but not mandated that the EP be on-path between the
connected to the clients in a wired network. That way the EP can		PaC and the PAA for the aforementioned reason. For example, the
drop unauthorized packets before they reach any other client node		EP can be hosted on the switch that is directly connected to the
or beyond the local area network.		clients in a wired network. That way the EP can drop unauthorized
		packets before they reach any other client node or beyond the
		local area network.
Some of the entities may be co-located depending on the deployment		Some of the entities may be co-located depending on the deployment
scenario. For example, the PAA and EP would be on the same node		scenario. For example, the PAA and EP would be on the same node
(BRAS) in DSL networks. In that case a simple API is sufficient		(BRAS) in DSL networks. In that case a simple API is sufficient
between the PAA and EP. In small enterprise deployments the PAA and		between the PAA and EP. In small enterprise deployments the PAA and
AS may be hosted on the same node (access router) that eliminates the		AS may be hosted on the same node (access router) that eliminates the
need for a protocol run between the two. The decision to co-locate		need for a protocol run between the two. The decision to co-locate
these entities or otherwise, and their precise location in the		these entities or otherwise, and their precise location in the
network topology are deployment decisions that are out of the scope		network topology are deployment decisions that are out of the scope
of this document.		of this document.
Use of IKE or IEEE 802.11i 4-way handshake protocols for secure		3. Call Flow
association is only required in the absence of any lower-layer
security prior to running PANA. Physically secured networks (e.g.,
DSL) or the networks that are already cryptographically secured on
the link-layer prior to PANA run (e.g., cdma2000) do not require
additional secure association and per-packet security. These
networks can bind the PANA authentication and authorization to the
lower-layer secure channel that is already available.
Figure 2 illustrates the signaling flow for authorizing a client for		Figure 2 illustrates the signaling flow for authorizing a client for
network access.		network access.
PaC EP PAA AS		PaC EP PAA AS
| | | |		| | | |
IP address ->| | | |		IP address ->| | | |
config. | PANA | | AAA |		config. | PANA | | AAA |
|<------------------------------>|<-------------->|		|<------------------------------>|<-------------->|
| | SNMP | |		| | Provisioning | |
(Optional) | |<-------------->| |		(Optional) | |<-------------->| |
IP address ->| | | |		IP address ->| | | |
reconfig. | Sec.Assoc. | | |		reconfig. | Sec.Assoc. | | |
|<------------->| | |		|<------------->| | |
| | | |		| | | |
| Data traffic | | |		| Data traffic | | |
|<-----------------> | |		|<-----------------> | |
| | | |		| | | |
Figure 2: PANA Signaling Flow		Figure 2: PANA Signaling Flow
The EP on the access network allows general data traffic from any		The EP on the access network allows general data traffic from any
authorized PaC, whereas it allows only limited type of traffic (e.g.,		authorized PaC, whereas it allows only limited type of traffic (e.g.,
PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This		PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This
ensures that the newly attached clients have the minimum access		ensures that the newly attached clients have the minimum access
service to engage in PANA and get authorized for the unlimited		service to engage in PANA and get authorized for the unlimited
service.		service.
The PaC MUST dynamically or statically configure an IP address prior		The PaC dynamically or statically configures an IP address prior to
to running PANA. After the successful PANA authentication, depending		running PANA. After the successful PANA authentication, depending on
on the deployment scenario the PaC MAY need to re-configure its IP		the deployment scenario the PaC may need to re-configure its IP
address or configure additional IP address(es). The additional		address or configure additional IP address(es). If this additional
address configuration MAY be executed as part of the secure		IP address configuration happens in the middle of an application
association protocol run (e.g., via IKE). If this additional IP
address configuration happens in the middle of an application
protocol run, an appropriate procedure for changing an IP address		protocol run, an appropriate procedure for changing an IP address
will need to be taken so that the IP address change is transparent to		will need to be taken so that the IP address change is transparent to
the application protocol.		the application protocol.
An initially unauthorized PaC starts the PANA authentication by		An initially unauthorized PaC starts the PANA authentication by
discovering the PAA, followed by the EAP exchange over PANA. The PAA		discovering the PAA, followed by the EAP exchange over PANA. The PAA
interacts with the AS during this process. Upon receiving the		interacts with the AS during this process. Upon receiving the
authentication and authorization result from the AS, the PAA informs		authentication and authorization result from the AS, the PAA informs
the PaC about the result of its network access request.		the PaC about the result of its network access request.
Skipping to change at page 10, line 8:
traffic protection introduces additional per-packet overhead but the		traffic protection introduces additional per-packet overhead but the
overhead exists only between the PaC and EP and will not affect		overhead exists only between the PaC and EP and will not affect
communications beyond the EP.		communications beyond the EP.
Finally, filters that are installed at the EP allow general purpose		Finally, filters that are installed at the EP allow general purpose
data traffic to flow between the PaC and the intranet/Internet.		data traffic to flow between the PaC and the intranet/Internet.
4. Environments		4. Environments
PANA can be used on any network environment whether there is a lower-		PANA can be used on any network environment whether there is a lower-
layer secure channel prior to PANA, or one has to be enabled upon		layer secure channel between the PaC and the EP prior to PANA, or one
successful PANA authentication.		has to be enabled upon successful PANA authentication.
With regard to network access authentication two types of networks		With regard to network access authentication two types of networks
need to be considered:		need to be considered:
a. Networks where a secure channel is already available prior to		a. Networks where a secure channel is already available prior to
running PANA		running PANA
This type of network is characterized by the existence of		This type of network is characterized by the existence of
protection against spoofing and eavesdropping. Nevertheless, user		protection against spoofing and eavesdropping. Nevertheless, user
authentication and authorization is required for network		authentication and authorization is required for network
Skipping to change at page 10, line 34:
network wiring ensures that practically there is only one client		network wiring ensures that practically there is only one client
that can send and receive IP packets on the link. Another example		that can send and receive IP packets on the link. Another example
is a cdma2000 network where the lower-layer security is provided		is a cdma2000 network where the lower-layer security is provided
by means of cryptographic protection (a.2). By the time the		by means of cryptographic protection (a.2). By the time the
client requests access to the network-layer services, it is		client requests access to the network-layer services, it is
already authenticated and authorized for accessing the radio		already authenticated and authorized for accessing the radio
channel, and link-layer ciphering is enabled.		channel, and link-layer ciphering is enabled.
The presence of a secure channel before PANA exchange eliminates		The presence of a secure channel before PANA exchange eliminates
the need for executing a secure association protocol after PANA.		the need for executing a secure association protocol after PANA.
The PANA session can be bound to the communication channel it was		The PANA session can be associated with the communication channel
carried over. Also, the choice of EAP authentication method		it was carried over. Also, the choice of EAP authentication
depends on the presence of this security during PANA run. For		method depends on the presence of this security during PANA run.
example, weak authentication methods, such as EAP-MD5, may be used		For example, weak authentication methods, such as EAP-MD5, may be
for such networks but not for the others.		used for such networks but not for the others.
b. Networks where a secure channel is created after running PANA		b. Networks where a secure channel is created after running PANA
These are the networks where there is no lower-layer protection		These are the networks where there is no lower-layer protection
prior to running PANA. A successful PANA authentication enables		prior to running PANA. A successful PANA authentication enables
generation of cryptographic keys that are used with a secure		generation of cryptographic keys that are used with a secure
association protocol to enable per-packet cryptographic		association protocol to enable per-packet cryptographic
protection.		protection.
PANA authentication is run on an insecure channel that is		PANA authentication is run on an insecure channel that is
Skipping to change at page 12, line 5:
Whether to use a link-layer per-packet security (b.1) or a network		Whether to use a link-layer per-packet security (b.1) or a network
layer security (b.2) is a deployment decision and outside the		layer security (b.2) is a deployment decision and outside the
scope of this document. This decision also dictates the choice of		scope of this document. This decision also dictates the choice of
the secure association protocol. If link-layer protection is		the secure association protocol. If link-layer protection is
used, the protocol would be link-layer specific. If IP-layer		used, the protocol would be link-layer specific. If IP-layer
protection is used, the secure association protocol would be IKE		protection is used, the secure association protocol would be IKE
and the per-packet security would be provided by IPsec AH/ESP		and the per-packet security would be provided by IPsec AH/ESP
regardless of the underlying link-layer technology.		regardless of the underlying link-layer technology.
5. IP Address Configuration		5. Security Considerations
The PaC configures an IP address before the PANA exchange begins.
This address is called a pre-PANA address (PRPA). After a successful
authentication, the client may have to configure a post-PANA address
(POPA) for communication with other nodes, if the PRPA is a local-use
(e.g., a link-local or private address) or a temporarily allocated IP
address. An operator might choose allocating a POPA only after
successful PANA authorization either to prevent waste of premium
(e.g., globally routable) IP resources until the client is
authorized, or to enable client identity based address assignment.
There are different methods by which a PRPA can be configured.
1. In some deployments (e.g., DSL networks) the PaC may be statically
configured with an IP address. This address SHOULD be used as a
PRPA.
2. In IPv4, some clients attempt to configure an address dynamically
using DHCP [RFC2131]. If they are unable to configure an address
using DHCP, they can configure a link-local address using
[RFC3927].
When the network access provider is able to run a DHCP server on
the access link, the client would configure the PRPA using DHCP.
This address may be from a private address pool [RFC1918]. Also,
the lease time on the address may vary. For example, a PRPA
configured solely for running PANA can have a short lease time.
The PRPA may be used for local-use only (i.e., only for on-link
communication, such as for PANA and IPsec tunneling with EP), or
also for ultimate end-to-end data communication.
In case there is no running DHCP server on the link, the client
would fall back to configuring a PRPA via zeroconfiguration
technique [RFC3927]. This yields a long-term address that can
only be used for on-link communication. (Note: At time of this
writing, the zeroconfiguration technique is not widely implemented
in routers.)
3. In IPv6, clients automatically configure a link-local address
[RFC2462] when they initialize an interface. Additionally, they
may also configure global address(es) when DHCP or router
advertisements with global prefixes are made available to the
them.
In case PAA is not on the same IP subnet as the PaCs are, the
deployment must ensure that a non-link-local PRPA is configurable by
the clients.
When a PRPA is configured, the client starts the PANA exchange. By
that time, a dual stacked client might have configured both an IPv4
address and an IPv6 address as PRPAs. Regardless of whether the PaC
has both IPv4 and IPv6 PRPAs or only one of those, only one PANA run
is required. A dual-stack device that implements PaC or PAA MUST be
able to run PANA over both IPv4 and IPv6. When a dual-stack PaC or
PAA initiates PANA authentication, it chooses either IPv4 or IPv6
where the choice is made depending on the deployment. A dual-stack
PaC or PAA that is initiated PANA authentication by its peer MUST use
the same IP version that the peer is using.
When the client successfully authenticates to the network, it may be
required to configure POPAs for its subsequent data communication
with the other nodes.
If the client is already configured with an address that can be used
with data communication, it is not required to configure a POPA.
Otherwise, the PANA-Bind-Request message allows the PAA to indicate
the available configuration methods to the PaC. The PaC can choose
one of the methods and act accordingly.
1. If the network relies on physical or link layer security, the PaC
can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6
stateless auto-configuration [RFC2461]. An IPv4 PRPA SHOULD be
unconfigured when the POPA is configured to prevent IPv4 address
selection problem [RFC3927]. If IPv6 is used, the link-local PRPA
SHOULD NOT be unconfigured [RFC3484].
If the PaC is a dual-stacked node, it can configure both IPv4 and
IPv6 type POPAs. The available POPA configuration methods are
indicated within PANA.
2. If the network uses IPsec for protecting the traffic on the link
subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
would use the PRPA as the outer address of IPsec tunnel mode SA
(IPsec-TOA). The PaC also needs to configure an inner address
(IPsec-TIA). There are different ways to configure an IPsec-TIA
which are indicated in a PANA-Bind-Request message.
When an IPv4 PRPA is configured, the same address may be used as
both IPsec-TOA and IPsec-TIA. In this case, a POPA is not
configured. Alternatively, an IPsec-TIA can be obtained via the
configuration method available within [RFC3456] for IPv4,
[RFC4307] for both IPv4 and IPv6. This newly configured address
constitutes a POPA. Please refer to [I-D.ietf-pana-ipsec] for
more details.
IKEv2 [RFC4307] can enable configuration of one IPv4 IPsec-TIA and
one IPv6 IPsec-TIA for the same IPsec tunnel mode SA. Therefore,
IKEv2 is recommended for handling dual-stacked PaCs where single
execution of PANA and IKE is desired. In this case, the same IP
version that has been used for PANA is used for IKE, and the IKE
entity on the dual-stack PaC will request one or both of IPv4 and
IPv6 IPsec-TIAs from the IKE entity on the EP and obtain the
one(s) that is(are) available on the EP.
Although there are potentially a number of different ways to
configure a PRPA, and POPA when necessary, it should be noted that
the ultimate decision to use one or more of these in a deployment
depends on the operator. The decision is dictated by the operator's
choice of per-packet protection capability (physical and link-layer
vs network-layer), PRPA type (local and temporary vs global and long-
term), and POPA configuration mechanisms available in the network.
6. Data Traffic Protection
Protecting data traffic of authenticated and authorized client from
others is another component of providing a complete secure network
access solution. Authentication, integrity and replay protection of
data packets is needed to prevent spoofing when the underlying
network is not physically secured. Encryption is needed when
eavesdropping is a concern in the network.
When the network is physically secured, or the link-layer ciphering
is already enabled prior to PANA, data traffic protection is already
in place. In other cases, enabling link-layer ciphering or network-
layer ciphering might rely on PANA authentication. The user and
network have to make sure that an appropriate EAP method which
generates keying materials is used. Once the keying material is
available, it needs to be provided to the EP(s) for use with data
traffic protection.
Network-layer protection, i.e., IPsec, can be used when data traffic
protection is required but link-layer protection is not available.
Note that the keying material generated by an EAP method is
insufficient to be used alone by IPsec AH/ESP or most link layer
mechanisms. In addition to the fresh and unique session key derived
from the EAP method, IPsec also needs both traffic selectors and
other IPsec SA parameters are missing. The shared secret can be used
in conjunction with a key management protocol like IKE [RFC2409] to
turn a session key into the required IPsec SA. The details of such a
mechanism is outside the scope of PANA and is specified in [I-D.ietf-
pana-ipsec]. PANA provides bootstrapping functionality for such a
mechanism by carrying EAP methods that can generate initial keying
material.
Using network-layer ciphers should be regarded as a substitute for
link-layer ciphers when the latter is not available. Network-layer
ciphering can also be used in addition to link-layer ciphering if the
added benefits outweigh its cost to the user and the network. In
this case, PANA bootstraps only the network-layer ciphering; link-
layer ciphering is enabled using any of the existing link-layer
specific methods.
7. PAA-EP Protocol
PANA provides client authentication and authorization functionality
for securing network access. The other component of a complete
solution is the access control which ensures that only authenticated
and authorized clients can gain access to the network. PANA enables
access control by distinguishing authenticated and authorized clients
from others and generating filtering information for access control
mechanisms.
Access control can be achieved by placing EPs (Enforcement Points) in
the network for policing the traffic flow. EPs should prevent data
traffic from and to any unauthorized client unless it's either PANA
or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
discovery, DHCP, etc.).
When a PaC is authenticated and authorized, the PAA should notify
EP(s) and ask for installing filtering rules to allow the PaC to send
and receive data traffic. When the PAA and EP(s) are not co-located,
they MUST implement SNMP [I-D.ietf-pana-snmp] for the PAA-EP
communication. They MAY optionally implement and use other standard
or proprietary protocols as well.
This section describes the possible models on the location of PAA and
EP, as well as the basic authorization information that needs to be
exchanged between PAA and EP. When PAA and EP are not co-located in
a single device, there are other issues such as dead or rebooted peer
detection and consideration for specific authorization and accounting
models. However, these issues are closely related to the PAA-EP
protocol solution and thus not discussed in this document. See
[I-D.ietf-pana-snmp] for further discussion.
7.1. PAA and EP Locations
EPs' location in the network topology should be appropriate for
performing access control functionality. When the access control is
performed at link-layer, an IP-capable access device on the same link
as the client devices is the logical choice. When IPsec-based or
non-cryptographic access control mechanisms are used, the EPs'
location can range from the first-hop router to other routers within
the access network. The first-hop router may be preferred in order
to limit the access of unauthorized IP traffic.
PAA and EPs should be aware of each other as this is necessary for
access control. Generally this can be achieved by manual
configuration. Dynamic discovery is another possibility, but this is
left to implementations and outside the scope of this document.
Since PANA allows the separation of EP and PAA, there are several
models depending on the number of EPs and PAAs and their locations.
In the simplest model, the PAA and EP are co-located on the same
device. In this model, the PAA-EP communication is implemented
locally by using an API. When there are multiple such co-located
devices in the same IP subnet, only the PAA co-locating with the EP
that is closest to the PaC among all EPs in the same subnet needs to
be discovered by the PaC in order to perform per-packet access
control appropriately. To achieve this, each PAA/EP device on an
link-layer switch or access point MUST NOT forward multicast PANA
discovery message sent by PaCs attached to it to other devices. This
model is suitable for an access network with a small number of EPs.
In the other model, the PAA and EP are separated into multiple
devices and they communicate using a PAA-EP protocol such as SNMP. A
typical scenario is that a single PAA controls multiple EPs
(Figure 3). While this model is complex compared to the first model,
it is particularly useful in an access network with a large number of
EPs because it eliminates EAP messaging when the PaC switches from
one EP to another in the same access network without inter-PAA
communications. In a more complex scenario, the single PAA may be
replaced with multiple PAAs to avoid a single point of failure.
Those PAAs may or may not be co-located with EPs.
+---+
|EP |--+
+---+ \
\
+---+ +---+ +---+
|PaC| |EP |----|PAA|
+---+ +---+ +---+
/
+---+ /
|EP |--+
+---+
Figure 3: An example model for a single PAA and multiple EPs
7.2. Notification of PaC Presence
When PAA and EP are separated and PAA is configured to be the
initiator of the discovery and initial handshake phase of PANA, EP
has the responsibility to detect presence of a new PaC and notifies
the PAA(s) of the presence [RFC4058]. Such a presence notification
is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp].
7.3. Filter Rule Installation
Filtering rules to be installed on EP generally include a device
identifier of PaC, and also cryptographic keying material (e.g., IKE
pre-shared key [RFC2409]) when cryptographic data traffic protection
is needed (See Section 6). Each keying material is uniquely
identified with a keying material name (e.g., ID_KEY_ID in IKE
[RFC2409]) and has a lifetime for key management, accounting, access
control and security reasons in general. In addition to the device
identifier and keying material, other filter rules, such as the IP
filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
EAP application [RFC4072] may be installed on EP. When IPsec is used
the filter rules are applied to IP packets carried inside the IPsec
tunnel, otherwise, the filter rules are applied to IP packets that
are not protected with IPsec.
8. Network Selection
The network selection problem statement is made in [I-D.ietf-eap-
netsel-problem]. PANA [I-D.ietf-pana-pana] provides a way for
networks to advertise which ISPs are available and for a PaC to
choose one ISP from the advertised information. When the PaC chooses
an ISP in the PANA exchange, the ultimate destination of the AAA
exchange is determined based on the identity of the chosen service
provider. It is also possible that the PaC does not choose a
specific ISP in the PANA exchange. In this case, both the ISP choice
and the AAA destination are determined based on the PaC's identity,
where the identifier may be an NAI [RFC2486] or the physical port
number or link-layer address of the subscriber.
As described in [I-D.ietf-eap-netsel-problem], network selection is
not only related to AAA routing but also related to payload routing.
Once an ISP is chosen and the PaC is successfully authenticated and
authorized, the PaC is assigned an address by the ISP.
Consider a typical DSL network where the AR (access router), EP, and
PAA are co-located on a BRAS in the access network operated by a NAP
(Network Access Provider). Figure 4 shows a typical model for ISP
selection.
<---- NAP ----><--------- ISP --------->
+---ISP1
/
+---+ +---------+/
|PaC|----|AR/EP/PAA|
+---+ +---------+\
BRAS \
+---ISP2
Figure 4: A Network Selection Model
When network selection is made at network-layer with the use of PANA
instead of link-layer specific authentication mechanisms, the IP link
between the PaC and PAA needs to exist prior to doing PANA (and prior
to network selection). In this model, the PRPA is either given by
the NAP or a link-local address is auto-configured. After the
successful authentication with the ISP, the PaC may acquire an
address (POPA) from the ISP. It also learns the address of the
access router (AR), e.g., through DHCP, to be used as its default
router. The address of the AR may or may not be in the same IP
subnet as that of the PaC's POPA. Note that the physically secured
DSL networks do not require IPsec-based access control. Therefore
the PaC uses one IP address at a time where the POPA replaces the
PRPA upon configuration.
9. Authentication Method Choice
Authentication methods' capabilities and therefore applicability to
various environments differ among them. Not all methods provide
support for mutual authentication, key derivation or distribution,
and DoS attack resiliency that are necessary for operating in
insecure networks. Such networks might be susceptible to
eavesdropping and spoofing, therefore a stronger authentication
method needs to be used to prevent attacks on the client and the
network.
The authentication method choice is a function of the underlying
security of the network (e.g., physically secured, shared link,
etc.). It is the responsibility of the user and the network operator
to pick the right method for authentication. PANA carries EAP
regardless of the EAP method used. It is outside the scope of PANA
to mandate, recommend, or limit use of any authentication methods.
PANA cannot increase the strength of a weak authentication method to
make it suitable for an insecure environment. PANA can carry these
EAP encapsulating methods but it does not concern itself with how
they achieve protection for the weak methods (i.e., their EAP method
payloads).
10. Example Cases
10.1. DSL Access Network
In a DSL access network, PANA is seen applicable in the following
scenarios.
A typical DSL access consists of an access router (BRAS -- Broadband
Remote Access Server) [DSL] in the DSL access provider network, and a
bridge/router (DSL Modem/Routing Gateway) in the customer premises
network (CPN) that is in charge of connecting the CPN to the DSL
network. The DSL Modem/RG supports multiple modes of operation and
PANA is applicable in each of these modes.
In the current DSL deployment, a DSLAM (DSL Access Multiplexor) which
is placed between the DSL Modem/RG and the BRAS is a transparent
device from PANA perspective. In a future DSL model, the PAA may
reside in the DSLAM which may directly connect ISP routers through
VLANs.
Host--+ +-- ISP1
| DSL link |
+-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2
| |
Host--+ +-- ISP3
<-------- CPN --------> <------ NAP ------> <-- ISP -->
Figure 5: DSL Model
The devices at the customer premises have been shown as "hosts" in
the above network.
DSL networks are protected by physical means. Eavesdropping and
spoofing attacks are prevented by keeping the unintended users
physically away from the network media. Therefore, generally
cryptographic protection of data traffic is not common.
Nevertheless, if enhanced security is deemed necessary for any
reason, IPsec-based access control can be enabled on DSL networks as
well by using the method described in [I-D.ietf-pana-ipsec].
10.1.1. Bridging Mode
In the bridging mode, the DSL Modem/RG acts as a simple link-layer
bridge. The hosts in the CPN will function as clients to obtain
addresses from the BRAS by using DHCP or PPPoE.
If PPPoE is used, authentication is typically performed using CHAP or
MS-CHAP.
PANA will be applicable when the hosts use DHCP to obtain an IP
address. DHCP does not support authentication of the devices on
either side of the DSL access line. In the simplest method of
address assignment, the BRAS will allocate the IP address to a host
with a lease time reasonably sufficient to complete a full PANA based
authentication which will be triggered immediately after the address
assignment. The hosts will perform the PaC function and the BRAS
will perform the PAA, EP and AR functions.
Host--+
(PaC) |
+-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP
| (Bridge) (PAA,EP,AR)
Host--+
(PaC)
Figure 6: Bridge Mode
The DSL service provider's trunk network should not be accessible to
any host that has not successfully completed the PANA authentication
phase.
10.1.2. Router Mode
In this mode, the DSL Modem/RG acts as a router for the CPN. The DSL
Modem/RG itself may obtain the IP address using DHCP or be configured
with a static IP address. Once the DSL Modem/RG is authenticated
using PANA and is provided access to the service provider's network,
the BRAS should begin exchanging routing updates with the DSL
Modem/RG. All devices at the customer premises will then have access
to the service provider's network.
Host--+
|
+-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP
| (Router, PaC) (PAA,EP,AR)
Host--+
Figure 7: Router Mode
It is possible that both ends of the DSL link are configured with
static IP addresses. PANA-based mutual authentication of PaC and PAA
is desirable before data traffic is exchanged between the CPN and the
service provider network. The DSL Modem/RG may also use NAPT
(Network Address Port Translation).
10.1.3. PANA and Dynamic ISP Selection
In some installations, a BRAS is shared by multiple service
providers. Each service provider configures the BRAS with a certain
IP address space.
The devices at the customer premises network indicate their choice of
service provider and the BRAS chooses the IP address from the
appropriate service provider's pool. In many cases, the address is
assigned not by the BRAS but by the AAA server that is managed fully
by the service provider.
This simplifies the management of the DSL access network as it is not
always necessary to configure each DSL access line with the service
provider's identity. The service provider is chosen dynamically by
the DSL Modem/RG. This is typically known as "dynamic Internet
Service Provider selection". The AAA function is usually overloaded
to perform dynamic ISP selection.
10.1.3.1. Selection as Part of the DHCP protocol or an Attribute of DSL
Access Line
The ISP selection, therefore the IP address pool, can be conveyed
based on the DHCP protocol exchange using, e.g., the 'client-id'
field of a DHCP packet, or by associating the DSL access line to the
service provider before the PANA authentication begins. When any of
these schemes is used, the IP address used during PANA authentication
(PRPA) is the ultimate IP address and it does not have to be changed
upon successful authorization.
10.1.3.2. Selection as Part of the PANA Authentication
The ISP selection of the client can be explicitly conveyed during the
PANA authentication (see "Network Selection" in [I-D.ietf-pana-
pana]). In that case, the client can be assigned a temporary IP
address (PRPA) prior to PANA authentication. This IP address might
be obtained via DHCP with a lease reasonably long to complete PANA
authentication, or via the zeroconf technique [RFC3927]. In either
case, successful PANA authentication signalling prompts the client to
obtain a new (long term) IP address via DHCP. This new IP address
(POPA) replaces the previously allocated temporary IP address.
The devices at the customer premises have been shown as "hosts" in
the above network.
The document specifically describes the use of PANA in non-PPP-based
DSL deployments. These are the deployments that lack a standard
network access authentication protocol between the customer premise
and the NAP.
10.2. Wireless LAN Example
This section describes how PANA can be used on WLANs. PANA may
bootstrap either link-layer or IP-layer security. IP-layer security
uses IPsec-based data traffic protection, bootstrapped by PANA. When
IP-layer security is used, link-layer security is not necessary. The
PAA indicates to the PaC whether IP-layer or link-layer protection is
necessary via the Protection-Capability AVP in a PANA-Bind-Request
message. The most common deployment cases are expected to be (1) a
co-located EP and Access Point (AP) bootstrapping link-layer
security, or (2) an Access Router (AR) co-located with a PAA (and
perhaps an EP) bootstrapping IP-layer security. These cases are
depicted together in Figure 8.
+-----+
|AP/EP|----+
+-----+ |
|
+---+ +-----+ | +---------+
|PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet
+---+ +-----+ | +---------+
|
+-----+ |
|AP/EP|----+
+-----+
Figure 8: PANA Wireless LAN Model
10.2.1. PANA with Bootstrapping IPsec
In this model, data traffic is protected by using IPsec tunnel mode
SA and an IP address is used as the device identifier of the PaC (see
Section 5 for details). Some or all of AP, DHCPv4 Server (including
PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA
and EP may be co-located in a single device. EP is always co-located
with AR and may be co-located with PAA. When EP and PAA are not co-
located, PAA-EP protocol is used for communication between PAA and
EP.
Note that for all of the cases described in this section, a PBR
(PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA
[I-D.ietf-pana-pana] should occur after installing the authorization
parameter to the AR, so that IKE can be performed immediately after
the PANA authentication is successfully completed. The PAA can
obtain the required device identifier (i.e., the IPsec-TOA in this
case) to be installed on the AR from the IP header of a PANA message
sent by the PaC before sending the PBR. However, when the PBR/PBA
exchange fails, the authorization parameters already installed on the
AR must be immediately revoked to avoid unauthorized access.
10.2.1.1. IPv4
Case A: IPsec-TIA obtained by using DHCPv4
In this case, the IPsec-TIA and IPsec-TOA are the same as the
PRPA, and all configuration information including the IP address
is obtained by using DHCPv4 [RFC2131]. No POPA is configured.
Case A is the simplest compared to other ones and might be used in
a network where IP address depletion attack on DHCP is not a
significant concern. The PRPA needs to be a routable address
unless NAT is performed on AR.
PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | |
| association| | | |
|<---------->| | | |
| | | | |
| DHCPv4 | | |
|<-----------+------------>| | |
| | | |
|PANA(Discovery and handshake phase | |
| & PAR/PAN exchange in authentication |
| and authorization phase) | |
|<-----------+-------------------------->| |
| | | |
| | |Authorization|
| | |[IKE-PSK, |
| | | PaC-DI, |
| | | Session-Id] |
| | |------------>|
| | | |
|PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| |
| | | |
| | IKE | |
|<-----------+---------------------------------------->|
| | | |
Figure 9: An example case for configuring IPsec-TIA by using
DHCPv4
Case B: IPsec-TIA obtained by using IKE
Like Case A, the PRPA is obtained by using DHCPv4 and used as the
IPsec-TOA. The difference is that the POPA is obtained by using
IKE (via a Configuration Payload exchange or equivalent) and used
as the IPsec-TIA.
Case C: IPsec-TIA obtained by using RFC3456
Like Case B, the PRPA is obtained by using DHCPv4. The difference
is that the POPA (eventually used as IPsec-TIA) and other
configuration parameter are configured by running DHCPv4 over a
special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4
Server and IPsec-TIA DHCPv4 Server may be co-located on the same
node.
Note: this case may be used only when IKEv1 is used as the IPsec
key management protocol (IKEv2 [RFC4307] does not seem to support
[RFC3456] equivalent case).
PaC AP DHCPv4 Server PAA
| Link-layer | | |
| association| | |
|<---------->| | |
| | | |
| DHCPv4 | |
|<-----------+-------->| |
| | |
|PANA(Discovery and handshake phase |
| & PAR/PAN exchange in |
| authentication and authorization phase)
|<-----------+-------------------------->|
| | |
| | | EP(AR)
| | | |Authorization
| | | |[IKE-PSK,
| | | | PaC-DI,
| | | | Session-Id]
| | |----------->|
| | | |
|PANA(PBR/PBA exchange in authentication | |
| and authorization phase) | |
|<-----------+-------------------------->| |
| | | |
| IKEv1 phase I & II |
| (to create DHCP SA) |
|<-----------+--------------------------------------->|
| | |
| DHCP over DHCP SA |
|<-----------+--------------------------------------->|
| | |
| IKEv1 phase II |
| (to create IPsec SA for data traffic) |
|<-----------+--------------------------------------->|
Figure 10: An example case for configuring IPsec-TIA by using
RFC3456
10.2.1.2. IPv6
IPsec-TIA (POPA) is obtained by using IKE (via a Configuration
Payload exchange or equivalent). Other configuration information may
be obtained in the same Configuration Payload exchange or may be
obtained by running an additional DHCPv6.
PaC AP PAA EP(AR)
| Link-layer | | |
| association| | |
|<---------->| | |
| | | |
| | | |
|PANA(Discovery and handshake phase |
| & PAR/PAN exchange in |
| authentication and authorization phase)
|<-----------+------------>| |
| | | |
| | | |
| | |Authorization|
| | |[IKE-PSK, |
| | | PaC-DI, |
| | | Session-Id] |
| | |------------>|
| | | |
|PANA(PBR/PBA exchange in | |
| authentication and authorization phase)
|<-----------+------------>| |
| | |
| IKEv2 |
| (with Configuration Payload exchange) |
|<-----------+-------------------------->|
| | | |
Figure 11: An example sequence for configuring IPsec-TIA in IPv6
10.2.2. PANA with Bootstrapping WPA/IEEE 802.11i
In this model, PANA is used for authentication and authorization, and
link-layer ciphering is used for access control. Successful PANA
authentication enables link-layer ciphering which is based on PSK
(Pre-Shared Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE
802.11i [802.11i]. The PSK is derived from the EAP AAA-Key as a
result of successful PANA authentication. In this model, MAC
addresses are used as the device identifiers in PANA.
This model allows the separation of PAA from EPs(APs). A typical
purpose of using this model is to reduce AP management cost by
allowing physical separation of RADIUS/Diameter client from access
points, where AP management can be a significant issue when deploying
a large number of access points. Additionally, this centralized AAA
framework enhances mobility-related performance (inter-AP but intra-
PAA mobility does not require additional PANA executions).
By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is
also possible to improve wireless LAN security by providing protected
disconnection procedure at L3.
This model does not require any change in the current WPA and IEEE
802.11i specifications. This also means that PANA doesn't provide
any link-layer security features beyond those already provided for in
WPA and IEEE 802.11i.
The IEEE 802.11 specification [802.11] allows Class 1 data frames to
be received in any state. Also, IEEE 802.11i [802.11i] optionally
allows higher-layer data traffic to be received and processed on the
IEEE 802.1X Uncontrolled Ports. This feature allows processing IP-
based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA)
on IEEE 802.1X Uncontrolled Port prior to client authentication.
Until the PaC is successfully authenticated, only a selected type of
IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any
other IP traffic is dropped at the AP without being forwarded to the
DS (Distribution System). Upon successful PANA authentication, the
traffic switches to the controlled port. Host configuration,
including obtaining an (potentially new) IP address, takes place on
this port. Usual DHCP-based, and also in the case of IPv6 stateless
autoconfiguration, mechanism is available to the PaC. After this
point, the rest of the IP traffic, including PANA exchanges, are
processed on the controlled port.
When a PaC does not have a PSK for the AP, the following procedure is
taken:
1. The PaC associates with the AP.
2. The PaC configures a PRPA by using a method defined in Section 5
and then runs PANA.
3. Upon successful authentication, the PaC obtains a separate PSK
for each AP controlled by the PAA as well as the information on
the available POPA configuration methods.
4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK
(Pair-wise Transient Key) with the PaC, by using the PMK.
5. The PaC obtains a POPA when necessary using one of the available
POPA configuration methods.
An alternative to running PANA over IEEE 802.1X Uncontrolled Port is
to dedicate a virtual open-access AP for the authentication. Upon
successful PANA authentication over this AP, the PaC will switch over
to another virtual AP to utilize the PANA-derived PSK.
10.2.3. Capability Discovery
When a PaC is a mobile, there may be multiple APs available in its
vicinity. Each AP can be one of the following types:
a) AP without IEEE 802.11i
There is no IEEE 802.11i link-layer security on this AP.
b) AP with IEEE 802.11i using PSK mode bootstrapped from PANA
The clients are required to perform PANA authentication which
allows the PaC to bootstrap a dynamic PSK to access this AP.
c) AP with IEEE 802.11i using native PSK mode
AP and PaC must share a statically configured PSK to access this
AP.
d) AP with IEEE 802.11i using 802.1X/EAP mode
The clients are required to perform IEEE 802.1X/EAP authentication
for this AP.
Checking the capability information advertised in IEEE 802.11 Beacon/
Probe Response frames (IEEE 802.11i defines RSN Information Element
(IE) for this purpose), PaC can extract certain information about the
different types of APs.
Specifically, if no RSN IE is contained in Beacon/Probe Response
frames then the AP is Type (a). Additionally, Type (d) can be
recognized because IEEE 802.1X-EAP mode is advertised in the RSN IE.
However Types (b) and (c) are not distinguishable by a PaC that does
not have a PSK bootstrapped from PANA for the AP, because in both
cases PSK mode is advertised in the RSN IE. Thus, the PaC will need
to take an additional action of trying to associate to the AP.
If either the PaC receives a disassociation frame from the AP as the
AP does not hold a PSK for the PaC, or AP immediately starts 4-way
handshake after association, PaC can consider AP as Type (c).
Otherwise it is Type (b).
The PaC behavior after identifying an Type (b) AP is described in
Section 10.2.2.
11. Security Considerations
Security is discussed throughout this document. For protocol-		Security is discussed throughout this document. For protocol-
specific security considerations, refer to [I-D.ietf-pana-pana].		specific security considerations, refer to [RFC4016] and [I-D.ietf-
		pana-pana].
12. IANA Considerations		6. IANA Considerations
This document has no actions for IANA.		This document has no actions for IANA.
13. Acknowledgments		7. Acknowledgments
We would like to thank Bernard Aboba, Yacine El Mghazli, Randy		We would like to thank Bernard Aboba, Yacine El Mghazli, Randy
Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley and Jari		Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko,
Arkko for their valuable comments.		Pekka Savola, tom Yu, Joel Halpern, Lakshminath Dondeti, David Black,
		and IEEE 802.11 Working Group for their valuable comments.
14. References		8. References
14.1. Normative References		8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.		RFC 3748, June 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,		RFC 4306, December 2005.
December 2005.
		[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
		and Network Access (PANA) Threat Analysis and Security
		Requirements", RFC 4016, March 2005.
[I-D.ietf-pana-snmp]		[I-D.ietf-pana-snmp]
Mghazli, Y., "SNMP usage for PAA-EP interface",		Mghazli, Y., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-05 (work in progress), January 2006.		draft-ietf-pana-snmp-06 (work in progress), June 2006.
[I-D.ietf-pana-pana]		[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for		Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-10 (work in		Network Access (PANA)", draft-ietf-pana-pana-11 (work in
progress), July 2005.		progress), March 2006.
[I-D.ietf-pana-ipsec]		[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA Enabling IPsec based Access		Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress),		Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005.		July 2005.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
and M. Carney, "Dynamic Host Configuration Protocol for		"Protocol for Carrying Authentication for Network Access
IPv6 (DHCPv6)", RFC 3315, July 2003.		(PANA) Requirements", RFC 4058, May 2005.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[DSL] DSL Forum Architecture and Transport Working Group, "DSL		[DSL] DSL Forum Architecture and Transport Working Group, "DSL
Forum TR-059 DSL Evolution - Architecture Requirements for		Forum TR-059 DSL Evolution - Architecture Requirements for
the Support of QoS-Enabled IP Services", September 2003.		the Support of QoS-Enabled IP Services", September 2003.
14.2. Informative References		8.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.		RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[I-D.ietf-eap-netsel-problem]
Arkko, J. and B. Aboba, "Network Discovery and Selection
Problem", draft-ietf-eap-netsel-problem-03 (work in
progress), October 2005.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
"Protocol for Carrying Authentication for Network Access
(PANA) Requirements", RFC 4058, May 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless
IP Network Standard", 3GPP2 P.S0001-B/v2.0,
September 2004.
[802.11i] Institute of Electrical and Electronics Engineers, "IEEE		[802.11i] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology - Telecommunications		Standard for Information technology - Telecommunications
and information exchange between systems - Local and		and information exchange between systems - Local and
metropolitan area networks - Specific requirements Part		metropolitan area networks - Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical		11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications Amendment 6: Medium Access		Layer (PHY) specifications Amendment 6: Medium Access
Control (MAC) Security Enhancements", IEEE Standard		Control (MAC) Security Enhancements", IEEE Standard
802.11i, 2004.		802.11i, 2004.
[802.11] Institute of Electrical and Electronics Engineers,		[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless
"Information technology - telecommunications and		IP Network Standard", 3GPP2 P.S0001-B/v2.0,
information exchange between systems - local and		September 2004.
metropolitan area networks - specific requirements part
11: Wireless lan medium access control (mac) and physical
layer (phy) specifications", IEEE Standard 802.11,
1999(R2003).
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-
Fi WPA v3.1, 2004.
Authors' Addresses		Authors' Addresses
Prakash Jayaraman		Prakash Jayaraman
Network Equipment Technologies, Inc.		Network Equipment Technologies, Inc.
6900 Paseo Padre Parkway		6900 Paseo Padre Parkway
Fremont, CA 94555		Fremont, CA 94555
USA		USA
Phone: +1 510 574 2305		Phone: +1 510 574 2305