Overview of Changes to Key Holder Frame Formats March 2007 doc.: IEEE 802.11-07/0437r0 March 2007 Overview of Changes to Key Holder Frame Formats Date: 2007-03-13 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@ok-brit.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>. Tony Braskich, Motorola Tony Braskich, Motorola

March 2007 doc.: IEEE 802.11-07/0437r0 March 2007 Abstract This presentation illustrates changes proposed to resolve LB93 comments, in several separate submissions. These submissions seek to resolve letter ballot comments related to mesh key holder communication defined in 8.8.3.3 of TGs D1.0. Primarily, the changes involve a redefinition of mesh action frames to simplify the definition of these functions and avoid the unnecessary consumption of IEs by TGs. Tony Braskich, Motorola Tony Braskich, Motorola

EAP Encapsulation Comments: Introduction March 2007 EAP Encapsulation Comments: Introduction An EAP Encapsulation mechanism was defined in TGs D1.0 (8.8.3.3.3) Several LB93 comments were received that prompt some changes in its implementation The method of splitting an EAP message across multiple IEs was an unnecessary complication. The specified method consumed IEs, but did not need to. In some places, the specification was unclear and had some minor errors. The message structure for EAP Transport in D1.0 is shown on the next slide. Tony Braskich, Motorola

Draft 1.0: EAP Encapsulation structure March 2007 doc.: IEEE 802.11-07/0437r0 March 2007 Draft 1.0: EAP Encapsulation structure Mesh Action frame body contents: EAP Authentication IE EAP Message IE containing EAP message fragments Category Action EAPAIE EAPMIE … Octets: 1 44 257 variable Element ID Length EAP Message Type Message Token SPA Message Fragments MIC Control MIC Octets: 1 16 6 2 MIC algorithm Reserved IE count Bit: B0 – B3 B4 – B7 B8 – B15 Element ID Length Fragment Control EAP Message Fragment Octets: 1 variable Tony Braskich, Motorola Tony Braskich, Motorola

Improved EAP Encapsulation messaging March 2007 Improved EAP Encapsulation messaging The EAP Encapsulation Mesh Action frame has been revised to eliminate the unnecessary “fragmentation” procedure for the EAP message. The new definition also does not require the use of IEs. Changes are provided in 11-07/0286r0. Tony Braskich, Motorola

Improved EAP Encapsulation message March 2007 Improved EAP Encapsulation message Category Action EAP Authentication MIC Octets: 1 Variable 16 Non-IE field defined in 7.3.1 Defined and used only for this EAP Authentication Mesh Action type. Encapsulation Type Message Token SPA EAP Message Length EAP Message Octets: 1 16 6 2 variable A MIC field is defined in 7.3.1 (a non-IE management frame component) since it is reused in other frames. The remainder is defined directly with the frame definition. No EAP message “fragmentation” is required. Tony Braskich, Motorola

Improved specification of EAP Transport protocol selection March 2007 Improved specification of EAP Transport protocol selection The EAP Encapsulation (8.8.3.3.3 in D1.0) is described as optional. However, a PICS proforma entry is needed instead of simply stating “optional” in the text. (CID 3492) The EAP Transport mechanism selection is improved to permit a “null” choice, for the case of a MKD that does not communicate with non-local MAs. These changes are provided in 11-07/0437r0. Tony Braskich, Motorola

Improved Key Holder communication March 2007 Improved Key Holder communication In addition to EAP Transport, key holders also communicate with a security association setup handshake (8.8.3.3.1) and key transport functions (8.8.3.3.2). In these specifications, we can similarly remove the unnecessary IEs to simplify the specification and avoid consuming the limited IE space. Changes are provided in 11-07/0287r0. Tony Braskich, Motorola

Improved Key Holder Security Establishment message March 2007 Improved Key Holder Security Establishment message Category Action Mesh ID IE MKDDIE Key Holder Security MIC Octets: 1 Variable 9 16 Added to explicitly distinguish messages Handshake Sequence MA-Nonce MKD-Nonce MA-ID MKD-ID Transport Type Selector Octets: 1 32 6 4 MKHSIE (7.3.2.65) removed. Fields now defined within mesh action frame definition. This action frame reuses other defined fields such as MKDDIE and MIC (non-IE). Tony Braskich, Motorola

Improved Key Transport Message (example: Push delivery) March 2007 Improved Key Transport Message (example: Push delivery) Category Action Mesh Key Transport Mesh Wrapped Key MIC Octets: 1 Variable 9 16 Replay Counter SPA PMK-MKD Name ANonce Octets: 8 6 16 32 Defined in 7.3.1 for use by several Mesh Action frames Wrapped Context Length Wrapped Context Octets: 2 variable The 5 Key Transport messages use up to 3 non-IE fields as shown above. (Mesh Wrapped Key not included in all key transport messages.) Tony Braskich, Motorola

Other changes in 11-07/0286 and 0287 Reorganize subclauses (CID 821) March 2007 Other changes in 11-07/0286 and 0287 Reorganize subclauses (CID 821) Fix choice of key wrap algorithm (CID 1413) Partially implement MIC algorithm update (to AES-128-CMAC) (CID 592, 4732.) Tony Braskich, Motorola

Additional Comment Resolution March 2007 Additional Comment Resolution Submission 11-07/0435 completes the update of the MIC algorithm based on the work begun in 0286 and 0287. Text is added to allow use of AES-128-CMAC in 4-way handshake and GTK handshake where used within EMSA. Text removes unused fields of the EMSAIE (including MIC). Submission 11-07/0436 defines MIB variables that were not defined in TGs D1.0. Tony Braskich, Motorola

Summary of Resolutions March 2007 Summary of Resolutions These 5 submissions are designed to resolve 66 comments: 11-07/0286, 11-07/0287, and 11-07/0435 together should resolve 37 comments. 11-07/0437 should resolve 4 comments 11-07/0436 should resolve 25 comments Further, these submissions may assist in resolving General-category comments related to IE consumption by TGs. Tony Braskich, Motorola

March 2007 References 802.11 TGs D1.0 11-07-0023-19-000s-lb93-tgs-draft-1-0-comment-spreadsheet 11-07/0286r0, “EMSA EAP Encapsulation Comment Resolution” 11-07/0287r0, “EMSA Key Holder Frame Formats” 11-07/0435r0, “EMSA MIC Update” 11-07/0437r0, “EAP Transport Specification comment resolution” 11-07/0436r0, “EMSA MIB definitions” Tony Braskich, Motorola

March 2007 Motion Adopt document 11-07/0286r0 to resolve 13 comments related to EMSA EAP Encapsulation. Tony Braskich, Motorola

March 2007 Motion Adopt document 11-07/0287r0 to resolve 9 comments related to EMSA Key Holder frame formats. Tony Braskich, Motorola

March 2007 Motion Adopt document 11-07/0435r0 to resolve 15 comments related to MIC algorithm update. Tony Braskich, Motorola

March 2007 Motion Adopt document 11-07/0437r0 to resolve 4 comments related to EMSA EAP Transport Specification. Tony Braskich, Motorola

March 2007 Motion Adopt document 11-07/0436r0 to resolve 25 comments related to MIB definitions. Tony Braskich, Motorola