1. TGr Architectural Entities
Month Year
doc.: IEEE yy/xxxxr0
May 2006
TGr Architectural Entities
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. Abstract These slides discuss the TGr Architectural Entities. May 2006
Month Year
doc.: IEEE yy/xxxxr0
May 2006
Abstract
These slides discuss the TGr Architectural Entities.
D. Stanley, Aruba Networks
John Doe, Some Company

3. IEEE 802.11ma-REV Understand 802.11 baseline (what TGr amends)
May 2006
IEEE ma-REV
Understand baseline (what TGr amends)
802.1X protocol entities are the Authenticator, Supplicant and AS
Authenticator, Supplicant state machines defined, and RSNA Key Management (RSNA Authenticator and Supplicant State machines) replace 802.1X key management
D. Stanley, Aruba Networks

4. Expanded Diagram, Showing More of the Players
May 2006
Expanded Diagram, Showing More of the Players
The Authenticator comprises
The NAS,
RSNA Key Management
802.1X Port Control
The EAP server, when no AS is present
D. Stanley, Aruba Networks

5. Definitions from 06/323r0 May 2006 IEEE 802.1X Authenticator (NAS)
Forwards the EAP exchanges between the Supplicant and the Authentication Server
Receives the MSK from the AS
Derives the PMK-R0 from the MSK
Transfers the PMK-R0 to the R0KH
Is identified by the NAS-ID
PMK-R0 Key Holder (R0KH) – Performs RSNA Key Management Functions, looks like an authenticator, acts like an authenticator….
Receives the PMK-R0 from the NAS
Derives the PMK-R1
Transfers the PMK-R1 to the R1KH
Is identified by the R0KH-ID
PMK-R1 Key Holder (R1KH) - Performs RSNA Key Management Functions, looks like an authenticator, acts like an authenticator….
Receives the PMK-R1 from the R0KH
Performs the 4-way handshake with the Supplicant
Derives the PTKs
Is identified by the R1KH-ID
D. Stanley, Aruba Networks

6. The TGr Entities Authenticator R0KH R1KH
May 2006
The TGr Entities
Authenticator
802.1X Port Control + RSNA Authenticator and Supplicant Key Management
R0KH
A new entity, or a new, specific name for an existing entity?
The First Association Authenticator
R1KH
A new entity, or a new specific name for an existing entity?
Either the First Association Authenticator or a different authenticator
The entity performing the PMKR1 to PTK derivation
D. Stanley, Aruba Networks

7. May 2006
Expanded Diagram - Authenticator Functions RSNA (Draft 2.x IEEE r)
D. Stanley, Aruba Networks

8. Draft TGr RSNA Key Management
May 2006
Draft TGr RSNA Key Management
TGr defines new RSNA Key management function partitioning – first association authenticator vs transitioned-to-authenticator
R0KH and R1KH functions seem to be authenticator functions
Unclear that new entities are needed/defined, vs uniquely named, with different functions to perform
In draft .11r, the equivalent 4-way handshake data elements are included in association and authentication frames rather than EAPOL-Key data frames.
Doesn't necessarily mean that the processing of the data elements moves to the MAC, it could be that the MLME interface conveys the data elements to and from the MAC, rather than extending authenticator functionality into the MAC.
Or, extend the authenticator functionality into the MAC
Benefits? Rationale?
D. Stanley, Aruba Networks

9. Fat-AP Model Authenticator functionality typically in “Fat AP Unit”
May 2006
Fat-AP Model
Authenticator functionality typically in “Fat AP Unit”
Authenticator includes R0KH, R1KH functions
Definitions “work”
D. Stanley, Aruba Networks

10. May 2006
WLAN Switch model
Authenticator functionality typically in Access Controller, for both split MAC and local MAC
Defintions “work”
Any need to change this – e.g. lower case in figure?
D. Stanley, Aruba Networks

11. May 2006
References
D. Stanley, Aruba Networks