802.11i Bootstrapping Using PANA May 2006 doc.: IEEE 802.11-06/0622r0 May 2006 802.11i Bootstrapping Using PANA Date: 2006-05-12 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Yoshihiro Ohba, Toshiba America Research, Inc. Yoshihiro Ohba, Toshiba America Research, Inc.

May 2006 doc.: IEEE 802.11-06/0622r0 May 2006 Abstract This document describes a brief overview of IETF PANA Framework draft (http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-06.txt) in terms of 802.11i bootstrapping and related issues that would need feedback from 802.11 WG. The PANA framework draft is being standardized in IETF PANA WG Yoshihiro Ohba, Toshiba America Research, Inc. Yoshihiro Ohba, Toshiba America Research, Inc.

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

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 802.11 WG before IESG review Yoshihiro Ohba, Toshiba America Research, Inc.

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.

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.

Bootstrapping 802.11i PSK mode using PANA May 2006 Bootstrapping 802.11i 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.

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.

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.

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 802.11i implementations does not allow IP packets to make use of 802.1X Uncontrolled Port Is this an implementation issue? Or does 802.11i specification prohibit this without any exception? An Interpretation Request has been sent from IETF PANA WG Chairs to IEEE 802.11 WG Yoshihiro Ohba, Toshiba America Research, Inc.

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 802.11i 2004 2. The specific subsection being questioned: In Clause 5.4.2.2: "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 802.11i. It appears that there is a strict architectural boundary between 802.11i and 802.1X in that the 802.11i 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 802.11i. In that sense, shouldn't the above quoted text in both Clause 5.4.2.2 and Clause 6.1.4 be interpreted as informative, not normative? Yoshihiro Ohba, Toshiba America Research, Inc.

May 2006 References IEEE Std 802.11i 2004 http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-06.txt http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-11.txt PANA FAQ: http://www.panasec.org/docs/PANA-FAQ.txt Yoshihiro Ohba, Toshiba America Research, Inc.