draft-ohba-pana-framework-00.txt draft-ietf-pana-framework-00.txt
PANA Working Group P. Jayaraman PANA Working Group P. Jayaraman
Internet-Draft N.E.T. Internet-Draft Net.Com
Expires: August 5, 2004 R. Lopez Expires: November 1, 2004 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
DoCoMo USA Labs Samsung
February 5, 2004 May 3, 2004
PANA Framework PANA Framework
draft-ohba-pana-framework-00 draft-ietf-pana-framework-00
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
  Skipping to change at page 1, line 38:
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 http://
www.ietf.org/ietf/1id-abstracts.txt. 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 August 5, 2004. This Internet-Draft will expire on November 1, 2004.
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. Access
networks can differ based on the availability of lower-layer 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
  Skipping to change at page 2, line 16:
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 . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. General PANA Framework . . . . . . . . . . . . . . . . . . 5 3. General PANA Framework . . . . . . . . . . . . . . . . . . 5
4. Environments . . . . . . . . . . . . . . . . . . . . . . . 9 4. Environments . . . . . . . . . . . . . . . . . . . . . . . 9
5. IP Address Configuration . . . . . . . . . . . . . . . . . 11 5. IP Address Configuration . . . . . . . . . . . . . . . . . 11
6. Data Traffic Protection . . . . . . . . . . . . . . . . . 13 6. Data Traffic Protection . . . . . . . . . . . . . . . . . 14
7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . 14 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . 15
7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 14 7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 15
7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . . . 14 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . . . 16
7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . . . 15 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . . . 16
7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 17 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 18
7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 17 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 18
8. Network Selection . . . . . . . . . . . . . . . . . . . . 18 8. Network Selection . . . . . . . . . . . . . . . . . . . . 19
9. Authentication Method Choice . . . . . . . . . . . . . . . 20 9. Authentication Method Choice . . . . . . . . . . . . . . . 21
10. Example Cases . . . . . . . . . . . . . . . . . . . . . . 21 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . 22
10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . . 21 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . . 22
10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . . . . 21 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . . . . 22
10.1.2 Address Translation (NAPT) Mode . . . . . . . . . . . . . 22 10.1.2 Address Translation (NAPT) Mode . . . . . . . . . . . . . 23
10.1.3 Router Mode . . . . . . . . . . . . . . . . . . . . . . . 22 10.1.3 Router Mode . . . . . . . . . . . . . . . . . . . . . . . 23
10.1.4 PANA and Dynamic Internet Service Provider Selection . . . 23 10.1.4 PANA and Dynamic Internet Service Provider Selection . . . 24
10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . . 24 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . . 25
10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . . . . 25 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . . . . 26
10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . . . . 31 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . . . . 30
10.2.3 Capability Discovery . . . . . . . . . . . . . . . . . . . 35 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . . . . 34
11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . 38 Normative References . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . 40 Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40
A. Other Possible Cases for PANA with Bootstrapping IPsec A. Other Possible Cases for PANA with Bootstrapping IPsec
in Wireless LAN . . . . . . . . . . . . . . . . . . . . . 42 in Wireless LAN . . . . . . . . . . . . . . . . . . . . . 41
A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . 46
1. Introduction 1. Introduction
PANA design provides support for various types of deployments. Access PANA design provides support for various types of deployments. Access
networks can differ based on the availability of lower-layer 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
  Skipping to change at page 4, line 20:
exchange. exchange.
Post-PANA address (POPA) Post-PANA address (POPA)
This is the address (optionally) configured after a successful This is the address (optionally) configured after a successful
authentication. 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 the address used as the inner address of an IPsec tunnel
mode SA. When IPsec protection is used, POPA becomes the mode SA. When IPsec protection is used, depending on the
deployment scenario used either a PRPA or POPA becomes the
IPsec-TIA. 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 used as the outer address of an IPsec tunnel
mode SA. When IPsec protection is used, either one of the PRPA or mode SA. When IPsec protection is used, a PRPA becomes the
POPA becomes IPsec-TOA depending on the deployment scenario. IPsec-TOA.
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 client hosts in access networks. PANA is an EAP
[I-D.ietf-eap-rfc2284bis] lower-layer that carries EAP authentication [I-D.ietf-eap-rfc2284bis] lower-layer that carries EAP authentication
methods encapsulated inside EAP between a client host and an agent in methods encapsulated inside EAP between a client host and an agent in
the access network. While PANA enables the authentication process the 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
  Skipping to change at page 5, line 47:
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.yacine-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 any
IP-enabled node on the same IP subnet as the PaC. For example on IP-enabled node on the same IP subnet as the PaC. For example on
a BAS (broadband access server) in DSL networks, or PDSN in 3GPP2 a BAS (broadband access server) in DSL networks, or PDSN in 3GPP2
networks. networks.
Authentication Server (AS): Authentication Server (AS):
  Skipping to change at page 7, line 40:
networks that are already cryptographically secured on the link-layer networks that are already cryptographically secured on the link-layer
prior to PANA run (e.g., cdma2000) do not require additional secure prior to PANA run (e.g., cdma2000) do not require additional secure
association and per-packet ciphering. These networks can bind the association and per-packet ciphering. These networks can bind the
PANA authentication and authorization to the lower-layer secure PANA authentication and authorization to the lower-layer secure
channel that is already available. channel that is already available.
Figure 2 illustrates the signaling flow for authorizing a client for Figure 2 illustrates the signaling flow for authorizing a client for
network access. network access.
PaC EP PAA AS PaC EP PAA AS
| PANA | | AAA |
|<------------------------------>|<-------------->|
| | | | | | | |
IP address o | | |
config. | PANA | | AAA |
|<------------------------------>|<-------------->|
| | SNMP | | | | SNMP | |
| |<-------------->| | (Optional) | |<-------------->| |
| Sec.Assoc. | | | IP address o | | |
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
successful PANA authentication, depending on the deployment scenario
PaC MAY need to re-configure its IP address or configure additional
IP address(es). The additional address configuration MAY 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 interfaces 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
  Skipping to change at page 11, line 8:
