draft-ietf-pana-framework-00.txt draft-ietf-pana-framework-01.txt
PANA Working Group P. Jayaraman PANA Working Group P. Jayaraman
Internet-Draft Net.Com Internet-Draft Net.Com
Expires: November 1, 2004 R. Lopez Expires: January 14, 2005 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
May 3, 2004 July 16, 2004
PANA Framework PANA Framework
draft-ietf-pana-framework-00 draft-ietf-pana-framework-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
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 November 1, 2004. This Internet-Draft will expire on January 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
PANA design provides support for various types of deployments. Access PANA design provides support for various types of deployments.
networks can differ based on the availability of lower-layer Access networks can differ based on the availability of lower-layer
security, placement of PANA entities, choice of client IP security, placement of PANA entities, choice of client IP
configuration and authentication methods, etc. This I-D defines a configuration and authentication methods, etc. This I-D defines a
general framework for describing how these various deployment choices general framework for describing how these various deployment choices
are handled by PANA and the access network architectures. are handled by PANA and the access network architectures.
Additionally, two possible deployments are described in detail: using Additionally, two possible deployments are described in detail: using
PANA over DSL networks and WLAN networks. PANA over DSL networks and WLAN networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Specification of Requirements . . . . . . . . . . . . . . 3 1.1 Specification of Requirements . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General PANA Framework . . . . . . . . . . . . . . . . . . 5 3. General PANA Framework . . . . . . . . . . . . . . . . . . . 6
4. Environments . . . . . . . . . . . . . . . . . . . . . . . 9 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IP Address Configuration . . . . . . . . . . . . . . . . . 11 5. IP Address Configuration . . . . . . . . . . . . . . . . . . 13
6. Data Traffic Protection . . . . . . . . . . . . . . . . . 14 6. Data Traffic Protection . . . . . . . . . . . . . . . . . . 16
7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . 15 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . . 17
7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 15 7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 17
7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . . . 16 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . 18
7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . . . 16 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . 18
7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 18 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 20
7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 18 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 20
8. Network Selection . . . . . . . . . . . . . . . . . . . . 19 8. Network Selection . . . . . . . . . . . . . . . . . . . . . 21
9. Authentication Method Choice . . . . . . . . . . . . . . . 21 9. Authentication Method Choice . . . . . . . . . . . . . . . . 23
10. Example Cases . . . . . . . . . . . . . . . . . . . . . . 22 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . 24
10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . . 22 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . 24
10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . . . . 22 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . 24
10.1.2 Address Translation (NAPT) Mode . . . . . . . . . . . . . 23 10.1.2 Router Mode . . . . . . . . . . . . . . . . . . . . 25
10.1.3 Router Mode . . . . . . . . . . . . . . . . . . . . . . . 23 10.1.3 PANA and Dynamic Internet Service Provider
10.1.4 PANA and Dynamic Internet Service Provider Selection . . . 24 Selection . . . . . . . . . . . . . . . . . . . . . 25
10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . . 25 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . 26
10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . . . . 26 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . 28
10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . . . . 30 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 32
10.2.3 Capability Discovery . . . . . . . . . . . . . . . . . . . 34 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . 34
11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . 35 11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . 39 13.1 Normative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 13.2 Informative References . . . . . . . . . . . . . . . . . . 38
A. Other Possible Cases for PANA with Bootstrapping IPsec Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
in Wireless LAN . . . . . . . . . . . . . . . . . . . . . 41 A. Other Possible Cases for PANA with Bootstrapping IPsec in
Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 41
A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . 46
1. Introduction 1. Introduction
PANA design provides support for various types of deployments. Access PANA is a link-layer agnostic network access authentication protocol
networks can differ based on the availability of lower-layer that runs between a node that wants to gain access to the network and
a server on the network side. PANA defines a new EAP [RFC3748] lower
layer that uses IP between the protocol end points.
The motivation to define such a protocol and the requirements are
described in [I-D.ietf-pana-requirements]. Protocol details are
documented in [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes
use of IPsec for access control following PANA-based authentication.
IPsec can be used for per-packet access control, but nevertheless it
is not the only way to achieve this functionality. Alternatives
include reliance on physical security and link-layer ciphering.
Separation of PANA server from the entity enforcing the access
control is envisaged as an optional deployment choice. SNMP
[I-D.ietf-pana-snmp] is chosen as the protocol to carry associated
information between the separate 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 security, placement of PANA entities, choice of client IP
configuration and authentication methods, etc. configuration and authentication methods, etc.
PANA can be used in any access network regardless of the underlying PANA can be used in any access network regardless of the underlying
security. For example, the network might be physically secured, or security. For example, the network might be physically secured, or
secured by means of cryptographic mechanisms after the successful secured by means of cryptographic mechanisms after the successful
client-network authentication. client-network authentication.
The PANA client, PANA authentication agent, authentication server, The PANA client, PANA authentication agent, authentication server,
and enforcement point are the relevant functional entities in this and enforcement point are the relevant functional entities in this
  Skipping to change at page 3, line 33:
IP address configuration mechanisms vary as well. Static IP address configuration mechanisms vary as well. Static
configuration, DHCP, stateless address autoconfiguration are possible configuration, DHCP, stateless address autoconfiguration are possible
mechanisms to choose from. If the client configures an IPsec tunnel mechanisms to choose from. If the client configures an IPsec tunnel
for enabling per-packet security, configuring IP addresses inside the for enabling per-packet security, configuring IP addresses inside the
tunnel becomes relevant, for which there are additional choices such tunnel becomes relevant, for which there are additional choices such
as IKE. as IKE.
This I-D defines a general framework for describing how these various This I-D defines a general framework for describing how these various
deployment choices are handled by PANA and the access network deployment choices are handled by PANA and the access network
architectures. Additionally, two possible deployments are described architectures. Additionally, two possible deployments are described
in detail: using PANA over DSL networks and WLAN networks. in detail: PANA over DSL networks and WLAN networks.
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. Terminology
Pre-PANA address (PRPA) Pre-PANA address (PRPA)
This is the address configured before starting the PANA protocol This is an IP address configured on a PANA client before starting
exchange. the PANA protocol exchange.
Post-PANA address (POPA) Post-PANA address (POPA)
This is the address (optionally) configured after a successful This is an IP address (optionally) configured on a PANA client
authentication. after a successful authentication.
IPsec Tunnel Inner Address (IPsec-TIA) IPsec Tunnel Inner Address (IPsec-TIA)
This is the address used as the inner address of an IPsec tunnel This is an IP address configured on a PANA client as the inner
mode SA. When IPsec protection is used, depending on the address of an IPsec tunnel mode SA.
deployment scenario used either a PRPA or POPA becomes the
IPsec-TIA.
IPsec Tunnel Outer Address (IPsec-TOA) IPsec Tunnel Outer Address (IPsec-TOA)
This is the address used as the outer address of an IPsec tunnel This is the address configured on a PANA client as the outer
mode SA. When IPsec protection is used, a PRPA becomes the address of an IPsec tunnel mode SA.
IPsec-TOA.
Secure Association Protocol
A protocol that provides 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 IP-based access control.
3. General PANA Framework 3. General PANA Framework
PANA protocol is designed to facilitate authentication and PANA protocol is designed to facilitate authentication and
authorization of client hosts in access networks. PANA is an EAP authorization of clients in access networks. PANA is an EAP
[I-D.ietf-eap-rfc2284bis] lower-layer that carries EAP authentication [RFC3748] lower-layer that carries EAP authentication methods
methods encapsulated inside EAP between a client host and an agent in encapsulated inside EAP between a client host and an agent in the
the access network. While PANA enables the authentication process access network. While PANA enables the authentication process
between the two entities, it is only a part of an overall AAA and between the two entities, it is only a part of an overall AAA and
access control framework. A AAA and access control framework using access control framework. A AAA and access control framework using
PANA is comprised of four functional entities. PANA is comprised of four functional entities.
PANA Client (PaC): PANA Client (PaC):
The client implementation of the PANA protocol. This entity The PaC is the client implementation of the PANA protocol. This
resides on the client host that is requesting access to a local entity resides on the end host that is requesting network access.
area network. Example client hosts can be laptops, PDAs, cell The end hosts are, for example, laptops, PDAs, cell phones,
phones, desktops that are connected to a network via wired or desktop pcs that are connected to a network via a wired or
wireless networks. A PaC is responsible for requesting network wireless interface. A PaC is responsible for requesting network
access and engaging in authentication process using the PANA access and engaging in the authentication process using the PANA
protocol. protocol
PANA Authentication Agent (PAA): PANA Authentication Agent (PAA):
The server implementation of the PANA protocol. A PAA is in The PAA is the server implementation of the PANA protocol. A PAA
charge of interfacing with the PaCs for authenticating and is in charge of interfacing with the PaCs for authenticating and
authorizing them for the network access service. authorizing them for the network access service.
The PAA consults an authentication server in order to verify the The PAA consults an authentication server in order to verify the
credentials and rights of a PaC. If the authentication server credentials and rights of a PaC. If the authentication server
resides on the same host as the PAA, an API is sufficient for this resides on the same host as the PAA, an API is sufficient for this
interaction. When they are separated (a much more common case in interaction. When they are separated (a much more common case in
public access networks), a protocol needs to run between the two. public access networks), a protocol needs to run between the two.
LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and
Diameter [RFC3588] are commonly used for this purpose. Diameter [RFC3588] are 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 host, an API is sufficient for this residing on the same host, 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. While not
prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]
is suggested for this task. is suggested for this task.
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 local area network. PAA can be hosted on any access server) in the local area network. PAA can be hosted on
IP-enabled node on the same IP subnet as the PaC. For example on any IP-enabled node on the same IP subnet as the PaC. For example
a BAS (broadband access server) in DSL networks, or PDSN in 3GPP2 on a BAS (broadband access server) in DSL networks, or PDSN in
networks. 3GPP2 networks.
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
credentials of a PaC that is requesting the network access credentials of a PaC that is requesting the network access
service. The AS receives requests from the PAA on behalf of the service. The AS receives requests from the PAA on behalf of the
PaCs, and responds with the result of verification together with PaCs, and responds with the result of verification together with
the authorization parameters (e.g., allowed bandwidth, IP the authorization parameters (e.g., allowed bandwidth, IP
configuration, etc). The AS might be hosted on the same host as configuration, etc). The AS might be hosted on the same host as
the PAA, on a dedicated host on the access network, or on a the PAA, on a dedicated host on the access network, or on a
central server somewhere on the Internet. central server somewhere on the Internet.
Enforcement Point (EP): Enforcement Point (EP):
The access control implementation that is in charge of allowing The access control implementation that is in charge of allowing
access to authorized clients while preventing access by others. access to authorized clients while preventing access by others.
An EP learns the attributes of the authorized clients from the An EP learns the attributes of the authorized clients from the
PAA. PAA.
The EP uses non-cryptographic or cryptographic filters to
The EP uses simple or cryptographic filters to selectively allow selectively allow and discard data packets. These filters may be
and discard data packets. These filters may be applied at the applied at the link-layer or the IP-layer. When cryptographic
link-layer or the IP-layer. When cryptographic access control is access control is used, a secure association protocol needs to run
used, a secure association protocol needs to run between the PaC between the PaC and EP. Link or network layer protection (for
and EP. This protocol provides the cryptographic binding between example TKIP, IPsec ESP) is used after the secure association
the communication channel and the authorization state. Examples of protocol established the necessary security association to enable
secure association protocols include the 4-way handshake in IEEE integrity protection, data origin authentication, replay
802.11i [802.11i], and IKE in IP-based access control. Link-layer protection and optionally confidentiality protection.
ciphering or IPsec [I-D.ietf-pana-ipsec] is used following the
secure association to enable per-packet integrity, authentication
and replay protection (and optionally confidentiality).
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. For
example, the EP can be hosted on the switch that is directly example, the EP can be hosted on the switch that is directly
connected to the clients in a wired network. That way the EP can connected to the clients in a wired network. That way the EP can
drop unauthorized packets before they reach any other client host drop unauthorized packets before they reach any other client host
or beyond the local area network. or beyond the local area network.
Figure 1 illustrates these functional entities and the interfaces Figure 1 illustrates these functional entities and the interfaces
(protocols, APIs) among them. (protocols, APIs) among them.
  Skipping to change at page 8, line 4:
