1. May 2007 MSA Comment Resolution Overview
doc.: IEEE /0755r0
May 2007
May 2007 MSA Comment Resolution Overview
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
Steve Emeott, Motorola
Steve Emeott, Motorola

2. May 2007
doc.: IEEE /0755r0
May 2007
Abstract
This presentation summarizes the following submissions related to comment resolution on MSA-related issues:
11-07/0564r1 revises the Initial MSA Authentication mechanism (11A.2.2.2) and Subsequent MSA Authentication (11A.2.2.3), combining these to create a single MSA authentication protocol.
11-07/0618r0 resolves comments related to key holder descriptions and key derivations (8.8).
Steve Emeott, Motorola
Steve Emeott, Motorola

3. MSA Authentication (564r1)
May 2007
MSA Authentication (564r1)
A single MSA authentication mechanism is defined, merging the Initial MSA Authentication and Subsequent MSA Authentication previously defined.
MSA Authentication consists of peer link management followed by a 4-way handshake.
MSA Authentication optionally includes Initial MSA Authentication which are steps that occur between peer link management and the 4-way handshake, such as 802.1X authentication, and establishment of the key hierarchy.
Steve Emeott, Motorola

4. MSA Authentication steps
May 2007
MSA Authentication steps
Mesh Point
Mesh Point
During peer link management, it is determined whether a common PMK-MA is available between the two peer MPs.
If not, Initial MSA Authentication is enabled (provided one MP has a connection to the MKD).
If so, the Initial MSA Authentication steps are skipped; the resulting protocol is essentially that of the Subsequent MSA Handshake (D1.03, 11A.2.2.3).
Peer Link Open
Peer Link Open
Peer Link Confirm
Peer Link Confirm
Initial MSA Authentication (e.g., EAP Authentication)
4-way Handshake #1
4-way Handshake #2
4-way Handshake #3
4-way Handshake #4
Steve Emeott, Motorola

5. MPs perform key selection & 802.1X role selection.
May 2007
Peer link management
The peer link open messages:
Indicate security capabilities
Indicate parameter choices
Identify available PMK-MAs by name
Indicate a request to authenticate
Key selection determines if Initial MSA Authentication is required, or chooses an available PMK-MA.
802.1X Role selection assigns supplicant & authenticator roles for the MSA 4-way handshake, and 802.1X authentication (if needed).
These selections are confirmed by each MP in the peer link confirm messages.
Each MP should independently reach the same selection of PMK-MA and 802.1X role.
Mesh Point
Mesh Point
Peer Link Open
Peer Link Open
MPs perform key selection & 802.1X role selection.
Peer Link Confirm
Peer Link Confirm
Steve Emeott, Motorola

6. May 2007
Key selection
If an MP requests authentication in the P.L. open message, then no PMK-MA is chosen. Initial MSA Authentication will create a key hierarchy, resulting in a common PMK-MA.
Otherwise, the key is selected based on connection to the MKD and cached keys.
If the MPs have 2 cached PMK-MAs in common, the MAC address is used as a tie-breaker to pick one.
If the MPs have 1 cached PMK-MA in common, that is selected.
If the MPs have no cached PMK-MAs in common, but at least one MP has a connection to the MKD, then the PMK-MA is identified, and the key will be retrieved from the MKD after peer link management.
This procedure prevents superfluous communications (e.g., key retrievals) with the MKD.
Steve Emeott, Motorola

7. May 2007
802.1X role selection
802.1X Authenticator and Supplicant roles are determined for the MSA 4-way handshake, and for 802.1X authentication, if required.
Role selection is based on the connection to the MKD, and whether an MP will undergo Initial MSA Authentication.
The MP with a connection to the MKD is the 802.1X authenticator.
If there is no connection to the MKD, assign roles based on MAC addresses.
If both are connected, assign based on MAC addresses, except:
If exactly one MP requests Initial MSA Authentication, then it is the 802.1X supplicant; the other MP is the 802.1X authenticator.
Steve Emeott, Motorola

8. Security parameter selection
May 2007
Security parameter selection
The AKM Suite and Pairwise Cipher Suite each need to be negotiated during peer link management.
The Selector MP is the MP designated to choose each of these, from the set of suites supported by both MPs.
The Selector MP is the MP with the numerically larger MAC address.
The Selector MP indicates its selection in the peer link open message. Each MP confirms this selection in the peer link confirm message.
Steve Emeott, Motorola

9. Additional improvements in 564r1
May 2007
Additional improvements in 564r1
Failure of peer link management during MSA authentication has been given explicit reason codes.
Clarification of processing for 4-way handshake, due to slight differences from the “11i” version in 8.5 of
PMK-MKD and PMK-MA security association definitions moved to appropriate clause in the standard.
Steve Emeott, Motorola

10. Summary: MSA Authentication (564r1)
May 2007
Summary: MSA Authentication (564r1)
Merges two previous authentication protocols (“Initial” and “Subsequent”) into a single MSA authentication mechanism, that includes Initial MSA Authentication when required.
Key selection and 802.1X role selection procedures revised.
Comment resolution: 18 comments, primarily related to role negotiation & the MSA authentication mechanisms.
See end of document 564r1 for table of resolved comments.
Steve Emeott, Motorola

