1. Impact of KTP Non-definition
Month Year
doc.: IEEE yy/xxxxr0
May 2006
Impact of KTP Non-definition
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
D. Stanley, Aruba Networks
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
May 2006
Abstract
This submission summarizes the impact of Key Transfer Protocol non-definition
TGr D2.0 Issue 56
D. Stanley, Aruba Networks
John Doe, Some Company

3. Without a KTP, Inter-MD Transitions become time sensitive
Month Year
doc.: IEEE yy/xxxxr0
May 2006
Without a KTP, Inter-MD Transitions become time sensitive
TGr D2.0 defines transitions within a Mobility Domain
Transitions between Mobility Domains use TGr Initial Association, and are assumed to be non-time critical 
TGr D2.0 requires but does not define a back-end mechanism to securely deliver keys (other transition data may also need to be delivered)
Without a standard back-end mechanism, the key transfer protocol will be vendor specific, and TGr fast transitions will not be possible between products from different vendors
Practical result for product deployments
TGr BSS transitions possible only in intra-vendor deployments; full 802.1X authentication required for inter-vendor transitions
Fat APs fromdifferent vendors – One MD per AP – Full 802.1X auth needed – TGr does not apply!
Mixed Fat AP + WLAN controller, different vendors - TGr transition possible only within WLAN controller
TGr D2.0 does not provide fast transitions in multi-vendor deployments
D. Stanley, Aruba Networks
John Doe, Some Company

4. May 2006 AAA Server Controller/ MDCvendor 1 Controller/ MDCvendor 2
Month Year
doc.: IEEE yy/xxxxr0
May 2006
MD 4
R0KH3
SSID-ABC v4
MD 5
R0KH3
SSID-ABC v5
FAT APs
TGr First
Association; no
Improvement over
TGi
AAA
Server
MD 3
R0KH3
SSID-ABC v3
Mobility Domain 1
R0KH-1
SSID-ABC
MD 7
R0KH3
SSID-ABC v7
MD 6
R0KH3
SSID-ABC v6
Controller/
MDCvendor 1
Controller/
MDCvendor 2
Mobility Domain 2
R0KH-2
SSID-ABC
Controller
APr
APr
Controller
BSS Transition 1
TGr Fast Transition
APr
APr
BSS Transition 3
Fast Transition
BSS Transition 2
TGr First Association, Including 802.1X EAP
D. Stanley, Aruba Networks
John Doe, Some Company

5. Possible TGr solutions
Month Year
doc.: IEEE yy/xxxxr0
May 2006
Possible TGr solutions
If KTP not specified, Speed up the inter-mobility domain transitions
Option 1: Extend existing, standardized i pre-authentication solution to also apply to TGr
Simple, minimal solution
Edits to Clause : change from:
"A STA’s Supplicant can initiate preauthentication when it has completed the 4-Way Handshake and configured the required temporal keys." to
A STA’s Supplicant can initiate preauthentication when it has completed the 4-Way Handshake or TGr First Association and configured the required temporal keys.”
An “Over the DS” solution
Option 2: Change FT Initial Association to have 802.1X exchange prior to (re) association
An “Over the Air” solution
Option 3: Define a Key Transfer Protocol
Other approaches?
D. Stanley, Aruba Networks
John Doe, Some Company