1. TGr Authentication Framework
doc: IEEE /724r0
July 2005
July 2005
TGr Authentication Framework
Date:
Author(s):
Name
Company
Address
Phone
Dan Harkins
Trapeze Networks
5753 W. Las Positas blvd
Pleasanton, CA 94588
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
Dan Harkins, Trapeze Networks
Dan Harkins, Trapeze Networks

2. doc: IEEE /724r0
July 2005
July 2005
Abstract
The r draft currently specifies 5 distinct entities with no defined role. This brings up problems with how 802.1X, EAP, and RADIUS are used. This presentation describes the problem and recommends a solution to adhere r to a more orthodox view of these protocols.
Dan Harkins, Trapeze Networks
Dan Harkins, Trapeze Networks

3. 802.11r Entities AAA Client PMK-R0 holder PMK-R1 holder PMK-R2 holder
doc: IEEE /724r0
July 2005
July 2005
802.11r Entities
AAA Client
PMK-R0 holder
PMK-R1 holder
PMK-R2 holder
PTK holder
There are 11 different ways to combine them.
And many of those combinations are problematic and unorthodox.
Dan Harkins, Trapeze Networks
Dan Harkins, Trapeze Networks

4. 802.11r Entities AAA client PMK-R0 holder PMK-R1 holder PTK holder
July 2005
802.11r Entities
AAA client
PMK-R0 holder
PMK-R1 holder
PTK holder
Even without the lower layer of the key hierarchy there are still 8 different ways to combine them many with the same problematic and unorthodox issues.
Dan Harkins, Trapeze Networks

5. Problems with 5 distinct entities
July 2005
Problems with 5 distinct entities
“first contact” is with a PMK-Rx holder but the AAA client forwards the EAP traffic on to a AAA server.
Prevents EAP channel binding from being used
Should be reason enough for the STA to disassociate!
How are EAP packets transported between these PMK-Rx holders and the AAA client?
EAP places specific requirements on its transport
“the AAA Client…may be co-located with the PMK-R0 key holder or may be a separate device”
NO!
Dan Harkins, Trapeze Networks

6. Problems with 5 distinct entities
July 2005
Problems with 5 distinct entities
How can authorization of PMK key holders be sanely performed when PMKs are being so widely distributed?
Need to distribute more than just a PMK-Rx
To properly use EAP we must define what we distribute, where and how.
With 5 distinct entities the job is difficult, more difficult than it needs to be. Even with 4 distinct entities it is much harder than necessary.
We cannot just say it’s “out of scope”.
Dan Harkins, Trapeze Networks

7. July 2005
Proposal
Restrict the number different combinations of r entities to 2
The AAA client and PMK-Rx holders are co-incident, and the PTK holder is separate
All five entities are co-incident
Satisfy all architectures described in CAPWAP taxonomy memo
Enforce a traditional and orthodox use of 802.1x and EAP on r
Dan Harkins, Trapeze Networks

8. What is an authenticator?
July 2005
What is an authenticator?
A PMK holder
A NAS, identified by a NAS-Id
A AAA client
An EAP authentication occurs at an authenticator, not at an access point.
The 4-way handshake is between a STA and an authenticator, not a STA and an access point.
Dan Harkins, Trapeze Networks

9. Requirements on an authenticator
July 2005
Requirements on an authenticator
Upon successful “first contact” authentication of a STA it must derive all PMKs as well as appropriate PMKSAs for itself.
Authorization attributes returned by AAA must be part of all PMKSAs and they must be distributed to other NASes along with the PMK derivative.
Dan Harkins, Trapeze Networks

10. How does it work? AAA server AAA client AAA client PMK-R0 NAS a PMK-R0
July 2005
AAA server
AAA client
AAA client
PMK-R0
NAS a
PMK-R0
NAS b
PMK-R1-a
PMK-R1-b
PTK holder
PTK holder
PTK holder
Dan Harkins, Trapeze Networks

11. Benefits Allows for proper analysis of 802.11r
July 2005
Benefits
Allows for proper analysis of r
Conforms r to approved use of EAP
Enables
EAP Key scoping
EAP channel binding
Authorization and correctness
Dan Harkins, Trapeze Networks

12. doc: IEEE /724r0
July 2005
July 2005
Motion
Instruct editor to incorporate changes from r into draft.
Dan Harkins, Trapeze Networks
Dan Harkins, Trapeze Networks