11. Key Distribution Comment Resolution (618r0) [1]
May 2007
Key Distribution Comment Resolution (618r0) [1]
Revises the overivew of the mesh key hierarchy and key distribution among mesh key holders, to improve clarity. (8.8.1)
Renames keys (e.g., former KDK and PTK-KD) to associate more closely with a mesh.
Cleans up some key derivations, for consistency in the order and inclusion of the non-secret parameters used in the key calculations. ( )
Refines the wording of existing key holder requirements for correctness & clarity. ( )
Steve Emeott, Motorola

12. Key Distribution Comment Resolution (618r0) [2]
May 2007
Key Distribution Comment Resolution (618r0) [2]
Considers key holder requirements from TGr, and updates mesh requirements as needed ( )
Identity of NAS Client at MKD made explicit (“MKD-NAS-ID”), advertised to supplicant MP, and bound into first-level key derivations. (This facilitates EAP Channel Binding.)
Clarifies functions provided by MKD & MA (key holders). ( )
Discusses authorization of mesh key holders. ( )
How an MKD is authorized to create & distribute keys for an MA
How an MA is authorized to receive PMK-MA keys.
How PMK-MA keys are to be distributed
Steve Emeott, Motorola

13. Summary: Key Distribution (618r0)
May 2007
Summary: Key Distribution (618r0)
Revises 8.8 (Key Distribution for MSA), especially Overview and Mesh key Holders.
Improved clarity of description of key hierarchy
Additional key holder requirements, and key holder authorization discussion added.
Minor changes to MSAIE & Initial MSA Authentication sections to permit communication of the MKD-NAS-ID to the supplicant MP.
Comment resolution: 21 comments, primarily related to key derivation and MKD topics.
See end of document 618r0 for table of resolved comments.
Steve Emeott, Motorola

14. May 2007
Backup
Steve Emeott, Motorola

15. MKD Key Holder Requirements (8.8.9.1) New requirements in blue
May 2007
MKD Key Holder Requirements ( ) New requirements in blue
The MKD shall provide NAS client (the client component of a Network Access Server that communicates with an Authentication Server) functionality.
The MKD domain identifier (MKDD-ID) uniquely identifies an MKD (i.e., there is a one-to-one mapping between an MKD domain identifier and an MKD). The MKDD-ID is bound into the derivation of the first level keys (PMK-MKD and MKDK).
The MKD NAS Identifier (MKD-NAS-ID) shall be set to the identity of the NAS Client provided by the MKD (e.g., NAS-Identifier as defined in RFC 2865 if RADIUS is used as the backend protocol). MKD-NAS-ID shall not be longer than 48 octets. MKD-NAS-ID is bound into the derivation of the first level keys (PMK-MKD and MKDK).
The mesh key distributor identifier (MKD-ID) shall be set to a MAC address of the physical entity that stores the MKD. The MKD-ID is used in the generation of the MPTK-KD.
When the PMK-MKD lifetime expires, the MKD shall delete the PMK-MKD SA and shall delete all PMK-MAs cached within the MKD that were derived from the PMK-MKD.
The MKD shall not expose the PMK-MKD to other parties.
The MKD shall not expose the PMK-MA to parties other than the authorized MA.
Steve Emeott, Motorola

16. MA Key Holder Requirements (8.8.9.1) New requirements in blue
May 2007
MA Key Holder Requirements ( ) New requirements in blue
The mesh authenticator identity (MA-ID) shall be set to a MAC address of the physical entity that stores the PMK-MA and uses it to generate the PTK. That same MAC address shall be used to advertise the MA identity to MPs and to the MKD.
The MA shall provide the IEEE 802.1X Authenticator function, and its Port Access Entity shall authorize the controlled Port for communication with a peer MP only upon installation of a PTK derived with the peer MP. The PTK shall be derived from a PMK-MA received from the MKD.
The MA shall provide the IEEE Authenticator function to derive and distribute the GTK to connected MPs.
When the PMK-MA lifetime expires, the MA shall delete the PMK-MA SA and shall revoke all PTKs derived from the PMK-MA using the MLME-DELETEKEYS primitive.
The MA shall not expose the PMK-MA to other parties.
Steve Emeott, Motorola

17. Authorization of Key Holders (see details in 8.8.9.2)
May 2007
Authorization of Key Holders (see details in )
An MKD is authorized when it facilitates Initial MSA Authentication. Successful completion of authentication (e.g., 802.1X Authentication) implies the MKD is authorized to derive and distribute keys on behalf of an MP.
An MA is authorized
Using its MA-ID (MAC Address) as its identity
if the PMK-MKD SA created during the MA’s Initial Authentication (containing the MAC address) allows it
if it successfully completes the Mesh Key Holder security handshake (using the same PMK-MKD) with the MKD
Steve Emeott, Motorola

18. References 11-07/0564r1, “Initial MSA Comment Resolution”
May 2007
References
11-07/0564r1, “Initial MSA Comment Resolution”
11-07/0618r0, “Key Distribution for MSA Comment Resolution”
TGs D1.03
11-07/0023r30 (TGs Comment Spreadsheet)
Steve Emeott, Motorola