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

Month Year doc.: IEEE 802.11-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

Without a KTP, Inter-MD Transitions become time sensitive Month Year doc.: IEEE 802.11-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

May 2006 AAA Server Controller/ MDCvendor 1 Controller/ MDCvendor 2 Month Year doc.: IEEE 802.11-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

Possible TGr solutions Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Possible TGr solutions If KTP not specified, Speed up the inter-mobility domain transitions Option 1: Extend existing, standardized 802.11i pre-authentication solution to also apply to TGr Simple, minimal solution Edits to Clause 8.4.6.1: 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