|<------------------------------>|<-------------->| |<------------------------------>|<-------------->|
| | SNMP | | | | SNMP | |
(Optional) | |<-------------->| | (Optional) | |<-------------->| |
IP address o | | | IP address o | | |
config. | Sec.Assoc. | | | config. | 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) for the unauthorized PaCs. This PANA, DHCP, router discovery) 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 configure an IP address prior to running PANA. After the The PaC MUST configure an IP address prior to running PANA. After
successful PANA authentication, depending on the deployment scenario the successful PANA authentication, depending on the deployment
PaC MAY need to re-configure its IP address or configure additional scenario the PaC MAY need to re-configure its IP address or configure
IP address(es). The additional address configuration MAY be executed additional IP address(es). The additional address configuration MAY
as part of the secure association protocol run. be executed as part of the secure association protocol run.
An initially unauthorized PaC starts the PANA authentication by An initially unauthorized PaC starts the PANA authentication by
discovering the PAA on the access network, followed by the EAP discovering the PAA on the access network, followed by the EAP
exchange over PANA. The PAA interfaces with the AS during this exchange over PANA. The PAA interacts with the AS during this
process. Upon receiving the authentication and authorization result process. Upon receiving the authentication and authorization result
from the AS, the PAA informs the PaC about the result of its network from the AS, the PAA informs the PaC about the result of its network
access request. access request.
If the PaC is authorized to gain the access to the network, the PAA If the PaC is authorized to gain the access to the network, the PAA
also sends the PaC-specific attributes (e.g., IP address, also sends the PaC-specific attributes (e.g., IP address,
cryptographic keys, etc.) to the EP by using SNMP. The EP uses this cryptographic keys, etc.) to the EP by using SNMP. The EP uses this
information to alter its filters for allowing data traffic from and information to alter its filters for allowing data traffic from and
to the PaC to pass through. to the PaC to pass through.
In case a cryptographic access control needs to be enabled after the In case cryptographic access control needs to be enabled after the
PANA authentication, a secure association protocol runs between the PANA authentication, a secure association protocol runs between the
PaC and the EP. The PaC should already have the input parameters to PaC and the EP. The PaC should already have the input parameters to
this process as a result of the successful PANA exchange. Similarly, this process as a result of the successful PANA exchange. Similarly,
the EP should have obtained them from the PAA via SNMP. Secure the EP should have obtained them from the PAA via SNMP. Secure
association exchange produces the required security associations association exchange produces the required security associations
between the PaC and the EP to enable per-packet protection. between the PaC and the EP to enable cryptographic data traffic
protection. Per-packet cryptographic data traffic protection
introduces additional per-packet overhead but the overhead exists
only between the PaC and EP and will not affect communications beyond
the EP. In this sense it is important to place the EP as close to
the edge of the network as possible.
Finally data traffic can start flowing from and to the newly Finally data traffic can start flowing from and to the newly
authorized PaC. authorized PaC.
4. Environments 4. Environments
The PANA protocol can be used on any network environment whether The PANA protocol can be used on any network environment whether
there is a lower-layer secure channel prior to PANA, or one has to be there is a lower-layer secure channel prior to PANA, or one has to be
enabled upon successful PANA authentication. The secure channel enabled upon successful PANA authentication.
enabled by PANA may rely on link-layer ciphering or IP-layer
ciphering.
Two types of networks are: With regard to network access authentication two types of networks
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
These are the networks where the lower-layer is already providing This type of network is characterized by the existence of
protection against spoofing and eavesdropping (nevertheless the protection against spoofing and eavesdropping. Nevertheless, user
client is still required to get authenticated and authorized for authentication and authorization is required for network
the network access service). connectivity.
One example is a DSL network where the lower-layer security is
One example is the DSL networks where the lower-layer security is
provided by physical means (a.1). Physical protection of the provided by physical means (a.1). Physical protection of the
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 the cdma2000 networks where the lower-layer security is is a cdma2000 network where the lower-layer security is provided
provided by means of cryptographic protection (a.2). By the time by means of cryptographic protection (a.2). By the time the
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 bound to the communication channel it was
carried over. Also, the choice of EAP authentication method carried over. Also, the choice of EAP authentication method
depends on the presence of this security during PANA run. Use of depends on the presence of this security during PANA run. Use of
some authentication methods outside a secure channel is not some authentication methods outside a secure channel is not
recommended (e.g., EAP-MD5). recommended (e.g., EAP-MD5).
b. Networks where a secure channel is created after running PANA b. Networks where a secure channel is created after running PANA
  Skipping to change at page 9, line 46:
