Secure 3-Party Protocol May 2006 doc.: IEEE 802.11-06/0695r0 May 2006 Secure 3-Party Protocol Date: 2006-05-14 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>. Dan Harkins, Tropos Networks

May 2006 doc.: IEEE 802.11-06/0695r0 May 2006 Abstract This document describes how the secure 3 party protocol (11-06/0637) operates to authorize key holders to possess a PMK-R1 and distribute the appropriate key and attributes to it. Dan Harkins, Tropos Networks

What’s the problem? The draft doesn’t say how to distribute a PMK-R1. May 2006 doc.: IEEE 802.11-06/0695r0 May 2006 What’s the problem? The draft doesn’t say how to distribute a PMK-R1. It must be done “securely” It must contain “binding information” (whatever that is!) The MDC facilitates the authentication of key holders and “the identities of the Key Holders presented to the MDC shall be the same as that advertised to the STA”. What identities would that be? How are these identities advertised to the STA? Interoperability is not possible. There is an assumption that possession of a PMK-R1 implies authorization to hold it. Dan Harkins, Tropos Networks

What’s the solution? A secure 3 party protocol! Provide all the features that the draft says are necessary– confidentiality, integrity validation, replay protection, and key binding– as well as two other essential ones Authorization: a key holder is sanctioned by both the STA and the PMK-R0 holder to become a legitimate holder of a PMK-R1 Validation: the authorization is acknowledged and the key holder can demonstrate it’s new status. The players: STA, target AP, and PMK-R0 holder

The Basic Assumptions Each key holder is identified by its 802.1X authenticator’s NAS-Id. The NAS-Id is the identity each key holder uses when it establishes security associations with other key holders (as facilitated by the MDC). A security association between 2 key holders provides a secure channel for communication between them. Each AP beacons out the NAS-Id of the 802.1X authenticator it is part of.

How it Logically Works MDC “B” “C” “A” “A and C” “B” “C” “A” “A and B” “B and C” APs identify each other by NAS-Id and establish SAs with each other with the help of the MDC

How it Logically Works “B” “C” “A” STA does initial association with A, A becomes PMK-R0 holder STA hands off to B, does 3 party protocol, B becomes PMK-R1 holder, STA does FT with B STA hands off to C, does 3 party protocol, C becomes PMK-R1 holder, STA does FT with C “B” PMK-R1 “C” “A” PMK-R1 PMK-R0

The Protocol STA target AP PMK-R0 holder ID-STA is MAC address ID-TAP is NAS-ID Ns is a random number chosen by the STA Na is a random number chosen by the PMK-R0 holder mk is a key shared between the STA and PMK-R0 holder AUTH is SHA-256(Na | Ns) {Z}x is AES Key wrapping of Z with symmetric key x R0KH-ID, {Ns, ID-TAP}mk ID-STA, {Ns, ID-TAP}mk ID-STA, Na, Ns, PMK-R1, auth-attributes, PMKR1Name, {ID-TAP, Na}mk AUTH, {ID-TAP, Na}mk

Comments? Complaints? Criticisms? Questions? Comments? Complaints? Criticisms?

Motion Adopt the changes specified in 06/0637r0 into the next TGr draft