1. 802.11i Bootstrapping Using PANA
May 2006
doc.: IEEE /0622r0
May 2006
802.11i Bootstrapping Using PANA
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Yoshihiro Ohba, Toshiba America Research, Inc.
Yoshihiro Ohba, Toshiba America Research, Inc.

2. May 2006
doc.: IEEE /0622r0
May 2006
Abstract
This document describes a brief overview of IETF PANA Framework draft ( in terms of i bootstrapping and related issues that would need feedback from WG. The PANA framework draft is being standardized in IETF PANA WG
Yoshihiro Ohba, Toshiba America Research, Inc.
Yoshihiro Ohba, Toshiba America Research, Inc.

3. Goals/Non-Goals of this Presentation
May 2006
Goals/Non-Goals of this Presentation
Goals:
Explain PANA model and its usage for i
Explain the recent issues and the interpretation request sent from IETF PANA WG Chairs to WG
Ask for feedback from security experts on i bootstrapping PSK mode using PANA
Non-goals:
Ask some modifications to specification to support PANA
Discussion on “EAP over L2” vs. “EAP over IP”
Yoshihiro Ohba, Toshiba America Research, Inc.

4. May 2006
What is PANA?
PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic EAP transport defined on top of UDP
Being defined in IETF PANA Working Group
Status:
Completed WG Last Call, Area Director review and IETF Last Call
Waiting for feedback from WG before IESG review
Yoshihiro Ohba, Toshiba America Research, Inc.

5. The PANA Model EAP over PANA (over UDP/IP) IKE/ SNMP/API
May 2006
The PANA Model
AAA
(RADIUS/
Dimeter)
EAP over PANA
(over UDP/IP)
PANA
Client
(PaC)
PANA
Authentication
Agent
(PAA)
Authentication
Server
(AS)
IKE/
4-way handshake
SNMP/API
Enforcement
Point
(EP)
Filtering Parameters,
Keys
Access Point/Base Station,
Access Router, etc.
EP and PAA can be implemented on separate nodes
PAA can control multiple EPs
PaC and PAA do not have to be on the same subnet.
Yoshihiro Ohba, Toshiba America Research, Inc.

6. Framework for Bootstrapping Lower-Layer Security using PANA
May 2006
Framework for Bootstrapping Lower-Layer Security using PANA
PANA is used for bootstrapping lower-layer security in an L2-agnostic manner
Bootstrapping is based on generating a master key (PaC-EP-Master-Key) from EAP-generated key, for each pair of PaC and EP
PaC-EP-Master-Key = prf+ (AAA-Key, “PaC EP Master Key” |
Session-Id | Key-Id | EP-Device-ID)
prf+: IKEv2 pseudo random function macro
The actual pseudo random function for prf+ is negotiated within PANA
AAA-Key: A Key exported by an EAP method
Session-Id: PANA Session Identifier
PAA’s FQDN combined with an additional identifier locally generated by the PAA
Key-Id: Key identifier of AAA-Key
EP-Device-ID: Device Identifier of EP
2-octet address-family concatenated with a variable length address value
IEEE MAC address, IP address, etc. can be a device ID
Provides cryptographic separation among PaC-EP-Master-Keys generated for different EPs.
List of EP-Device-IDs are advertised from PAA using PANA message
The PaC-EP-Master-Key is installed to the corresponding EP and made available to SAP (Secure Association Protocol) to generate TSKs (Transient Session Keys) for use of lower-layer per-packet ciphering
Yoshihiro Ohba, Toshiba America Research, Inc.

7. Bootstrapping 802.11i PSK mode using PANA
May 2006
Bootstrapping i PSK mode using PANA
Non-AP STA (PaC) and target APs (EPs) operate in PSK mode
PaC associates to an AP and obtains an IP address using a standard IP configuration method such as DHCP(v4/v6) and IPv6 stateless address autoconfiguration and IPv4 link-local address configuration
This initial AP is either
One of the target APs operating in PSK mode (Option 1), OR
Another AP operating in open-access mode (Option 2)
PANA authentication starts.
After PANA authentication, PaC-EP-Master-Keys are generated for the target APs using BSSIDs of the APs as EP-Device-ID
PaC and EP use the PaC-EP-Master-Keys as the PSKs for the target APs
Yoshihiro Ohba, Toshiba America Research, Inc.

8. Option 1: PANA over 802.1X Uncontrolled Port
May 2006
Option 1: PANA over 802.1X Uncontrolled Port
(2) IP address configuration and PANA over
802.1X Uncontrolled Port
Target
AP1
PaC
PAA
Target
AP2
(1) Association
(4) 4-way HS
(3) Per-STA PSK Installation
Yoshihiro Ohba, Toshiba America Research, Inc.

9. Option 2: PANA over Open-Access AP
May 2006
Option 2: PANA over Open-Access AP
(1) Association, IP address configuration and PANA
Open
Access AP
Target
AP1
PaC
PAA
Target
AP2
(3) Association w/4-way HS
(2) Per-STA PSK Installation
Yoshihiro Ohba, Toshiba America Research, Inc.

10. May 2006
Issue on Option 1
Option 1 requires limited IP packets (DHCP, PANA, etc.) to make use of 802.1X Uncontrolled Port before enabling Controlled Port
Most i implementations does not allow IP packets to make use of 802.1X Uncontrolled Port
Is this an implementation issue? Or does i specification prohibit this without any exception?
An Interpretation Request has been sent from IETF PANA WG Chairs to IEEE WG
Yoshihiro Ohba, Toshiba America Research, Inc.

11. Interpretation Request sent to IEEE
May 2006
Interpretation Request sent to IEEE
1. The specific designation of the standard, including the year of publication: IEEE Std i 2004
2. The specific subsection being questioned:
In Clause : "However, a given protocol may need to bypass the authorization function and make use of the IEEE 802.1X Uncontrolled Port.“
In Clause 6.1.4: "The IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled or if the MSDU does not represent an IEEE 802.1X frame."
3. The applicable conditions for the case in question: Is a non-802.1X frame such an IP datagram allowed to make use of 802.1X Uncontrolled Port before Controlled Port is enabled in a certain case? The question comes up because IETF PANA WG is defining a mode in which PANA protocol messages, carried in IP datagrams, make use of 802.1X Uncontrolled Port over i.
It appears that there is a strict architectural boundary between i and 802.1X in that the i state machines order and filter events that are related to 802.1X so that 802.1X state machines can process them. If so, how 802.1X state machines process those events should be governed by 802.1X, not by i. In that sense, shouldn't the above quoted text in both Clause and Clause be interpreted as informative, not normative?
Yoshihiro Ohba, Toshiba America Research, Inc.

12. May 2006
References
IEEE Std i 2004
PANA FAQ:
Yoshihiro Ohba, Toshiba America Research, Inc.