IP-layer one (b.2) is a deployment decision. This decision also IP-layer one (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
technology specific. If IP-layer protection is used, the secure technology specific. If IP-layer protection is used, the secure
association protocol would be IKE and the per-packet security association protocol would be IKE and the per-packet security
would be provided by IPsec regardless of the link type. would be provided by IPsec regardless of the link type.
5. IP Address Configuration 5. IP Address Configuration
PaC configures an IP address before the PANA protocol exchange PaC configures an IP address before the PANA protocol exchange
begins. This address is called as the Pre-PANA address. After a begins. This address is called a pre-PANA address (PRPA). After a
successful authentication, the client may have to configure POPA for successful authentication, the client may have to configure a
communication with other nodes, if PRPA is a link-local or private post-PANA address (POPA) for communication with other nodes, if PRPA
address. An operator might choose allocating a POPA address only is a local-use (e.g., link-local or private address) or a temporarily
after successful PANA authorization either to prevent waste of allocated IP address. An operator might choose allocating a POPA
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.
There are many ways by which PRPA can be configured. In case PaC is a IPv4-IPv6 dual-stack host, it may configure more
than one PRPA, at least one for each protocol. Nevertheless, the PaC
needs only one to run PANA which is executed once regardless of the
type and number of IP stacks. After successful PANA authentication,
similarly PaC may configure multiple POPAs.
1. In some deployments e.g., DSL networks, the PaC may be statically There are different methods by which a PRPA can be configured.
1. In some deployments (e.g., DSL networks) the PaC may be statically
configured with an IP address. This address SHOULD be used as configured with an IP address. This address SHOULD be used as
PRPA. 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 configure a link-local address using using DHCP, they can configure a link-local address using
[I-D.ietf-zeroconf-ipv4-linklocal]. This gives way to two [I-D.ietf-zeroconf-ipv4-linklocal].
possibilities. Network access provider may be able to run a DHCP
server to provide private addresses as defined in [RFC1918] or
may be able to provide non-private addresses. In this case, the
client would configure the address using DHCP as it attempts DHCP
first. If the network access provider cannot run DHCP server to
provide PRPA, the client SHOULD configure a link-local address.
3. In IPv6, all the clients configure a link-local address [RFC2462] When the network access provider is able to run a DHCP server on
when they initialize an interface. This address SHOULD be used as the access link, the client would configure the PRPA using DHCP.
PRPA. The network may also send out router advertisements for This address may be from a private address pool [RFC1918]. Also,
the client to auto-configure [RFC2461] a global address. This the lease time on the address may vary. For example, a PRPA
address also MAY be used as PRPA. configured solely for running PANA can have a short lease time.
PRPA may be used for local-use only (i.e., only for on-link
communication, such as for PANA and IPsec tunneling with EP), or
also for ultimate data communication.
When PRPA is configured, the client starts the PANA protocol In case there is no running DHCP server on the link, the client
exchange. When it successfully authenticates to the network, it may would fall back to configuring a PRPA via zeroconfiguration
configure a Post-PANA address for its subsequent communication with technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a
the other nodes. long-term address that can only be used for on-link communication.
If the client is already configured with a global address (non- 3. In IPv6, clients configure a link-local address [RFC2462] when
private and non-link-local), then it can continue to use that for all they initialize an interface. This address SHOULD be used as
other communications. If PRPA is configured with a private address PRPA.
or link-local address, PAA would indicate PaC to configure an
appropriate POPA through the PANA-Bind-Request message. There are When a PRPA is configured, the client starts the PANA protocol
many ways by which POPA can be configured. exchange. By that time, a dual-stack client might have configured
both an IPv4 address, and one or more IPv6 addresses as PRPAs. When
the client successfully authenticates to the network, it may be
required to configure POPAs for its subsequent data communication
with the other nodes.
If the client is already configured with a non-temporary address that
can be used with data communication, it is not required to configure
a POPA. Otherwise, PAA would indicate PaC the available POPA
configuration methods through the PANA-Bind-Request message. PaC can
choose one of the methods and execute 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, PaC can
configure a global address using DHCP [RFC2131][RFC3315] or using configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6
IPv6 stateless auto-configuration [RFC2461]. If IPv4 is being stateless auto-configuration [RFC2461]. If IPv4 is being used,
used, PRPA SHOULD be unconfigured when the global address is PRPA is likely to be a link-local or private address, or an
configured to prevent using the private address or the link-local address with a short DHCP lease. An IPv4 PRPA SHOULD be
address as the source address for communicating with external unconfigured when the POPA is configured to prevent IPv4 address
nodes. If IPv6 is used, the link-local address may continue to selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is
be used as specified in [RFC3484]. used, the link-local PRPA address SHOULD NOT be unconfigured
[RFC3484].
If the PaC is a dual-stack host, it can configure both IPv4 and
IPv6 type POPAs.
PRPA and the IP address of PAA are assumed to be on the same IP PRPA and the IP address of PAA are assumed to be on the same IP
subnet, hence the PaC and PAA can perform on-link communication subnet, hence the PaC and PAA can perform on-link communication as
as required by PANA. When the PaC changes its IP address from required by PANA. When the PaC replaces its IPv4 PRPA with POPA,
PRPA to POPA, this assumption may not hold true. In order to this assumption may not hold true. In order to maintain the same
maintain the same on-link communication, the PaC and PAA SHOULD on-link communication, the PaC and PAA SHOULD create host routes
create host routes to each other upon PaC's IP address change. to each other upon PaC's IP address change. The PaC SHOULD create
The PaC SHOULD create a host route to the PAA, and the PAA SHOULD a host route to the PAA, and the PAA SHOULD create a host route to
create a host route to the PaC (POPA). the PaC (POPA).
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, PaC may use the address subsequent to PANA authentication [I-D.ietf-pana-ipsec], PaC would
configuration methods available within [RFC2409] or use the PRPA as the outer address of IPsec tunnel mode SA
[I-D.ietf-ipsec-ikev2] or it may also use the mechanism described (IPsec-TOA). PaC also needs to configure an inner address
in [RFC3456]. If IPv4 is being used, PRPA SHOULD be (IPsec-TIA). There are different ways to configure IPsec-TIA
unconfigured, when the global address is configured to prevent which are indicated in Pana-Bind-Request message.
using the private address or the link-local address as the source
address for communicating with the external nodes. All packets When an IPv4 PRPA is configured, the same address may be used as
are tunneled using IPsec tunnel mode SA [I-D.ietf-pana-ipsec] both IPsec-TOA and IPsec-TIA. In this case, a POPA is not
with the inner and outer source addresses same as the address configured. Alternatively, an IPsec-TIA can be obtained via the
configured using IKE or [RFC3456]. In the case of IPv6, PRPA is configuration method available within [RFC3456] for IPv4, and
used for the outer header and POPA is used for the inner header. [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly
Please refer to [I-D.ietf-pana-ipsec] for more details. PaC also configured address constitutes a POPA. Please refer to
needs to update the device identifier to be the same as POPA by [I-D.ietf-pana-ipsec] for more details.
initiating a PANA-Reauth-Request/Answer exchange, if IPsec based
access control is being used and PRPA is used as the IPsec-TOA. IKEv2 can enable configuration of both IPv4 and IPv6 TIAs for the
same IPsec tunnel mode SA. Therefore, IKEv2 is recommended for
handling dual-stack PaCs where single execution of PANA and IKE is
desired.
Although there are potentially a number of different ways to
configure a PRPA, and POPA when necessary, it should be noted that
the ultimate decision to use one or more of these in a deployment
depends on the operator. The decision is dictated by the operator's
choice of per-packet protection capability (physical and link-layer
vs network-layer), PRPA type (local and temporary vs global and
long-term), and POPA configuration mechanisms available in the
network.
6. Data Traffic Protection 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 are 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.
  Skipping to change at page 14, line 16:
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 identifying legitimate clients and
generating filtering information for access control mechanisms. 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 PANA traffic. traffic from and to any unauthorized client unless it's either PANA
or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
discovery, DHCP, etc.).
When a client is authenticated and authorized, PAA should notify When a client is authenticated and authorized, PAA should notify
EP(s) and ask for changing filtering rules to allow traffic for a EP(s) and ask for changing filtering rules to allow traffic for a
recently authorized client. There needs to be a protocol between PAA recently authorized client. There needs to be a protocol between PAA
and EP(s) when these entities are not co-located. PANA Working Group and EP(s) when these entities are not co-located. PANA Working Group
will not be defining a new protocol for this interaction. Instead, it will not be defining a new protocol for this interaction. Instead,
identifies one of the existing protocols that can fit the it identifies one of the existing protocols that can fit the
requirements. An assessment was made in the PANA Working Group and requirements. An assessment was made in the PANA Working Group and
SNMPv3 has been chosen as the mandatory PAA-EP protocol. 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.yacine-pana-snmp] for further discussion. [I-D.ietf-pana-snmp] for further discussion.
7.1 PAA and EP Locations 7.1 PAA and EP Locations
EPs' location in the network topology should be appropriate for EPs' location in the network topology should be appropriate for
performing access control functionality. The closest IP-capable performing access control functionality. The closest IP-capable
access device to the client devices is the logical choice. PAA and access device to the client devices is the logical choice. PAA and
EPs on an access network should be aware of each other as this is EPs on an access network should be aware of each other as this is
necessary for access control. Generally this can be achieved by necessary for access control. Generally this can be achieved by
manual configuration. Dynamic discovery is another possibility, but manual configuration. Dynamic discovery is another possibility, but
this is left to implementations and outside the scope of this this is left to implementations and outside the scope of this
  Skipping to change at page 16, line 24:
Figure 4: PAA and EP in Parallel Figure 4: PAA and EP in Parallel
In the remaining of this section, PaC is not shown in figures and the In the remaining of this section, PaC is not shown in figures and the
figures cover both the serial and parallel models. figures cover both the serial and parallel models.
7.1.2.1 Single PAA, Single EP, Separated 7.1.2.1 Single PAA, Single EP, Separated
The model benefits from separation of data traffic handling and AAA. The model benefits from separation of data traffic handling and AAA.
The EP does not need to have a AAA protocol implementation which The EP does not need to have a AAA protocol implementation which
might updated relatively more frequently than the per-packet access might be updated relatively more frequently than the per-packet
enforcement implementation. access enforcement implementation.
7.1.2.2 Single PAA, Multiple EPs 7.1.2.2 Single PAA, Multiple EPs
In this model, a single PAA controls multiple EPs. The PAA may be In this model, a single PAA controls multiple EPs. The PAA may be
separated from any EP or co-located with a particular EP. This model separated from any EP or co-located with a particular EP. This model
might be useful where it is preferable to run a AAA protocol at a might be useful where it is preferable to run a AAA protocol at a
single, manageable point. This model is particularly useful in an single, manageable point. This model is particularly useful in an
access network that consists of a large number of access points on access network that consists of a large number of access points on
which per-packet access enforcement is made. When a PaC is which per-packet access enforcement is made. When a PaC is
authenticated to the PAA, the PAA should install access control authenticated to the PAA, the PAA should install access control
  Skipping to change at page 17, line 32:
and to be visible to PaCs on the link. PAAs may or may not be and to be visible to PaCs on the link. PAAs may or may not be
co-located with EPs as long as authorization results do not depend on co-located with EPs as long as authorization results do not depend on
whichever PAAs are chosen by a PaC [I-D.ietf-pana-pana]. whichever PAAs are chosen by a PaC [I-D.ietf-pana-pana].
7.2 Notification of PaC Presence 7.2 Notification of PaC Presence
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 either in a PAA-EP protocol message presence notification is carried in a PAA-EP protocol message
[I-D.yacine-pana-snmp] or in a PANA-PAA-Discover message generated by [I-D.ietf-pana-snmp].
EP on behalf of PaC [I-D.ietf-pana-pana].
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 (such as
keys, key pairs, and initialization values) when needed. The keying keys, key pairs, and initialization values) when needed. The keying
material is needed when attackers can eavesdrop and spoof on the material is needed when attackers can eavesdrop and spoof on the
device identifiers easily. Each keying material is uniquely device identifiers easily. Each keying material is uniquely
identified with a keying material name and has a lifetime for key identified with a keying material name and has a lifetime for key
management purpose. The keying material is used with link-layer or management purpose. The keying material is used with link-layer or
  Skipping to change at page 18, line 12:
as the IP filter rules specified in NAS-Filter-Rule AVPs carried in 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. 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, AAA routing is performed on the chosen ISP and based on the exchange, the ultimate destination of the AAA exchange is determined
PaC's identity used in EAP. It is also possible that the PaC does based on the identity of the chosen service provider. It is also
not choose a specific ISP in the PANA protocol exchange. In this possible that the PaC does not choose a specific ISP in the PANA
case, both ISP choice and AAA routing are made based on the PaC's protocol exchange. In this case, both the ISP choice and the AAA
identity, where the identity may be an NAI [RFC2486] or the physical destination are determined based on the PaC's identity, where the
port number or L2 address of the subscriber. identity may be an NAI [RFC2486] or the physical port number or L2
address of the subscriber.
As described in [I-D.ietf-eap-netsel-problem], network selection is As described in [I-D.ietf-eap-netsel-problem], network selection is
not only related to AAA routing but also related to payload routing. not only related to AAA routing but also related to payload routing.
Once an ISP is chosen and the PaC is successfully authenticated and Once an ISP is chosen and the PaC is successfully authenticated and
authorized, PaC is assigned an address by the ISP whose IP prefix may authorized, PaC is assigned an address by the ISP whose IP prefix may
be different from that of the AR. This affects the routing of the be different from that of the AR. This affects the routing of the
subsequent data traffic between AR and PaC. A suggested solution is subsequent data traffic between AR and PaC. A suggested solution is
to add host route from AR to PaC's POPA address and host route from to add host route from AR to PaC's POPA address and host route from
PaC to AR. PaC to AR.
In this section, it is assumed that an AR is in the access network of Consider a typical DSL network where the AR, EP, and PAA are
a NAP (Network Access Provider). It is also assumed that EP is co-located on a BAS (Broadband Access Server) in the access network
co-located with the AR. In DSL, the AR is typically co-located with operated by a NAP (Network Access Provider). Figure 6 shows a
BAS (Broadband Access Server). PAA may or may not be co-located with typical model for ISP selection.
EP. Figure 6 shows a typical model for ISP selection.
<---- NAP ----><--------- ISP ---------> <---- NAP ----><--------- ISP --------->
+---ISP1 +---ISP1
/ /
+---+ +---------+/ +---+ +---------+/
|PaC|----|AR/EP/PAA| |PaC|----|AR/EP/PAA|
+---+ +---------+\ +---+ +---------+\
\ BAS \
+---ISP2 +---ISP2
Figure 6: A Network Selection Model Figure 6: A Network Selection Model
When network selection is made at L3 with the use of the PANA When network selection is made at L3 with the use of the PANA
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 pre-PANA address is prior to network selection). In this model, the PRPA is either given
either given by NAP or a link-local address is auto-configured. by NAP or a link-local address is auto-configured. After the
After the successful authentication with the ISP, PaC may acquire an successful authentication with the ISP, PaC may acquire an address
address (POPA) from the ISP. It also learns the address of the AR, (POPA) from the ISP. It also learns the address of the AR, e.g.,
e.g., through DHCP, to be used as its default router. The address of through DHCP, to be used as its default router. The address of the
the AR may or may not be in the same IP subnet as that of the PaC's AR may or may not be in the same IP subnet as that of the PaC's POPA.
POPA. If they don't share the same prefix, they SHOULD use host If they don't share the same prefix, they SHOULD use host routes to
routes to reach each other. Note that the physically secured DSL reach each other. Note that the physically secured DSL networks do
networks do not require IPsec-based access control. Therefore the not require IPsec-based access control. Therefore the PaCs use one IP
PaCs use one IP address at a time where POPA replaces PRPA upon address at a time where POPA replaces PRPA upon configuration.
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
  Skipping to change at page 23, line 5:
before gaining access to the service provider's network. before gaining access to the service provider's network.
10.1.3 Router Mode 10.1.3 Router Mode
In this case, the CPE acts as a full-fledged router for the customer In this case, the CPE acts as a full-fledged router for the customer
premises network. The CPE itself may obtain the IP address using premises network. The CPE itself may obtain the IP address using
DHCP or be configured with static IP address. Once the CPE is DHCP or be configured with static IP address. Once the CPE is
authenticated using PANA and is provided access to the service authenticated using PANA and is provided access to the service
provider's network, the NAS should begin exchanging routing updates provider's network, the NAS should begin exchanging routing updates
with the CPE. All devices at the customer premises will then have with the CPE. All devices at the customer premises will then have
access the service provider's network. access to the service 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 10: Router Mode
As in the NAPT mode, it is possible that both ends of the DSL link As in the NAPT mode, it is possible that both ends of the DSL link
are configured with static IP addresses. PANA-based mutual are configured with static IP addresses. PANA-based mutual
authentication of CPE and NAS may be desirable before data-traffic is authentication of CPE and NAS is desirable before data-traffic is
exchanged between the customer premises network and the service exchanged between the customer premises network and the service
provider network. provider network.
10.1.4 PANA and Dynamic Internet Service Provider Selection 10.1.4 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 IP
address space. address space.
The devices at the customer premises network indicate their choice of The devices at the customer premises network indicate their choice of
  Skipping to change at page 24, line 16:
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.4.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 zeroconf technique. In either complete PANA authentication, or via the zeroconf technique
case, the client attempts a new (long term) IP address configuration [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA
via DHCP upon successful PANA authentication. This new IP address authentication signalling prompts the client to obtain a new (long
(POPA) replaces the previously allocated temporary IP address. term) IP address via DHCP. This new IP address (POPA) replaces the
previously allocated temporary IP address.
10.2 Wireless LAN Example 10.2 Wireless LAN Example
This section describes how PANA can be used on WLAN networks. In This section describes how PANA can be used on WLAN networks. In
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
  Skipping to change at page 25, line 24:
|AP/EP|----+ |AP/EP|----+
+-----+ +-----+
Figure 11: PANA Wireless LAN Model Figure 11: 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
Pre-PANA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA
PAA and EP may be co-located in a single device. EP is always and EP may be co-located in a single device. EP is always co-located
co-located with AR and may be co-located with PAA. When EP and PAA with AR and may be co-located with PAA. When EP and PAA are not
are not co-located, PAA-EP protocol is used for communication between co-located, PAA-EP protocol is used for communication between PAA and
PAA and EP. EP.
Note that for all of the cases described in this section, PBR Note that for all of the cases described in this section, PBR
(PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA
[I-D.ietf-pana-pana] should occur after installing the authorization [I-D.ietf-pana-pana] should occur after installing the authorization
parameter to AR, so that IKE can be performed immediately after PANA parameter to AR, so that IKE can be performed immediately after PANA
is successfully completed. is successfully completed.
10.2.1.1 IPv4 10.2.1.1 IPv4
Case A: IPsec-TIA obtained by using DHCPv4 Case A: IPsec-TIA obtained by using DHCPv4
In this case, the IPsec-TIA and IPsec-TOA are the same as the In this case, the IPsec-TIA and IPsec-TOA are the same as the
pre-PANA address, and all configuration information including the PRPA, and all configuration information including the IP address
IP address is obtained by using DHCPv4 [RFC2131]. No post-PANA is obtained by using DHCPv4 [RFC2131]. No POPA is configured.
address is configured. Case A is the simplest compared to other Case A is the simplest compared to other ones and might be used in
ones and might be used in a network where IP address depletion a network where IP address depletion attack on DHCP is not a
attack on DHCP is not a significant concern. The pre-PANA address significant concern. The PRPA needs to be a routable address
needs to be a routable address unless NAT is performed on AR. unless NAT is performed on AR.
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| 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 26, line 31:
| | | |------------>| | | | |------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 12: An example case for IPsec-TIA obtained by using DHCPv4 Figure 12: An example case for configuring IPsec-TIA by using
DHCPv4
Case B: IPsec-TIA obtained by using IKE Case B: IPsec-TIA obtained by using IKE
In this case, the pre-PANA address is obtained by using DHCPv4 and In this case, the PRPA is obtained by using DHCPv4 and used as
used as IPsec-TOA. The post-PANA address is obtained by using IKE IPsec-TOA. The POPA is obtained by using IKE (via a Configuration
(via a Configuration Payload exchange or equivalent) and used as Payload exchange or equivalent) and used as IPsec-TIA.
IPsec-TIA.
Case C: IPsec-TIA obtained by using RFC3456 Case C: IPsec-TIA obtained by using RFC3456
Like Case B, the pre-PANA address is obtained by using DHCPv4. Like Case B, the PRPA is obtained by using DHCPv4. The difference
The difference is that the post-PANA address (eventually used as is that the POPA (eventually used as IPsec-TIA) and other
both IPsec-TOA and IPsec-TIA) and other configuration parameter configuration parameter are configured by running DHCPv4 over a
are configured by running DHCPv4 over a special IPsec tunnel mode special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4
SA [RFC3456]. As soon as the post-PANA address is obtained, the Server and IPsec-TIA DHCPv4 Server may be co-located on the same
PaC unconfigures the pre-PANA address. Note that the pre-PANA node.
DHCPv4 server and IPsec-TIA DHCPv4 server may be co-located on the
same node.
Note: this case may be used only when IKEv1 is used as the IPsec Note: this case may be used only when IKEv1 is used as the IPsec
key management protocol (IKEv2 does not seem to support RFC3456 key management protocol (IKEv2 does not seem to support RFC3456
equivalent case). equivalent case).
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
  Skipping to change at page 28, line 4:
|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 13: An example case for IPsec-TIA obtained by using IKE
Pre-PANA IPsec-TIA PRPA
PaC AP DHCPv4 Server PAA DHCPv4 Server PaC AP DHCPv4 Server PAA
| Link-layer | | | | | Link-layer | | |
| association| | | | | association| | |
|<---------->| | | | |<---------->| | |
| | | | |
| DHCPv4 | | |
|<-----------+------------>| | |
| | | |
|PANA(Discovery and initial handshake phase |
| & PAR-PAN exchange in authentication phase) |
|<-----------+-------------------------->| |
| | | |
| | EP(AR) | |
| | |Authorization| |
| | |[IKE-PSK, | |
| | | PaC-DI, | |
| | | Session-Id] | |
| | |<------------| |
| | | | |
|PANA(PBR-PBA exchange in authentication phase) |
|<-----------+-------------------------->| |
| | | |
| IKEv1 phase I & II | |
| (to create DHCP SA) | |
|<-----------+------------>| |
| | | | | | | |
| DHCP over DHCP SA | DHCP | | DHCPv4 | |
|<-----------+------------>+<------------------------->| |<-----------+-------->| |
| | |
|PANA(Discovery and initial handshake phase
| & PAR-PAN exchange in authentication phase)
|<-----------+-------------------------->|
| | |
| | EP(AR) |
| | |Authorization|
| | |[IKE-PSK, |
| | | PaC-DI, |
| | | Session-Id] |
| | |<------------|
| | | | | | | |
|PANA(PBR-PBA exchange in authentication phase)
|<-----------+-------------------------->|
| | |
| IKEv1 phase I & II |
| (to create 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 IPsec-TIA obtained by using RFC3456 Figure 14: An example case for configuring IPsec-TIA by using
RFC3456
10.2.1.2 IPv6 10.2.1.2 IPv6
Case A: IPsec-TIA obtained by using DHCPv6 In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local
address. IPsec-TIA (POPA) is obtained by using Configuration Payload
This case is similar to Case A in IPv4, except that a link-local exchange of IKE version 2 (Note that there is no standard method for
address is used as the pre-PANA address and IPsec-TOA, and that configuring IPsec-TIA in IKEv1). Other configuration information may
the DHCPv6 procedure can occur at any time after link-layer be obtained in the same Configuration Payload exchange or may be
association and before IKE. obtained by running an additional DHCPv6.
PaC AP DHCPv6 Server PAA EP(AR)
| Link-layer | | | |
| association| | | |
|<---------->| | | |
| | | | |
| DHCPv6 | | |
|<-----------+------------>| | |
| | | | |
|PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | | |
| | | |Authorization|
| | | |[IKE-PSK, |
| | | | PaC-DI, |
| | | | Session-Id] |
| | | |------------>|
| | | | |
|PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | | |
| | IKE | |
|<-----------+---------------------------------------->|
| | | | |
| | | | |
Figure 15: An example case for IPsec-TIA obtained by using DHCPv6
Case B: IPsec-TIA obtained by using IPv6 stateless address
autoconfiguration
In this case, the IPsec-TOA (link-local address) and IPsec-TIA
(global address) are configured through IPv6 stateless address
autoconfiguration before running IKE. Other configuration
information can be obtained by using several methods including
authenticated DHCPv6, Configuration Payload exchange and DHCPv6
over IPsec SA.
Case C: IPsec-TIA obtained by using IKEv2
In this case, the IPsec-TOA (pre-PANA address) is the IPv6
link-local address. IPsec-TIA (post-PANA address) is obtained by
using Configuration Payload exchange of IKEv2. Other
configuration information may be obtained in the same
Configuration Payload exchange or may be obtained by running an
additional DHCPv6.
PaC AP PAA EP(AR) PaC AP EP(AR) PAA
| Link-layer | | | | Link-layer | | |
| association| | | | association| | |
|<---------->| | | | |<---------->| | |
| | | |
| | | |
|PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | |
| | |Authorization|
| | |[IKE-PSK, |
| | | PaC-DI, |
| | | Session-Id] |
| | |------------>|
| | | |
|PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | |
| IPv6 stateless address autoconfiguration |
| (can occur at any time before Association and IKEv2) |
|<-----------+---------------------------------------->|
| | | | | | | |
| | IKEv2 | |
|<-----------+---------------------------------------->|
| | | | | | | |
Figure 16: An example sequence for IPsec-TIA obtained by using
IPv6 stateless address autoconfiguration
PaC AP PAA
| Link-layer | |
| 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)
|<-----------+-------------------------->| |<-----------+-------------------------->|
| | | | | | |
| | EP(AR) | | | | |
| | |Authorization| | | |Authorization|
| | |[IKE-PSK, | | | |[IKE-PSK, |
| | | PaC-DI, | | | | PaC-DI, |
| | | Session-Id] | | | | Session-Id] |
| | |<------------| | | |<------------|
| | | | | | | |
|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 17: An example sequence for IPsec-TIA obtained by using Figure 15: An example sequence for configuring IPsec-TIA in IPv6
IKEv2
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
  Skipping to change at page 32, line 37:
number of APs in a single IP subnet and the network administrator 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 want to avoid setting up RADIUS client on each AP. Note that the
network administrator would still need to set up SNMPv3 security network administrator would still need to set up SNMPv3 security
association between each AP and PAA for secure PAA-EP communication, association between each AP and PAA for secure PAA-EP communication,
however, in the environments where operator can rely on physical however, in the environments where operator can rely on physical
layer security between PAA and EP, this might not be the case. 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 In a typical usage scenario, a single PAA co-located with DHCP server
is connected to both unauthenticated VLAN and authenticated VLAN and is connected to both unauthenticated VLAN and authenticated VLAN and
that the unauthenticated VLAN AP and the authenticated VLAN AP are that the unauthenticated VLAN AP and the authenticated VLAN AP are
co-located in a single physical AP, as shown in Figure 18. Note that 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 in an environment where virtual AP are not supported, physical APs
can be used instead of virtual APs. can be used instead of virtual APs.
+------------------+ +------------------+
| Physical AP | | Physical AP |
| +--------------+ | | +--------------+ |
| |Virtual AP1 | | Unauthenticated | |Virtual AP1 | | Unauthenticated
| |(open-access) |---- VLAN \ | |(open-access) |---- VLAN \
| | | | \+-------+ | | | | \+-------+
+---+ | +--------------+ | |PAA/AR/| +---+ | +--------------+ | |PAA/AR/|
|PaC| | | |DHCP |--- Internet |PaC| | | |DHCP |--- Internet
+---+ | +--------------+ | |Server | +---+ | +--------------+ | |Server |
| |Virtual AP2 | | /+-------+ | |Virtual AP2 | | /+-------+
| |(WPA PSK mode)|---- Authenticated / | |(WPA PSK mode)|---- Authenticated /
| | | | VLAN | | | | VLAN
| +--------------+ | | +--------------+ |
| | | |
+------------------+ +------------------+
Figure 18: Separate PAA and AP with two virtual APs Figure 16: Separate PAA and AP with two virtual APs
When a PaC does not have a PMK with an authenticated VLAN AP, the When a PaC does not have a PMK with an authenticated VLAN AP, the
following procedure is taken: following procedure is taken:
1. The PaC associates with the unauthenticated VLAN AP. 1. The PaC associates with the unauthenticated VLAN AP.
2. The PaC configures a pre-PANA IP address by using DHCP (in the 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or
case of IPv4) or configures a link-local address (in the case of configures a link-local address (in the case of IPv6), and then
IPv6), and then runs PANA by using the address. runs PANA by using the address.
3. Upon successful authentication, the PaC obtains a distinct PMK 3. Upon successful authentication, the PaC obtains a distinct PMK
for each authenticated VLAN AP controlled by the PAA. for each authenticated VLAN AP controlled by the PAA.
4. The PaC associated with an authenticated VLAN AP, with performing 4. The PaC associated with an authenticated VLAN AP, with performing
4-way handshake to establish a PTK (Pair-wise Transient Key) 4-way handshake to establish a PTK (Pair-wise Transient Key)
between the PaC and AP, by using the PMK. between the PaC and AP, by using the PMK.
5. The PaC obtains a post-PANA IP address by using any method that 5. If the PaC is required to configure a new IP address (POPA) as
the client normally uses. 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 Note that switching from one VLAN to another is a commonly used
technique in WPA (even without PANA) where the client that does not technique in WPA (even without PANA) where the client that does not
have any valid credentials first accesses the certificate server via have any valid credentials first accesses the certificate server via
https through the unauthenticated VLAN to perform a sign-in procedure https through the unauthenticated VLAN to perform a sign-in procedure
to obtain a certificate, and then switches to the authenticated VLAN to obtain a certificate, and then switches to the authenticated VLAN
with the obtained certificate. with the obtained certificate.
When the MSK is updated as a result of EAP re-authentication, a new 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. PMK is derived for and transfered to each authenticated VLAN AP.
  Skipping to change at page 34, line 39:
Since this case does not require virtual AP switching, the procedure Since this case does not require virtual AP switching, the procedure
to bootstrap PSK mode becomes simpler compared to the separate PAA to bootstrap PSK mode becomes simpler compared to the separate PAA
and EP case, however, with a cost of configuring RADIUS/Diameter and EP case, however, with a cost of configuring RADIUS/Diameter
client on each AP. client on each AP.
When a PaC does not have a PMK with an authenticated VLAN AP, the When a PaC does not have a PMK with an authenticated VLAN AP, the
following procedure is taken: following procedure is taken:
1. The PaC associates with the AP. 1. The PaC associates with the AP.
2. The PaC configures a pre-PANA IP address by using DHCP (in the 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or
case of IPv4) or configures a link-local address (in the case of configures a link-local address (in the case of IPv6), and then
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 3. Upon successful authentication, the PaC obtains a PMK for each AP
authenticated VLAN AP controlled by the PAA. controlled by the PAA.
4. The PaC performs 4-way handshake to establish a PTK (Pair-wise 4. The PaC performs 4-way handshake to establish a PTK (Pair-wise
Transient Key) between the PaC and AP, by using the PMK. Transient Key) between the PaC and AP, by using the PMK.
5. The PaC obtains a post-PANA address by using any method that the 5. The PaC obtains a POPA by using any method that the client
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.
a) Free access network a) Free access network
There is no IEEE 802.1X or PANA authentication in this access There is no IEEE 802.1X or PANA authentication in this access
  Skipping to change at page 36, line 14:
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 PRPA
and POPA address types or configuration mechanisms are different this and POPA types or configuration mechanisms are different this is not
is not a problem. One possible combination where such clues are 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)
  Skipping to change at page 38, line 12:
