1. R0KH-R1KH protocol requirements
Month Year
doc.: IEEE yy/xxxxr0
November, 2005
R0KH-R1KH protocol requirements
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
All
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
November, 2005
Abstract
This presentation describes initial discussion results re: R0KH-R1KH protocol requirements.
All
John Doe, Some Company

3. TGr Key Hierarchy November, 2005 Month Year
doc.: IEEE yy/xxxxr0
November, 2005
TGr Key Hierarchy
AAA Server
MSK
MD-ID = MAC Address of MDC
Mobility Domain
Controller
MDC manages keys for distributing PMK-R1; Authorization, Identity and Attestation of Authenticators
R1KH-ID
R0KH-ID
R1KH-ID
PMK-R0
PMK-R1
AP3
AP1
AP2
TSTA
TSTA
All
John Doe, Some Company

4. Key State Requirements
November, 2005
Key State Requirements
R0Key
At R0KH
R1Key
At all R1KHs in the Mobility Domain
Does the R0 Key need to stay around?
If R1Key push model used – no. Actual lifetime less than actual life of R1Key.
Max key lifetime of R0Key >= Max key lifetime of R1Key
All

5. Month Year
doc.: IEEE yy/xxxxr0
November, 2005
System Capabilities
Introduce the Mobility Domain Controller (MDC) Function
One MDC per Mobility Domain, Authorizes Authenticators to be part of the Mobility Domain
MAC address of the Mobility Domain Controller names the Mobility Domain
MDC function can be collocated with an Authenticator, or a separate box
Protocol Options to generate keys, authenticate peers Include
Deploy certificates for Authenticators
Needham-Schroeder based protocol
Then can use keys with RFC3576 messages
All
John Doe, Some Company

6. System Capabilities Both Push and Pull models supported
Month Year
doc.: IEEE yy/xxxxr0
November, 2005
System Capabilities
Both Push and Pull models supported
R0KH can push R1Keys to peer Authenticators
R1KH can pull R1Keys from R0Key Holder
Protocol between Authenticators within a Mobility Domain
IP? Yes. Gives the most flexibility in deployment
L2? Not recommended. Requires that all ACs (Authenticators) in a Mobility Domain are on the same VLAN.
In CAPWAP architecture, IP used between WTP and AC, to provide deployment flexibility. Follow this model.
All
John Doe, Some Company

7. Observations Authenticators (ACs) must have static IP addresses
Month Year
doc.: IEEE yy/xxxxr0
November, 2005
Observations
Authenticators (ACs) must have static IP addresses
MDC must provide authenticated source for 3 attributes of a KH
IP address, MAC address, Authenticator name/address
Process Recommendation
Do work in IETF (IP based)
Informational RFC, individual submission
Possible Radext work
All
John Doe, Some Company

8. November, 2005
References
All