carried over. Also, the choice of EAP authentication method carried over. Also, the choice of EAP authentication method
depends on the presence of this security during PANA run. Use of depends on the presence of this security during PANA run. Use of
some authentication methods outside a secure channel is not some authentication methods outside a secure channel is not
recommended (e.g., EAP-MD5). recommended (e.g., EAP-MD5).
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 protection. association protocol to enable per-packet cryptographic
protection.
PANA authentication is run on an insecure channel that is PANA authentication is run on an insecure channel that is
vulnerable to eavesdropping and spoofing. The choice of EAP vulnerable to eavesdropping and spoofing. The choice of EAP
method must be resilient to the possible attacks associated with method must be resilient to the possible attacks associated with
such an environment. Furthermore, the EAP method must be able to such an environment. Furthermore, the EAP method must be able to
create cryptographic keys that will later be used by the secure create cryptographic keys that will later be used by the secure
association protocol. association protocol.
Whether to use a link-layer per-packet security (b.1) or an Whether to use a link-layer per-frame security (b.1) or a network
IP-layer one (b.2) is a deployment decision. This decision also layer security (b.2) is a deployment decision. This decision also
dictates the choice of the secure association protocol. If dictates the choice of the secure association protocol. If
link-layer protection is used, the protocol would be link link-layer protection is used, the protocol would be link-layer
technology specific. If IP-layer protection is used, the secure specific. If IP-layer protection is used, the secure association
association protocol would be IKE and the per-packet security protocol would be IKE and the per-packet security would be
would be provided by IPsec regardless of the link type. provided by IPsec AH/ESP regardless of the underlying link-layer
technology.
5. IP Address Configuration 5. IP Address Configuration
PaC configures an IP address before the PANA protocol exchange The PaC configures an IP address before the PANA protocol exchange
begins. This address is called a pre-PANA address (PRPA). After a begins. This address is called a pre-PANA address (PRPA). After a
successful authentication, the client may have to configure a successful authentication, the client may have to configure a
post-PANA address (POPA) for communication with other nodes, if PRPA post-PANA address (POPA) for communication with other nodes, if PRPA
is a local-use (e.g., link-local or private address) or a temporarily is a local-use (e.g., link-local or private address) or a temporarily
allocated IP address. An operator might choose allocating a POPA allocated IP address. An operator might choose allocating a POPA
only after successful PANA authorization either to prevent waste of only after successful PANA authorization either to prevent waste of
premium IP resources until the client is authorized, or to enable premium IP resources until the client is authorized, or to enable
client identity based address assignment. client identity based address assignment.
In case PaC is a IPv4-IPv6 dual-stack host, it may configure more In case the PaC is a IPv4/IPv6 dual-stacked host, it may configure
than one PRPA, at least one for each protocol. Nevertheless, the PaC more than one PRPA. After a successful PANA authentication the PaC
needs only one to run PANA which is executed once regardless of the may configure multiple POPAs.
type and number of IP stacks. After successful PANA authentication,
similarly PaC may configure multiple POPAs.
There are different methods by which a PRPA can be configured. There are different methods by which a PRPA can be configured.
1. In some deployments (e.g., DSL networks) the PaC may be statically 1. In some deployments (e.g., DSL networks) the PaC may be
configured with an IP address. This address SHOULD be used as statically configured with an IP address. This address SHOULD be
PRPA. used as PRPA.
2. In IPv4, most clients attempt to configure an address dynamically 2. In IPv4, most clients attempt to configure an address dynamically
using DHCP [RFC2131]. If they are unable to configure an address using DHCP [RFC2131]. If they are unable to configure an address
using DHCP, they can configure a link-local address using using DHCP, they can configure a link-local address using
[I-D.ietf-zeroconf-ipv4-linklocal]. [I-D.ietf-zeroconf-ipv4-linklocal].
When the network access provider is able to run a DHCP server on When the network access provider is able to run a DHCP server on
the access link, the client would configure the PRPA using DHCP. the access link, the client would configure the PRPA using DHCP.
This address may be from a private address pool [RFC1918]. Also, This address may be from a private address pool [RFC1918]. Also,
the lease time on the address may vary. For example, a PRPA the lease time on the address may vary. For example, a PRPA
  Skipping to change at page 11, line 49:
PRPA may be used for local-use only (i.e., only for on-link 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 communication, such as for PANA and IPsec tunneling with EP), or
also for ultimate data communication. also for ultimate data communication.
In case there is no running DHCP server on the link, the client In case there is no running DHCP server on the link, the client
would fall back to configuring a PRPA via zeroconfiguration would fall back to configuring a PRPA via zeroconfiguration
technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a
long-term address that can only be used for on-link communication. long-term address that can only be used for on-link communication.
3. In IPv6, clients configure a link-local address [RFC2462] when 3. In IPv6, clients configure a link-local address [RFC2462] when
they initialize an interface. This address SHOULD be used as they initialize an interface. This address SHOULD be used as a
PRPA. PRPA.
When a PRPA is configured, the client starts the PANA protocol When a PRPA is configured, the client starts the PANA protocol
exchange. By that time, a dual-stack client might have configured exchange. By that time, a dual-stacked client might have configured
both an IPv4 address, and one or more IPv6 addresses as PRPAs. When both an IPv4 address, and one or more IPv6 addresses as PRPAs. When
the client successfully authenticates to the network, it may be the client successfully authenticates to the network, it may be
required to configure POPAs for its subsequent data communication required to configure POPAs for its subsequent data communication
with the other nodes. with the other nodes.
If the client is already configured with a non-temporary address that If the client is already configured with a non-temporary address that
can be used with data communication, it is not required to configure can be used with data communication, it is not required to configure
a POPA. Otherwise, PAA would indicate PaC the available POPA a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to
configuration methods through the PANA-Bind-Request message. PaC can indicate the available configuration methods to the PaC. The PaC can
choose one of the methods and execute accordingly. choose one of the methods and act accordingly.
1. If the network relies on physical or link-layer security, PaC can 1. If the network relies on physical or link-layer security, the PaC
configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6 can configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6
stateless auto-configuration [RFC2461]. If IPv4 is being used, stateless auto-configuration [RFC2461]. If IPv4 is being used, a
PRPA is likely to be a link-local or private address, or an PRPA is likely to be a link-local or private address, or an
address with a short DHCP lease. An IPv4 PRPA SHOULD be address with a short DHCP lease. An IPv4 PRPA SHOULD be
unconfigured when the POPA is configured to prevent IPv4 address unconfigured when the POPA is configured to prevent IPv4 address
selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is
used, the link-local PRPA address SHOULD NOT be unconfigured used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484].
[RFC3484].
If the PaC is a dual-stack host, it can configure both IPv4 and If the PaC is a dual-stacked host, it can configure both IPv4 and
IPv6 type POPAs. IPv6 type POPAs.
PRPA and the IP address of PAA are assumed to be on the same IP The PaC with a PRPA and the PAA with IP address X can perform
subnet, hence the PaC and PAA can perform on-link communication as on-link communication as required by PANA. In IPv4, the PRPA and
required by PANA. When the PaC replaces its IPv4 PRPA with POPA, IP address X have the same on-link prefix. In IPv6, the two
this assumption may not hold true. In order to maintain the same addresses are link-local addresses. When the PaC replaces its
on-link communication, the PaC and PAA SHOULD create host routes IPv4 PRPA with an IPv4 POPA, the PaC and PAA SHOULD create host
to each other upon PaC's IP address change. The PaC SHOULD create routes to each other, as they do not share the same on-link prefix
a host route to the PAA, and the PAA SHOULD create a host route to any more. This is needed for the PaC with the IPv4 POPA and the
the PaC (POPA). PAA with IP address X to continue on-link communication. In this
case, the PaC SHOULD create a host route to IP address X, and the
PAA SHOULD create a host route to the IPv4 POPA. PANA defines a
mechanism for the PaC to report the POPA to the PAA.
2. If the network uses IPsec for protecting the traffic on the link 2. If the network uses IPsec for protecting the traffic on the link
subsequent to PANA authentication [I-D.ietf-pana-ipsec], PaC would subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
use the PRPA as the outer address of IPsec tunnel mode SA would use the PRPA as the outer address of IPsec tunnel mode SA
(IPsec-TOA). PaC also needs to configure an inner address (IPsec-TOA). The PaC also needs to configure an inner address
(IPsec-TIA). There are different ways to configure IPsec-TIA (IPsec-TIA). There are different ways to configure an IPsec-TIA
which are indicated in Pana-Bind-Request message. which are indicated in a PANA-Bind-Request message.
When an IPv4 PRPA is configured, the same address may be used as 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 both IPsec-TOA and IPsec-TIA. In this case, a POPA is not
configured. Alternatively, an IPsec-TIA can be obtained via the configured. Alternatively, an IPsec-TIA can be obtained via the
configuration method available within [RFC3456] for IPv4, and configuration method available within [RFC3456] for IPv4, and
[I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly
configured address constitutes a POPA. Please refer to configured address constitutes a POPA. Please refer to
[I-D.ietf-pana-ipsec] for more details. [I-D.ietf-pana-ipsec] for more details.
IKEv2 can enable configuration of both IPv4 and IPv6 TIAs for the IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6
same IPsec tunnel mode SA. Therefore, IKEv2 is recommended for IPsec-TIA for the same IPsec tunnel mode SA. Therefore, IKEv2 is
handling dual-stack PaCs where single execution of PANA and IKE is recommended for handling dual-stacked PaCs where single execution
desired. of PANA and IKE is desired.
Although there are potentially a number of different ways to Although there are potentially a number of different ways to
configure a PRPA, and POPA when necessary, it should be noted that 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 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 depends on the operator. The decision is dictated by the operator's
choice of per-packet protection capability (physical and link-layer choice of per-packet protection capability (physical and link-layer
vs network-layer), PRPA type (local and temporary vs global and vs network-layer), PRPA type (local and temporary vs global and
long-term), and POPA configuration mechanisms available in the long-term), and POPA configuration mechanisms available in the
network. network.
6. Data Traffic Protection 6. Data Traffic Protection
Protecting data traffic of authenticated and authorized client from Protecting data traffic of authenticated and authorized client from
others is another component of providing a complete secure network others is another component of providing a complete secure network
access solution. Authentication, integrity and replay protection of access solution. Authentication, integrity and replay protection of
data packets are needed to prevent spoofing when the underlying data packets is needed to prevent spoofing when the underlying
network is not physically secured. Encryption is needed when network is not physically secured. Encryption is needed when
eavesdropping is a concern in the network. eavesdropping is a concern in the network.
When the network is physically secured, or the link-layer ciphering When the network is physically secured, or the link-layer ciphering
is already enabled prior to PANA, data traffic protection is already is already enabled prior to PANA, data traffic protection is already
in place. In other cases, enabling link-layer ciphering or in place. In other cases, enabling link-layer ciphering or
network-layer ciphering might rely on PANA authentication. The user network-layer ciphering might rely on PANA authentication. The user
and network have to make sure an appropriate EAP method that can and network have to make sure that an appropriate EAP method which
generate required keying materials is used. Once the keying material generates keying materials is used. Once the keying material is
is available, it needs to be provided to the EP(s) for use with available, it needs to be provided to the EP(s) for use with data
ciphering. traffic protection.
Network-layer ciphering, i.e., IPsec, can be used when data traffic Network-layer protection, i.e., IPsec, can be used when data traffic
protection is required but link-layer ciphering capability is not protection is required but link-layer protection is not available.
available. Note that a simple shared secret generated by an EAP Note that the keying material generated by an EAP method is not
method is not readily usable by IPsec for authentication and readily usable by IPsec AH/ESP or most link layer mechanisms. A
encryption of IP packets. Fresh and unique session key derived from fresh and unique session key derived from the EAP method is still
the EAP method is still insufficient to produce an IPsec SA since insufficient to produce an IPsec SA since both traffic selectors and
both traffic selectors and other IPsec SA parameters are missing. other IPsec SA parameters are missing. The shared secret can be used
The shared secret can be used in conjunction with a key management in conjunction with a key management protocol like IKE [RFC2409] to
protocol like IKE [RFC2409] to turn a simple shared secret into the turn a session key into the required IPsec SA. The details of such a
required IPsec SA. The details of such a mechanism is outside the mechanism is outside the scope of PANA protocol and is specified in
scope of PANA protocol and is specified in [I-D.ietf-pana-ipsec]. [I-D.ietf-pana-ipsec]. PANA provides bootstrapping functionality for
PANA provides bootstrapping functionality for such a mechanism by such a mechanism by carrying EAP methods that can generate initial
carrying EAP methods that can generate initial keying material. keying material.
Using network-layer ciphers should be regarded as a substitute for Using network-layer ciphers should be regarded as a substitute for
link-layer ciphers when the latter is not available. Network-layer link-layer ciphers when the latter is not available. Network-layer
ciphering can also be used in addition to link-layer ciphering if the 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 added benefits outweigh its cost to the user and the network. In
this case, PANA bootstraps only the network-layer ciphering and this case, PANA bootstraps only the network-layer ciphering and
link-layer is protected using any of the existing link-layer specific link-layer is protected using any of the existing link-layer specific
methods. methods.
7. PAA-EP Protocol 7. PAA-EP Protocol
The PANA protocol provides client authentication and authorization The PANA protocol provides client authentication and authorization
functionality for securing network access. The other component of a functionality for securing network access. The other component of a
complete solution is the access control which ensures that only complete solution is the access control which ensures that only
authenticated and authorized clients can gain access to the network. authenticated and authorized clients can gain access to the network.
PANA enables access control by identifying legitimate clients and PANA enables access control by distinguishing authenticated and
generating filtering information for access control mechanisms. authorized clients from others and generating filtering information
for access control mechanisms.
Access control can be achieved by placing EPs (Enforcement Points) in Access control can be achieved by placing EPs (Enforcement Points) in
the network for policing the traffic flow. EPs should prevent data the network for policing the traffic flow. EPs should prevent data
traffic from and to any unauthorized client unless it's either PANA 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 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
discovery, DHCP, etc.). discovery, DHCP, etc.).
When a client is authenticated and authorized, PAA should notify When a PaC is authenticated and authorized, the PAA should notify
EP(s) and ask for changing filtering rules to allow traffic for a EP(s) and ask for installing filtering rules to allow the PaC to sent
recently authorized client. There needs to be a protocol between PAA and receive data traffic. SNMP is used between PAA and EP(s) for
and EP(s) when these entities are not co-located. PANA Working Group this purpose when these entities are not co-located
will not be defining a new protocol for this interaction. Instead, [I-D.ietf-pana-snmp].
it identifies one of the existing protocols that can fit the
requirements. An assessment was made in the PANA Working Group and
SNMPv3 has been chosen as the mandatory PAA-EP protocol.
This section describes the possible models on the location of PAA and This section describes the possible models on the location of PAA and
EP, as well as the basic authorization information that needs to be 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 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 a single device, there are other issues such as dead or rebooted peer
detection and consideration for specific authorization and accounting detection and consideration for specific authorization and accounting
models. However, these issues are closely related to the PAA-EP models. However, these issues are closely related to the PAA-EP
protocol solution and thus not discussed in this document. See protocol solution and thus not discussed in this document. See
[I-D.ietf-pana-snmp] for further discussion. [I-D.ietf-pana-snmp] for further discussion.
  Skipping to change at page 16, line 14:
7.1.1 Single PAA, Single EP, Co-located 7.1.1 Single PAA, Single EP, Co-located
This model corresponds to the legacy NAS model. Since the PAA and This model corresponds to the legacy NAS model. Since the PAA and
the EP are co-located, the PAA-EP communication can be implemented the EP are co-located, the PAA-EP communication can be implemented
locally by using, e.g., IPC (Inter-Process Communication). The only locally by using, e.g., IPC (Inter-Process Communication). The only
difference from the legacy NAS model is the case where there are difference from the legacy NAS model is the case where there are
multiple co-located PAA/EP devices on the same IP link and the PAA/EP multiple co-located PAA/EP devices on the same IP link and the PAA/EP
devices are L2 switches or access points. In this case, for a PaC devices are L2 switches or access points. In this case, for a PaC
that attaches to a given PAA/EP device, other PAA/EP devices should that attaches to a given PAA/EP device, other PAA/EP devices should
not be visible to the PaC even if those devices are on the same IP not be discovered by the PaC even if those devices are on the same IP
link. Otherwise, the PaC may result in finding a PAA that is not the link. Otherwise, the PaC may result in finding a PAA that is not the
closest one to it during the PANA discovery and initial handshake closest one to it during the PANA discovery and initial handshake
phase and performing PANA with the wrong PAA. To prevent this, each phase and performing PANA with the PAA, which does not correspond to
PAA/EP device on an L2 switch or access point should not forward the legacy NAS model. To prevent this, each PAA/EP device on an L2
multicast PANA discovery message sent by PaCs attached to it to other switch or access point should not forward multicast PANA discovery
devices. message sent by PaCs attached to it to other devices.
7.1.2 Separate PAA and EP 7.1.2 Separate PAA and EP
When PAA is separated from EP, two cases are possible with regard to When PAA is separated from EP, two cases are possible with regard to
whether PAA and EP are located in parallel or serial when viewed from whether PAA and EP are located in parallel or serial when viewed from
PaC, for each of models described in this section. PaC, for each of models described in this section.
In the first case, PAA is located behind EP. The EP should be In the first case, PAA is located behind EP. The EP should be
configured to always pass through PANA messages and address configured to always pass through PANA messages and address
configuration protocol messages used for configuring an IP address configuration protocol messages used for configuring an IP address
  Skipping to change at page 18, line 38:
When PAA and EP are separated and PAA is configured to be the When PAA and EP are separated and PAA is configured to be the
initiator of the discovery and initial handshake phase of PANA, EP initiator of the discovery and initial handshake phase of PANA, EP
has the responsibility to detect presence of a new PaC and notifies has the responsibility to detect presence of a new PaC and notifies
the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a
presence notification is carried in a PAA-EP protocol message presence notification is carried in a PAA-EP protocol message
[I-D.ietf-pana-snmp]. [I-D.ietf-pana-snmp].
7.3 Filter Rule Installation 7.3 Filter Rule Installation
Filtering rules to be installed on EP generally include a device Filtering rules to be installed on EP generally include a device
identifier of PaC, and also cryptographic keying material (such as identifier of PaC, and also cryptographic keying material (e.g., IKE
keys, key pairs, and initialization values) when needed. The keying pre-shared key [RFC2409]) when cryptographic data traffic protection
material is needed when attackers can eavesdrop and spoof on the is needed (See Section 6). Each keying material is uniquely
device identifiers easily. Each keying material is uniquely identified with a keying material name (e.g., ID_KEY_ID in IKE
identified with a keying material name and has a lifetime for key [RFC2409]) and has a lifetime for key management, accounting, access
management purpose. The keying material is used with link-layer or control and security reasons in general. In addition to the device
network-layer ciphering to provide additional protection. For issues identifier and keying material, other filter rules, such as the IP
regarding data-origin authentication see Section 6. In addition to filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
the device identifier and keying material, other filter rules, such EAP application [I-D.ietf-aaa-eap] may be installed on EP.
as the IP filter rules specified in NAS-Filter-Rule AVPs carried in
Diameter EAP application [I-D.ietf-aaa-eap] may be installed on EP.
8. Network Selection 8. Network Selection
The network selection problem statement is made in The network selection problem statement is made in
[I-D.ietf-eap-netsel-problem]. The PANA protocol [I-D.ietf-eap-netsel-problem]. The PANA protocol
[I-D.ietf-pana-pana] provides a way for networks to advertise which [I-D.ietf-pana-pana] provides a way for networks to advertise which
ISPs are available and for PaC to choose one ISP from the advertised ISPs are available and for PaC to choose one ISP from the advertised
information. When a PaC chooses an ISP in the PANA protocol information. When a PaC chooses an ISP in the PANA protocol
exchange, the ultimate destination of the AAA exchange is determined exchange, the ultimate destination of the AAA exchange is determined
based on the identity of the chosen service provider. It is also based on the identity of the chosen service provider. It is also
  Skipping to change at page 20, line 8:
protocol instead of L2-specific authentication mechanisms, the IP protocol instead of L2-specific authentication mechanisms, the IP
link between PaC and PAA needs to exist prior to doing PANA (and link between PaC and PAA needs to exist prior to doing PANA (and
prior to network selection). In this model, the PRPA is either given prior to network selection). In this model, the PRPA is either given
by NAP or a link-local address is auto-configured. After the by NAP or a link-local address is auto-configured. After the
successful authentication with the ISP, PaC may acquire an address successful authentication with the ISP, PaC may acquire an address
(POPA) from the ISP. It also learns the address of the AR, e.g., (POPA) from the ISP. It also learns the address of the AR, e.g.,
through DHCP, to be used as its default router. The address of the 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. AR may or may not be in the same IP subnet as that of the PaC's POPA.
If they don't share the same prefix, they SHOULD use host routes to If they don't share the same prefix, they SHOULD use host routes to
reach each other. Note that the physically secured DSL networks do reach each other. Note that the physically secured DSL networks do
not require IPsec-based access control. Therefore the PaCs use one IP not require IPsec-based access control. Therefore the PaCs use one
address at a time where POPA replaces PRPA upon configuration. IP address at a time where POPA replaces PRPA upon configuration.
9. Authentication Method Choice 9. Authentication Method Choice
Authentication methods' capabilities and therefore applicability to Authentication methods' capabilities and therefore applicability to
various environments differ among them. Not all methods provide various environments differ among them. Not all methods provide
support for mutual authentication, key derivation or distribution, support for mutual authentication, key derivation or distribution,
and DoS attack resiliency that are necessary for operating in and DoS attack resiliency that are necessary for operating in
insecure networks. Such networks might be susceptible to insecure networks. Such networks might be susceptible to
eavesdropping and spoofing, therefore a stronger authentication eavesdropping and spoofing, therefore a stronger authentication
method needs to be used to prevent attacks on the client and the method needs to be used to prevent attacks on the client and the
network. network.
The authentication method choice is a function of the underlying The authentication method choice is a function of the underlying
security of the network (e.g., physically secured, shared link, security of the network (e.g., physically secured, shared link,
etc.). It is the responsibility of the user and the network operator etc.). It is the responsibility of the user and the network operator
to pick the right method for authentication. PANA carries EAP to pick the right method for authentication. PANA carries EAP
regardless of the EAP method used. It is outside the scope of PANA to regardless of the EAP method used. It is outside the scope of PANA
mandate, recommend, or limit use of any authentication methods. PANA to mandate, recommend, or limit use of any authentication methods.
cannot increase the strength of a weak authentication method to make PANA cannot increase the strength of a weak authentication method to
it suitable for an insecure environment. There are some EAP-based make it suitable for an insecure environment. There are some
approaches to achieve this goal (see EAP-based approaches to achieve this goal (see
[I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls] [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls]
,[I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating ,[I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating
methods but it does not concern itself with how they achieve methods but it does not concern itself with how they achieve
protection for the weak methods (i.e., their EAP method payloads). protection for the weak methods (i.e., their EAP method payloads).
10. Example Cases 10. Example Cases
10.1 DSL Access Network 10.1 DSL Access Network
In a DSL access network, PANA is seen applicable in the following In a DSL access network, PANA is seen applicable in the following
  Skipping to change at page 23, line 4:
addresses from the NAS device by using DHCP or PPPoE. addresses from the NAS device by using DHCP or PPPoE.
If PPPoE is used, authentication is typically performed using CHAP or If PPPoE is used, authentication is typically performed using CHAP or
MS-CHAP. MS-CHAP.
PANA will be applicable when the hosts use DHCP to obtain IP address. PANA will be applicable when the hosts use DHCP to obtain IP address.
DHCP does not support authentication of the devices on either side of DHCP does not support authentication of the devices on either side of
the DSL access line. In the simplest method of address assignment, the DSL access line. In the simplest method of address assignment,
the NAS will allocate the IP address to a host with a lease time the NAS will allocate the IP address to a host with a lease time
reasonably sufficient to complete a full PANA based authentication reasonably sufficient to complete a full PANA based authentication
which will be triggered immediately after the address assignment. The which will be triggered immediately after the address assignment.
hosts will perform the PaC function and the NAS will perform the PAA, The hosts will perform the PaC function and the NAS will perform the
EP and AR functions. PAA, EP and AR functions.
Host--+ Host--+
(PaC) | (PaC) |
+----- CPE ---------------- NAS ------------- ISP +----- CPE ---------------- NAS ------------- ISP
| (Bridge) (PAA,EP,AR) | (Bridge) (PAA,EP,AR)
Host--+ Host--+
(PaC) (PaC)
Figure 8: Bridge Mode Figure 8: Bridge Mode
The DSL service provider's trunk network should not be accessible to The DSL service provider's trunk network should not be accessible to
any host that has not successfully completed the PANA authentication any host that has not successfully completed the PANA authentication
phase. phase.
10.1.2 Address Translation (NAPT) Mode 10.1.2 Router Mode
In the NAPT mode, the CPE is configured with the authentication
parameters (i.e. username, password). In this case, the CPE acts as a
"client" of the NAS. If the CPE uses DHCP to obtain the IP address,
PANA will be necessary to authenticate the CPE and the NAS to each
other.
Host--+
|
+----- CPE ---------------- NAS ------------- ISP
| (NAPT, PaC) (PAA,EP,AR)
Host--+
Figure 9: NAPT Mode
The CPE in this case typically acts as a DHCP server for the devices
at the customer premises network. It applies NAPT mechanisms to
forward traffic between the customer premises network and the NAS.
If the CPE is configured with a static IP address and does not
perform DHCP, it will need to initiate a PANA authentication phase
before gaining access to the service provider's network.
10.1.3 Router Mode
In this case, the CPE acts as a full-fledged router for the customer In this mode, the CPE acts as a router for the customer premises
premises network. The CPE itself may obtain the IP address using network. The CPE itself may obtain the IP address using DHCP or be
DHCP or be configured with static IP address. Once the CPE is configured with a static IP address. Once the CPE is authenticated
authenticated using PANA and is provided access to the service using PANA and is provided access to the service provider's network,
provider's network, the NAS should begin exchanging routing updates the NAS should begin exchanging routing updates with the CPE. All
with the CPE. All devices at the customer premises will then have devices at the customer premises will then have access to the service
access to the service provider's network. provider's network.
Host--+ Host--+
| |
+----- CPE ---------------- NAS ------------- ISP +----- CPE ---------------- NAS ------------- ISP
| (Router, PaC) (PAA,EP,AR) | (Router, PaC) (PAA,EP,AR)
Host--+ Host--+
Figure 10: Router Mode Figure 9: Router Mode
As in the NAPT mode, it is possible that both ends of the DSL link It is possible that both ends of the DSL link are configured with
are configured with static IP addresses. PANA-based mutual static IP addresses. PANA-based mutual authentication of CPE and NAS
authentication of CPE and NAS is desirable before data-traffic is is desirable before data-traffic is exchanged between the customer
exchanged between the customer premises network and the service premises network and the service provider network. The CPE router
provider network. may also use NAPT (Network Address Port Tranlation).
10.1.4 PANA and Dynamic Internet Service Provider Selection 10.1.3 PANA and Dynamic Internet Service Provider Selection
In some installations, a NAS device is shared by multiple service In some installations, a NAS device is shared by multiple service
providers. Each service provider configures the NAS with a certain IP providers. Each service provider configures the NAS with a certain
address space. IP address space.
The devices at the customer premises network indicate their choice of The devices at the customer premises network indicate their choice of
service provider and the NAS chooses the IP address from the service provider and the NAS chooses the IP address from the
appropriate service provider's pool. In many cases, the address is appropriate service provider's pool. In many cases, the address is
assigned not by the NAS but by the AAA server that is managed fully assigned not by the NAS but by the AAA server that is managed fully
by the service provider. by the service provider.
This simplifies the management of the DSL access network as it is not This simplifies the management of the DSL access network as it is not
always necessary to configure each DSL access line with the service always necessary to configure each DSL access line with the service
provider's identity. The service provider is chosen dynamically by provider's identity. The service provider is chosen dynamically by
  Skipping to change at page 24, line 47:
Provider selection". The AAA function is usually overloaded to Provider selection". The AAA function is usually overloaded to
perform dynamic ISP selection. perform dynamic ISP selection.
If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP
is chosen by mapping the username field of a CHAP response to a is chosen by mapping the username field of a CHAP response to a
provider. provider.
If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or
DHCP-request packet is mapped to the provider. DHCP-request packet is mapped to the provider.
10.1.4.1 Selection as Part of the DHCP protocol or an Attribute of DSL 10.1.3.1 Selection as Part of the DHCP protocol or an Attribute of DSL
Access Line Access Line
The ISP selection, therefore the IP address pool, can be conveyed The ISP selection, therefore the IP address pool, can be conveyed
based on the DHCP protocol exchange (as explained earlier), or by based on the DHCP protocol exchange (as explained earlier), or by
associating the DSL access line to the service provider before the associating the DSL access line to the service provider before the
PANA authentication begins. When any of these schemes is used, the PANA authentication begins. When any of these schemes is used, the
IP address used during PANA authentication (PRPA) is the ultimate IP IP address used during PANA authentication (PRPA) is the ultimate IP
address and it does not have to be changed upon successful address and it does not have to be changed upon successful
authorization. authorization.
10.1.4.2 Selection as Part of the PANA Authentication 10.1.3.2 Selection as Part of the PANA Authentication
The ISP selection of the client can be explicitly conveyed during the The ISP selection of the client can be explicitly conveyed during the
PANA authentication. In that case, the client can be assigned a PANA authentication. In that case, the client can be assigned a
temporary IP address (PRPA) prior to PANA authentication. This IP temporary IP address (PRPA) prior to PANA authentication. This IP
address might be obtained via DHCP with a lease reasonably long to address might be obtained via DHCP with a lease reasonably long to
complete PANA authentication, or via the zeroconf technique complete PANA authentication, or via the zeroconf technique
[I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA
authentication signalling prompts the client to obtain a new (long authentication signalling prompts the client to obtain a new (long
term) IP address via DHCP. This new IP address (POPA) replaces the term) IP address via DHCP. This new IP address (POPA) replaces the
previously allocated temporary IP address. previously allocated temporary IP address.
  Skipping to change at page 25, line 35:
most common WLAN deployments the IP addresses are dynamically most common WLAN deployments the IP addresses are dynamically
configured. Therefore this section does not cover the scenarios configured. Therefore this section does not cover the scenarios
where the IP address is statically configured. There are two models where the IP address is statically configured. There are two models
depending on which layer security is bootstrapped from PANA depending on which layer security is bootstrapped from PANA
authentication, L2 or L3. When PANA authentication is used for authentication, L2 or L3. When PANA authentication is used for
bootstrapping L3 security, L2 security is not necessarily to exist bootstrapping L3 security, L2 security is not necessarily to exist
even after PANA authentication. Instead, IPsec-based data traffic even after PANA authentication. Instead, IPsec-based data traffic
protection is bootstrapped from PANA. The PAA can indicate the PaC protection is bootstrapped from PANA. The PAA can indicate the PaC
as to whether L2 or L3 protection is needed, by including a as to whether L2 or L3 protection is needed, by including a
Protection-Capability AVP in PANA-Bind-Request message. In both Protection-Capability AVP in PANA-Bind-Request message. In both
cases, the most common deployment would be illustrated in Figure 11, cases, the most common deployment would be illustrated in Figure 10,
where EP is typically co-located with AP (access point) when PANA is where EP is typically co-located with AP (access point) when PANA is
used for bootstrapping L2 security or with AR when PANA is used for used for bootstrapping L2 security or with AR when PANA is used for
bootstrapping L3 security. bootstrapping L3 security.
+-----+ +-----+
|AP/EP|----+ |AP/EP|----+
+-----+ | +-----+ |
| |
+---+ +-----+ | +---------+ +---+ +-----+ | +---------+
|PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet
+---+ +-----+ | +---------+ +---+ +-----+ | +---------+
| |
+-----+ | +-----+ |
|AP/EP|----+ |AP/EP|----+
+-----+ +-----+
Figure 11: PANA Wireless LAN Model Figure 10: PANA Wireless LAN Model
10.2.1 PANA with Bootstrapping IPsec 10.2.1 PANA with Bootstrapping IPsec
In this model, data traffic is protected by using IPsec tunnel mode In this model, data traffic is protected by using IPsec tunnel mode
SA and an IP address is used as the device identifier of PaC (see SA and an IP address is used as the device identifier of PaC (see
Section 5 for details). Some or all of AP, DHCPv4 Server (including Section 5 for details). Some or all of AP, DHCPv4 Server (including
PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA 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 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 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 co-located, PAA-EP protocol is used for communication between PAA and
  Skipping to change at page 27, line 31:
| | | |------------>| | | | |------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 12: An example case for configuring IPsec-TIA by using Figure 11: An example case for configuring IPsec-TIA by using
DHCPv4 DHCPv4
Case B: IPsec-TIA obtained by using IKE Case B: IPsec-TIA obtained by using IKE
In this case, the PRPA is obtained by using DHCPv4 and used as In this case, the PRPA is obtained by using DHCPv4 and used as
IPsec-TOA. The POPA is obtained by using IKE (via a Configuration IPsec-TOA. The POPA is obtained by using IKE (via a Configuration
Payload exchange or equivalent) and used as IPsec-TIA. Payload exchange or equivalent) and used as IPsec-TIA.
Case C: IPsec-TIA obtained by using RFC3456 Case C: IPsec-TIA obtained by using RFC3456
  Skipping to change at page 28, line 32:
| | | | | | | |
|PANA(PBR-PBA exchange in authentication phase) | |PANA(PBR-PBA exchange in authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| | IKE | | | | IKE | |
| (with Configuration Payload exchange or equivalent) | | (with Configuration Payload exchange or equivalent) |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
| | | | | | | |
Figure 13: An example case for IPsec-TIA obtained by using IKE Figure 12: An example case for IPsec-TIA obtained by using IKE
PRPA PRPA
PaC AP DHCPv4 Server PAA PaC AP DHCPv4 Server PAA
| Link-layer | | | | Link-layer | | |
| association| | | | association| | |
|<---------->| | | |<---------->| | |
| | | | | | | |
| DHCPv4 | | | DHCPv4 | |
|<-----------+-------->| | |<-----------+-------->| |
| | | | | |
|PANA(Discovery and initial handshake phase |PANA(Discovery and initial handshake phase
  Skipping to change at page 29, line 38:
| (to create DHCP SA) | | (to create DHCP SA) |
|<-----------+------------>| |<-----------+------------>|
| | | | | |
| DHCP over DHCP SA | | DHCP over DHCP SA |
|<-----------+------------>| |<-----------+------------>|
| | | | | |
| IKEv1 phase II | | IKEv1 phase II |
| (to create IPsec SA for data traffic) | (to create IPsec SA for data traffic)
|<-----------+------------>| |<-----------+------------>|
Figure 14: An example case for configuring IPsec-TIA by using Figure 13: An example case for configuring IPsec-TIA by using
RFC3456 RFC3456
10.2.1.2 IPv6 10.2.1.2 IPv6
In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local
address. IPsec-TIA (POPA) is obtained by using Configuration Payload address. IPsec-TIA (POPA) is obtained by using Configuration Payload
exchange of IKE version 2 (Note that there is no standard method for exchange of IKE version 2 (Note that there is no standard method for
configuring IPsec-TIA in IKEv1). Other configuration information may configuring IPsec-TIA in IKEv1). Other configuration information may
be obtained in the same Configuration Payload exchange or may be be obtained in the same Configuration Payload exchange or may be
obtained by running an additional DHCPv6. obtained by running an additional DHCPv6.
  Skipping to change at page 30, line 31:
| | | | | | | |
|PANA(PBR-PBA exchange in authentication phase) |PANA(PBR-PBA exchange in authentication phase)
|<-----------+-------------------------->| |<-----------+-------------------------->|
| | | | | | | |
| IKEv2 | | | IKEv2 | |
|(w/Configuration Payload | | |(w/Configuration Payload | |
| exchange to obtain IPsec-TIA) | | exchange to obtain IPsec-TIA) |
|<-----------+------------>| | |<-----------+------------>| |
| | | | | | | |
Figure 15: An example sequence for configuring IPsec-TIA in IPv6 Figure 14: An example sequence for configuring IPsec-TIA in IPv6
10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i
In this model, PANA is used for authentication and authorization, and In this model, PANA is used for authentication and authorization, and
L2 ciphering is used for access control, the latter is enabled by the L2 ciphering is used for access control, the latter is enabled by the
former. The L2 ciphering is based on using PSK (Pre-Shared Key) mode former. The L2 ciphering is based on using PSK (Pre-Shared Key) mode
of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i], of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i],
which is derived from the EAP MSK as a result of successful PANA which is derived from the EAP MSK as a result of successful PANA
authentication. In this document, the pre-shared key shared between authentication. In this document, the pre-shared key shared between
station and AP is referred to as PMK (Pair-wise Master Key). In this station and AP is referred to as PMK (Pair-wise Master Key). In this
model, MAC address is used as the device identifier in PANA. model, MAC address is used as the device identifier in PANA.
A typical purpose of using this model is to reduce AP management cost This model allows the separation of PAA from APs (EPs). A typical
by allowing physical separation of RADIUS/Diameter client from access 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 points, where AP management can be a significant issue when deploying
a large number of access points. a large number of access points.
By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is
also possible to improve wireless LAN security by providing protected also possible to improve wireless LAN security by providing protected
disconnection procedure at L3. disconnection procedure at L3.
This model does not require any change in the current WPA and IEEE This model does not require any change in the current WPA and IEEE
802.11i specifications. This also means that PANA doesn't provide 802.11i specifications. This also means that PANA doesn't provide
any L2 security features beyond those already provided for in WPA and any L2 security features beyond those already provided for in WPA and
IEEE 802.11i. IEEE 802.11i.
10.2.2.1 Separate PAA and AP
When PAA and AP are separated, two (virtual) APs are needed, one is
connected to an unauthenticated VLAN and the other to an
authenticated VLAN. The former and latter APs are referred to as
unauthenticated VLAN AP and authenticated VLAN AP, respectively. If
a PaC does not have a PMK with the authenticated VLAN AP, it runs
PANA on the unauthenticated VLAN to obtain the MAC address of the
authenticated VLAN AP and derive the PMK valid for the AP. Once the
PMK is obtained, the PaC associates with the authenticated VLAN AP
with performing 4-way handshake. It configures an (potentially new)
IP address and starts sending and receiving data traffic. Future
PANA exchanges are carried on the IEEE 802.1X Controlled Port of the
authenticated VLAN AP just like any other data traffic.
Separating PAA and AP may be used in a network where there is a large
number of APs in a single IP subnet and the network administrator
want to avoid setting up RADIUS client on each AP. Note that the
network administrator would still need to set up SNMPv3 security
association between each AP and PAA for secure PAA-EP communication,
however, in the environments where operator can rely on physical
layer security between PAA and EP, this might not be the case.
In a typical usage scenario, a single PAA co-located with DHCP server
is connected to both unauthenticated VLAN and authenticated VLAN and
that the unauthenticated VLAN AP and the authenticated VLAN AP are
co-located in a single physical AP, as shown in Figure 16. Note that
in an environment where virtual AP are not supported, physical APs
can be used instead of virtual APs.
+------------------+
| Physical AP |
| +--------------+ |
| |Virtual AP1 | | Unauthenticated
| |(open-access) |---- VLAN \
| | | | \+-------+
+---+ | +--------------+ | |PAA/AR/|
|PaC| | | |DHCP |--- Internet
+---+ | +--------------+ | |Server |
| |Virtual AP2 | | /+-------+
| |(WPA PSK mode)|---- Authenticated /
| | | | VLAN
| +--------------+ |
| |
+------------------+
Figure 16: Separate PAA and AP with two virtual APs
When a PaC does not have a PMK with an authenticated VLAN AP, the
following procedure is taken:
1. The PaC associates with the unauthenticated VLAN AP.
2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or
configures a link-local address (in the case of IPv6), and then
runs PANA by using the address.
3. Upon successful authentication, the PaC obtains a distinct PMK
for each authenticated VLAN AP controlled by the PAA.
4. The PaC associated with an authenticated VLAN AP, with performing
4-way handshake to establish a PTK (Pair-wise Transient Key)
between the PaC and AP, by using the PMK.
5. If the PaC is required to configure a new IP address (POPA) as
signaled by the PAA at the end of successful authentication, it
should configure POPA by using any method that the client
normally uses. If PRPA is an IPv4 address, it should be
unconfigured before POPA configuration.
Note that switching from one VLAN to another is a commonly used
technique in WPA (even without PANA) where the client that does not
have any valid credentials first accesses the certificate server via
https through the unauthenticated VLAN to perform a sign-in procedure
to obtain a certificate, and then switches to the authenticated VLAN
with the obtained certificate.
When the MSK is updated as a result of EAP re-authentication, a new
PMK is derived for and transfered to each authenticated VLAN AP.
WPA/IEEE 802.11i 4-way handshake is performed between the PaC and its
currently associating authenticated VLAN AP to derive a new PTK.
10.2.2.2 Co-located PAA and AP
The IEEE 802.11 specification [802.11] allows Class 1 data frames to The IEEE 802.11 specification [802.11] allows Class 1 data frames to
be received in any state. Also, the latest version of IEEE 802.11i be received in any state. Also, the latest version of IEEE 802.11i
[802.11i] optionally allows higher-layer data traffic that is [802.11i] optionally allows higher-layer data traffic to be received
terminated between stations (including AP) are received and processed and processed on their IEEE 802.1X Uncontrolled Ports. This feature
on their IEEE 802.1X Uncontrolled Ports. This feature allows allows processing IP-based traffic (such as ARP, IPv6 neighbor
processing IP-based traffic (such as ARP, IPv6 neighbor discovery, discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to
DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client client authentication. (Note: WPA and its corresponding version of
authentication. (Note: WPA and its corresponding version of IEEE IEEE 802.11i draft do not explicitly define this operation, so it may
802.11i draft do not explicitly define this operation, so it may be be safer not to use this in WPA).
safer not to use this co-located PAA and AP case in WPA).
Until the PaC is successfully authenticated, only a selected type of Until the PaC is successfully authenticated, only a selected type of
IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any
other IP traffic is dropped on the AP without forwarding to the DS other IP traffic is dropped on the AP without being forwarded to the
(Distribution System). Upon successful PANA authentication, the DS (Distribution System). Upon successful PANA authentication, the
traffic switches to the controlled port. Host configuration, traffic switches to the controlled port. Host configuration,
including obtaining an (potentially new) IP address, takes place on including obtaining an (potentially new) IP address, takes place on
this port. Usual DHCP-based, and also in the case of IPv6 stateless this port. Usual DHCP-based, and also in the case of IPv6 stateless
autoconfiguration, mechanism is available to the PaC. After this autoconfiguration, mechanism is available to the PaC. After this
point, the rest of the IP traffic, including PANA exchanges, are point, the rest of the IP traffic, including PANA exchanges, are
processed on the controlled port. processed on the controlled port.
Since this case does not require virtual AP switching, the procedure When a PaC does not have a PMK for the AP, the following procedure is
to bootstrap PSK mode becomes simpler compared to the separate PAA taken:
and EP case, however, with a cost of configuring RADIUS/Diameter
client on each AP.
When a PaC does not have a PMK with an authenticated VLAN AP, the
following procedure is taken:
1. The PaC associates with the AP. 1. The PaC associates with the AP.
2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or
configures a link-local address (in the case of IPv6), and then configures a link-local address (in the case of IPv6), and then
runs PANA by using the address. runs PANA by using the address.
3. Upon successful authentication, the PaC obtains a PMK for each AP 3. Upon successful authentication, the PaC obtains a PMK for each AP
controlled by the PAA. controlled by the PAA.
4. The PaC performs 4-way handshake to establish a PTK (Pair-wise 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK
Transient Key) between the PaC and AP, by using the PMK. (Pair-wise Transient Key) with the PaC, by using the PMK.
5. The PaC obtains a POPA by using any method that the client 5. The PaC obtains a POPA by using any method that the client
normally uses. normally uses.
10.2.3 Capability Discovery 10.2.3 Capability Discovery
When a PaC is a mobile, there may be multiple APs available in its When a PaC is a mobile, there may be multiple APs available in its
vicinity. Each AP are connected to one of the following types of vicinity. Each AP are connected to one of the following types of
access networks. access networks.
  Skipping to change at page 34, line 38:
information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i
defines RSN Information Element for this purpose). Types (a) and (b) defines RSN Information Element for this purpose). Types (a) and (b)
are not distinguishable until the PaC associates with the AP, get an are not distinguishable until the PaC associates with the AP, get an
IP address, and engage in PANA discovery. The default PaC behavior IP address, and engage in PANA discovery. The default PaC behavior
would be to act as if this is a free network and attempt DHCP. This would be to act as if this is a free network and attempt DHCP. This
would be detected by the access network and trigger unsolicited PANA would be detected by the access network and trigger unsolicited PANA
discovery. A type (b) network would send a PANA-Start-Request to the discovery. A type (b) network would send a PANA-Start-Request to the
client and block general purpose data traffic. This helps the client client and block general purpose data traffic. This helps the client
discover whether the network is type (a) or type (b). Or if the PaC discover whether the network is type (a) or type (b). Or if the PaC
is pre-provisioned with the information that this is a PANA enabled is pre-provisioned with the information that this is a PANA enabled
network, it can attempt PAA discovery immediately. network, it can attempt PAA discovery immediately. The PaC behavior
after connecting to an AP of type (b) network is described in Section
The PaC behavior after connecting to an AP of type (b) network is 10.2, Section 10.2.1 and Section 10.2.2.
described in Section 10.2, Section 10.2.1 and Section 10.2.2. Note
that in case of using PANA for bootstrapping WPA/IEEE 802.11i PSK
mode (see Section 10.2.2), PaC needs to know whether PAA and AP are
separated (see Section 10.2.2.1) or co-located (see Section 10.2.2.2)
due to PaC having to act differently in each mode. This is achieved
by checking the existence of an EP-Device-Id AVP in PANA-Bind-Request
message (if an EP-Device-Id AVP is included then PAA is not
co-located with AP).
11. Open Issue 11. Open Issue
Certain combination of network environments and timing cases may Certain combination of network environments and timing cases may
require further considerations. require further considerations.
If PaC changes access point right after a successful PANA If PaC changes access point right after a successful PANA
authorization but before POPA configuration, it might be confused authorization but before POPA configuration, it might be confused
whether the new IP address configured via the new access point is the whether the new IP address configured via the new access point is the
POPA of the ongoing session or a PRPA of a new session. When the PRPA POPA of the ongoing session or a PRPA of a new session. When the
and POPA types or configuration mechanisms are different this is not PRPA and POPA types or configuration mechanisms are different this is
a problem. One possible combination where such clues are not not a problem. One possible combination where such clues are not
available is when PaC moves from a Case A of Section 10.2.1.1 available is when PaC moves from a Case A of Section 10.2.1.1
(IPsec-TIA obtained by using DHCPv4) network to a Case D of Appendix (IPsec-TIA obtained by using DHCPv4) network to a Case D of Appendix
A.1 (IPsec-TIA obtained by using RFC3118) network. A.1 (IPsec-TIA obtained by using RFC3118) network.
In another example, when PaC switches from one wired Ethernet hub to In another example, when PaC switches from one wired Ethernet hub to
another (without the use of bootstrapping IPsec) before configuring another (without the use of bootstrapping IPsec) before configuring
the POPA. In this case, PaC may not able to know whether an obtained the POPA. In this case, PaC may not able to know whether an obtained
address is the POPA in the same subnet or a PRPA in a new subnet. address is the POPA in the same subnet or a PRPA in a new subnet.
For these cases, a mechanism to remove the ambiguity (PRPA vs. POPA) For these cases, a mechanism to remove the ambiguity (PRPA vs. POPA)
may need to be defined. may need to be defined.
12. Acknowledgments 12. Acknowledgments
We would like to thank Bernard Aboba and Yacine El Mghazli for their We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner
valuable comments. and Hannes Tschofenig for their valuable comments.
Normative References 13. References
13.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.
[I-D.ietf-eap-rfc2284bis] [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Blunk, L., "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
draft-ietf-eap-rfc2284bis-09 (work in progress), February 3748, June 2004.
2004.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[I-D.ietf-zeroconf-ipv4-linklocal] [I-D.ietf-zeroconf-ipv4-linklocal]
Aboba, B., "Dynamic Configuration of Link-Local IPv4 Aboba, B., "Dynamic Configuration of Link-Local IPv4
Addresses", draft-ietf-zeroconf-ipv4-linklocal-14 (work in Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in
progress), April 2004. progress), July 2004.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. 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.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.
[I-D.ietf-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in
progress), April 2004. progress), April 2004.
[I-D.ietf-pana-pana] [I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Network Access (PANA)", draft-ietf-pana-pana-03 (work in Yegin, "Protocol for Carrying Authentication for Network
progress), February 2004. Access (PANA)", draft-ietf-pana-pana-04 (work in
progress), May 2004.
[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-02 (work in progress), Control", draft-ietf-pana-ipsec-03 (work in progress), May
March 2004. 2004.
[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.
[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.
13.2 Informative References
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
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] [I-D.ietf-eap-netsel-problem]
Arkko, J. and B. Aboba, "Network Discovery and Selection Arkko, J. and B. Aboba, "Network Discovery and Selection
Problem", draft-ietf-eap-netsel-problem-00 (work in Problem", draft-ietf-eap-netsel-problem-00 (work in
progress), January 2004. progress), January 2004.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. RFC 2486, January 1999.
[I-D.ietf-pana-requirements] [I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements", Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-07 (work in progress), June draft-ietf-pana-requirements-08 (work in progress), June
2003. 2004.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-08 (work in progress), June 2004.
[I-D.yegin-eap-boot-rfc3118] [I-D.yegin-eap-boot-rfc3118]
Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping
RFC3118 Delayed DHCP Authentication Using EAP-based RFC3118 Delayed DHCP Authentication Using EAP-based
Network Access Authentication", Network Access Authentication",
draft-yegin-eap-boot-rfc3118-00 (work in progress), draft-yegin-eap-boot-rfc3118-00 (work in progress),
February 2004. February 2004.
[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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
Informative References
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-05 (work in progress), April 2004.
[I-D.josefsson-pppext-eap-tls-eap] [I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D. and G. Zorn, Josefsson, S., Palekar, A., Simon, D. and G. Zorn,
"Protected EAP Protocol (PEAP)", "Protected EAP Protocol (PEAP)",
draft-josefsson-pppext-eap-tls-eap-07 (work in progress), draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
October 2003. October 2003.
[I-D.ietf-pppext-eap-ttls] [I-D.ietf-pppext-eap-ttls]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", Authentication Protocol (EAP-TTLS)",
draft-ietf-pppext-eap-ttls-04 (work in progress), April draft-ietf-pppext-eap-ttls-04 (work in progress), April
  Skipping to change at page 41, line 27:
(authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK (authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK
needed for authenticated DHCP is distributed from the PAA to the needed for authenticated DHCP is distributed from the PAA to the
POPA DHCPv4 server by using the method specified in POPA DHCPv4 server by using the method specified in
[I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using
DHCPv4 and may be assigned with a short lease period in order to DHCPv4 and may be assigned with a short lease period in order to
provide some level of robustness against IP address depletion provide some level of robustness against IP address depletion
attack. The IPsec-TIA is bound to an IPsec SA by using specifying attack. The IPsec-TIA is bound to an IPsec SA by using specifying
the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2 the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2
CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec]. CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec].
Once the IPsec-TIA is obtained, the PANA re-authentication based Once the IPsec-TIA is obtained, the PANA re-authentication based
on PRAR (PANA Re-Authentication Request) and PRAA (PANA on PUR (PANA-Update-Rquest) and PUA (PANA-Update-Answer) exchange
Re-Authentication Answer) exchange is performed with using the is performed with using the obtained IPsec-TIA in order to inform
obtained IPsec-TIA in order to inform PAA of the update of PaC-DI. PAA of the update of PaC-DI. The IKE procedure should occur after
The IKE procedure should occur after the PRAR-PRAA exchange the PUR-PUA exchange procedure. The PaC unconfigures the PRPA
procedure. The PaC unconfigures the PRPA immediately after the immediately after the IPsec-TIA is obtained.
IPsec-TIA is obtained.
PRPA PRPA
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv4 | | | | DHCPv4 | | |
|<-----------+--------->| | | |<-----------+--------->| | |
| | | | | | | | | |
  Skipping to change at page 42, line 33:
| | | Session-Id] | Session-Id] | | | | Session-Id] | Session-Id] |
| | |<------------|------------>| | | |<------------|------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| Authenticated DHCPv4 | | | | Authenticated DHCPv4 | | |
| (RFC3118) | | | | (RFC3118) | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | | | | | | | |
| PANA(PRAR-PRAA exchange using POPA as PaC-DI) | | PANA(PUR-PUA exchange using POPA as PaC-DI) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 17: An example case for IPsec-TIA obtained by using RFC3118 Figure 15: An example case for IPsec-TIA obtained by using RFC3118
Appendix A.2 IPv6 Appendix A.2 IPv6
Case A: IPsec-TIA obtained by using DHCPv6 Case A: IPsec-TIA obtained by using DHCPv6
This case is similar to Case A in IPv4, except that a link-local This case is similar to Case A in IPv4, except that a link-local
address is used as the PRPA and IPsec-TOA, and that the DHCPv6 address is used as the PRPA and IPsec-TOA, and that the DHCPv6
procedure can occur at any time after link-layer association and procedure can occur at any time after link-layer association and
before IKE. before IKE.
  Skipping to change at page 43, line 35:
| | | |------------>| | | | |------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 18: An example case for IPsec-TIA obtained by using DHCPv6 Figure 16: An example case for IPsec-TIA obtained by using DHCPv6
Case B: IPsec-TIA obtained by using IPv6 stateless address Case B: IPsec-TIA obtained by using IPv6 stateless address
autoconfiguration autoconfiguration
In this case, the IPsec-TOA (link-local address) and IPsec-TIA In this case, the IPsec-TOA (link-local address) and IPsec-TIA
(global address) are configured through IPv6 stateless address (global address) are configured through IPv6 stateless address
autoconfiguration before running IKE. Other configuration autoconfiguration before running IKE. Other configuration
information can be obtained by using several methods including information can be obtained by using several methods including
authenticated DHCPv6, Configuration Payload exchange and DHCPv6 authenticated DHCPv6, Configuration Payload exchange and DHCPv6
over IPsec SA. over IPsec SA.
  Skipping to change at page 44, line 32:
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| IPv6 stateless address autoconfiguration | | IPv6 stateless address autoconfiguration |
| (can occur at any time before Association and IKEv2) | | (can occur at any time before Association and IKEv2) |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
| | IKEv2 | | | | IKEv2 | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
Figure 19: An example sequence for IPsec-TIA obtained by using Figure 17: An example sequence for IPsec-TIA obtained by using
IPv6 stateless address autoconfiguration IPv6 stateless address autoconfiguration
Case C: IPsec-TIA obtained by using authenticated DHCPv6 Case C: IPsec-TIA obtained by using authenticated DHCPv6
This case is similar to Case C of IPv4, except that a link-local This case is similar to Case C of IPv4, except that a link-local
address is used as the PRPA, and that there is no need for address is used as the PRPA, and that there is no need for
additional PRAR-PRAA exchange to update the PaC-DI. additional PUR-PUA exchange to update the PaC-DI.
PaC AP DHCPv6 Server PAA EP(AR) PaC AP DHCPv6 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| | | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) | | & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
  Skipping to change at page 45, line 26:
| | |[DHCP-PSK, |[IKE-PSK, | | | |[DHCP-PSK, |[IKE-PSK, |
| | | Session-Id] | PaC-DI, | | | | Session-Id] | PaC-DI, |
| | | | Session-Id] | | | | | Session-Id] |
| | |<------------|------------>| | | |<------------|------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| Authenticated DHCPv6 | | | | Authenticated DHCPv6 | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | | |
| PANA(PRAR-PRAA exchange using POPA as PaC-DI)
|<-----------+-------------------------->| |
| | | |Authorization| | | | |Authorization|
| | | | [IKE-PSK, | | | | | [IKE-PSK, |
| | | | PaC-DI, | | | | | PaC-DI, |
| | | | Session-Id]| | | | | Session-Id]|
| | | |------------>| | | | |------------>|
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 20: An example case for configuring IPsec-TIA by using Figure 18: An example case for configuring IPsec-TIA by using
authenticated DHCPv6 authenticated DHCPv6
Intellectual Property Statement Intellectual Property Statement
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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any 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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
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.