We would like to thank Bernard Aboba and Yacine El Mghazli for their We would like to thank Bernard Aboba and Yacine El Mghazli for their
valuable comments. valuable comments.
Normative References 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] [I-D.ietf-eap-rfc2284bis]
Blunk, L., "Extensible Authentication Protocol (EAP)", Blunk, L., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-07 (work in progress), December draft-ietf-eap-rfc2284bis-09 (work in progress), February
2003. 2004.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, Protocol (v3): Technical Specification", RFC 3377,
September 2002. September 2002.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000. 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[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-12 (work in Addresses", draft-ietf-zeroconf-ipv4-linklocal-14 (work in
progress), February 2004. progress), April 2004.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 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-12 (work in progress), January draft-ietf-ipsec-ikev2-13 (work in progress), March 2004.
2004.
[I-D.yacine-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., "PANA: SNMP usage for PAA-2-EP interface", Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
draft-yacine-pana-snmp-00 (work in progress), December PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in
2003. progress), April 2004.
[I-D.ietf-pana-pana] [I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-02 (work in Network Access (PANA)", draft-ietf-pana-pana-03 (work in
progress), October 2003. progress), February 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-01 (work in progress), Control", draft-ietf-pana-ipsec-02 (work in progress),
January 2004. March 2004.
[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-07 (work in progress), June
2003. 2003.
[I-D.tschofenig-pana-bootstrap-rfc3118] [I-D.yegin-eap-boot-rfc3118]
Tschofenig, H., "Bootstrapping RFC3118 Delayed Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping
authentication using PANA", RFC3118 Delayed DHCP Authentication Using EAP-based
draft-tschofenig-pana-bootstrap-rfc3118-01 (work in Network Access Authentication",
progress), October 2003. draft-yegin-eap-boot-rfc3118-00 (work in progress),
February 2004.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 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 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003. IPsec Tunnel Mode", RFC 3456, January 2003.
Informative References Informative References
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-03 (work in progress), October 2003. 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-03 (work in progress), August draft-ietf-pppext-eap-ttls-04 (work in progress), April
2003. 2004.
[I-D.tschofenig-eap-ikev2] [I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work in (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in
progress), October 2003. progress), February 2004.
[DSL] DSL Forum Architecture and Transport Working Group, "DSL [DSL] DSL Forum Architecture and Transport Working Group, "DSL
Forum TR-058 Multi-Service Architecture and Framework Forum TR-058 Multi-Service Architecture and Framework
Requirements", September 2003. Requirements", September 2003.
[802.11i] Institute of Electrical and Electronics Engineers, "Draft [802.11i] Institute of Electrical and Electronics Engineers, "Draft
supplement to standard for telecommunications and supplement to standard for telecommunications and
information exchange between systems - lan/man specific information exchange between systems - lan/man specific
requirements - part 11: Wireless medium access control requirements - part 11: Wireless medium access control
(mac) and physical layer (phy) specifications: (mac) and physical layer (phy) specifications:
Specification for enhanced security", IEEE 802.11i/D7.0, Specification for enhanced security", IEEE 802.11i/D10.0,
2003. 2004.
[802.11] Institute of Electrical and Electronics Engineers, [802.11] Institute of Electrical and Electronics Engineers,
"Information technology - telecommunications and "Information technology - telecommunications and
information exchange between systems - local and information exchange between systems - local and
metropolitan area networks - specific requirements part metropolitan area networks - specific requirements part
11: Wireless lan medium access control (mac) and physical 11: Wireless lan medium access control (mac) and physical
layer (phy) specifications", IEEE Standard 802.11, 1997. layer (phy) specifications", IEEE Standard 802.11,
1999(R2003).
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi
WPA v2.0, 2003. WPA v2.0, 2003.
Authors' Addresses Authors' Addresses
Prakash Jayaraman Prakash Jayaraman
Network Equipment Technologies, Inc. Network Equipment Technologies, Inc.
6900 Paseo Padre Parkway 6900 Paseo Padre Parkway
Fremont, CA 94555 Fremont, CA 94555
  Skipping to change at page 41, line 24:
EMail: prakash_jayaraman@net.com EMail: prakash_jayaraman@net.com
Rafa Marin Lopez Rafa Marin Lopez
University of Murcia University of Murcia
30071 Murcia 30071 Murcia
Spain Spain
EMail: rafa@dif.um.es EMail: rafa@dif.um.es
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Information Systems, Inc. Toshiba America Research, Inc.
9740 Irvine Blvd. 1 Telcordia Drive
Irvine, CA 92619-1697 Piscateway, NJ 08854
USA USA
Phone: +1 973 829 5174 Phone: +1 732 699 5365
EMail: yohba@tari.toshiba.com EMail: yohba@tari.toshiba.com
Mohan Parthasarathy Mohan Parthasarathy
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 408 734 8820 Phone: +1 408 734 8820
EMail: mohanp@sbcglobal.net EMail: mohanp@sbcglobal.net
Alper E. Yegin Alper E. Yegin
DoCoMo USA Labs Samsung Advanced Institute of Technology
181 Metro Drive, Suite 300 75 West Plumeria Drive
San Jose, CA 95110 San Jose, CA 95134
USA USA
Phone: +1 408 451 4743 Phone: +1 408 544 5656
EMail: alper@docomolabs-usa.com EMail: alper.yegin@samsung.com
Appendix A. Other Possible Cases for PANA with Bootstrapping IPsec in Appendix A. Other Possible Cases for PANA with Bootstrapping IPsec in
Wireless LAN Wireless LAN
This section describes other possible cases for PANA with This section describes other possible cases for PANA with
Bootstrapping IPsec in wireless LAN environments. Bootstrapping IPsec in wireless LAN environments.
Appendix A.1 IPv4 Appendix A.1 IPv4
Case D: IPsec-TIA obtained by using RFC3118 Case D: IPsec-TIA obtained by using RFC3118
In this case, the post-PANA address is configured and used as both In this case, the POPA is configured and used as both IPsec-TIA
IPsec-TIA and IPsec-TOA. The IPsec-TIA is assigned by using and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118
RFC3118 (authenticated DHCP) [RFC3118] before running IKE. The (authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK
DHCP-PSK needed for authenticated DHCP is distributed from the PAA needed for authenticated DHCP is distributed from the PAA to the
to the post-PANA DHCPv4 server by using the method specified in POPA DHCPv4 server by using the method specified in
[I-D.tschofenig-pana-bootstrap-rfc3118]. The pre-PANA address is [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using
assigned by using DHCPv4 and may be assigned with a short lease DHCPv4 and may be assigned with a short lease period in order to
period in order to provide some level of robustness against IP provide some level of robustness against IP address depletion
address depletion attack. The IPsec-TIA is bound to an IPsec SA attack. The IPsec-TIA is bound to an IPsec SA by using specifying
by using specifying the IPsec-TIA as the SA Identification in the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2
IKEv1 phase II or IKEv2 CREATE_CHILD_SA exchange as specified in CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec].
[I-D.ietf-pana-ipsec]. Once the IPsec-TIA is obtained, the PANA Once the IPsec-TIA is obtained, the PANA re-authentication based
re-authentication based on PRAR (PANA Re-Authentication Request) on PRAR (PANA Re-Authentication Request) and PRAA (PANA
and PRAA (PANA Re-Authentication Answer) exchange is performed Re-Authentication Answer) exchange is performed with using the
with using the obtained IPsec-TIA in order to inform PAA of the obtained IPsec-TIA in order to inform PAA of the update of PaC-DI.
update of PaC-DI. The IKE procedure should occur after the The IKE procedure should occur after the PRAR-PRAA exchange
PRAR-PRAA exchange procedure. The PaC unconfigures the pre-PANA procedure. The PaC unconfigures the PRPA immediately after the
address immediately after the IPsec-TIA is obtained. IPsec-TIA is obtained.
Pre-PANA PRPA
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv4 | | | | DHCPv4 | | |
|<-----------+------------>| | | |<-----------+--------->| | |
| | | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) | | & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| | | | | | | |
| | Post-PANA | | | | POPA | |
| | DHCPv4 Server |Authorization| | | DHCPv4 Server |Authorization|
| | |Authorization|[IKE-PSK, | | | |Authorization|[IKE-PSK, |
| | |[DHCP-PSK, | PaC-DI, | | | |[DHCP-PSK, | PaC-DI, |
| | | 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 post-PANA address as PaC-DI) | PANA(PRAR-PRAA exchange using POPA as PaC-DI) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 19: An example case for IPsec-TIA obtained by using RFC3118 Figure 17: An example case for IPsec-TIA obtained by using RFC3118
Appendix A.2 IPv6 Appendix A.2 IPv6
Case D: IPsec-TIA obtained by using authenticated DHCPv6 Case A: IPsec-TIA obtained by using DHCPv6
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
procedure can occur at any time after link-layer association and
before IKE.
This case is not recommended since there is an ambiguity on
whether IPv6 Neighbor Discovery for the POPA should run on the
physical interface or inside the IPsec tunnel or both.
PaC AP DHCPv6 Server PAA EP(AR)
| Link-layer | | | |
| association| | | |
|<---------->| | | |
| | | | |
| DHCPv6 | | |
|<-----------+------------>| | |
| | | | |
|PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | | |
| | | |Authorization|
| | | |[IKE-PSK, |
| | | | PaC-DI, |
| | | | Session-Id] |
| | | |------------>|
| | | | |
|PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | | |
| | IKE | |
|<-----------+---------------------------------------->|
| | | | |
| | | | |
Figure 18: An example case for IPsec-TIA obtained by using DHCPv6
Case B: IPsec-TIA obtained by using IPv6 stateless address
autoconfiguration
In this case, the IPsec-TOA (link-local address) and IPsec-TIA
(global address) are configured through IPv6 stateless address
autoconfiguration before running IKE. Other configuration
information can be obtained by using several methods including
authenticated DHCPv6, Configuration Payload exchange and DHCPv6
over IPsec SA.
This case is not recommended for the same reason as Case A of
IPv6.
PaC AP PAA EP(AR)
| Link-layer | | |
| association| | |
|<---------->| | |
| | | |
| | | |
|PANA(Discovery and Initial Handshake phase |
| & PAR-PAN exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | |
| | |Authorization|
| | |[IKE-PSK, |
| | | PaC-DI, |
| | | Session-Id] |
| | |------------>|
| | | |
|PANA(PBR-PBA exchange in Authentication phase) |
|<-----------+-------------------------->| |
| | | |
| IPv6 stateless address autoconfiguration |
| (can occur at any time before Association and IKEv2) |
|<-----------+---------------------------------------->|
| | | |
| | IKEv2 | |
|<-----------+---------------------------------------->|
| | | |
Figure 19: An example sequence for IPsec-TIA obtained by using
IPv6 stateless address autoconfiguration
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 pre-PANA address, and that there is no need address is used as the PRPA, and that there is no need for
for additional PRAR-PRAA exchange to update the PaC-DI. additional PRAR-PRAA 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 44, line 27:
| | | 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 post-PANA address as PaC-DI) | 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 IPsec-TIA obtained by using Figure 20: 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 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; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the