doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 1 Summary of Updates to MSA Overview and MKD Functionality Text Date: Authors:

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 2 Abstract This submission provides an overview of document /2119r0, which revises the introductory text to the MSA architecture and expands the discussion of key holder organization. 19 comments are addressed by the proposed changes.

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 3 Outline Introduction to MKD Domains Improvements to MSA overview and updates to MKD description –Summary of comments received –Overview of proposed changes

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 4 Introduction to MKD Domains Mesh key holder functions –Mesh Key Distributor (MKD) May serve as a AAA client on behalf of candidate peer MP joining the mesh Creates a mesh key hierarchy for a MP joining mesh and distributes derived keys –Mesh Authenticator (MA) Takes delivery of derived keys Interacts with candidate peer MPs to generate session keys MKD domain –Consists of MKD and all MA with security association to MKD –The MKD may distribute derived keys to any MA within its domain MKD1 domain MP1 MKD1 MP3 MP2

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 5 Mesh A MKD2 domainMKD1 domain Support for Multiple MKDs The draft supports one or more MKDs to operate in a mesh In the example above, the mesh is partitioned into 2 MKD domains An MP can establish secure links with MPs in the same or nearby domains However, the text may not be explicit enough about details of interaction between MKD domains MP1 MKD1MKD2 MP4 MP3 MP2 MP6 MP5

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 6 Comments Received Introduction to MSA authentication mechanism and overview of mesh security services needs more details Move introductory text closer to protocol description Multiple MKDs in a mesh would be beneficial, but text does not clearly allow this configuration MKD-to-AS communication properties not specified Clarify motivation and use for “Mesh Authenticator” and “Connected to MKD” bits

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 7 Overview of Changes Revised introductory text describing mesh key holders (11A.4.1.1) –A mesh contains 1 or more MKDs –An MA maintains connection to no more than 1 MKD –Properties of AS to MKD communication made explicit Revised description (11A.4.1.2) of “Mesh Authenticator” and “Connected to MKD” bits, which indicate one of 3 states: 1.The MP is not a mesh authenticator. 2.The MP is a mesh authenticator but does not have a connection to the MKD. The MP has one or more valid, cached PMK-MAs that may be used to establish a secure peer link. 3.The MP is a mesh authenticator and currently has a connection to the MKD. Consolidated and revised portions of 11A.4.1 for conformance with changes to MSA authentication mechanism (11-07/0564r2).

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 8 Overview of Changes (cont.) Moved introduction of MSA authentication mechanism to the section dealing with that protocol (11A.4.2.1). Generalized introduction of key holder protocols, and expanded requirements of those protocols (11A.4.1.4). Created Key Holder Security Teardown protocol (11A.4.3.4) –Two-message exchange permits tear-down of a key holder session between MA & MKD (established using Mesh Key Holder Security Handshake). –MA initiates protocol to delete an old SA after establishing a key holder session with a “new” MKD.

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 9 MA behavior when changing MKD domains After the Key Holder Security Teardown, MA3 has a secure peer link with both MA1 and MA2, but it only has a key holder session with MKD2. MA3 MKD 1 MA 1 MKD 2 MA 2 Key Holder Security HS Initial MSA Authentication Key Holder Security Teardown In MKDD 1 Added by 07/2119r0. Key Holder Security HS Initial MSA Authentication In MKDD 2

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 10 Key Holder Security Teardown protocol details The Key Holder Security Teardown protocol permits the MA to delete a prior key holder session, when joining a new MKD domain. The protocol may also be used by an MKD if it must stop its services as an MKD to one or more MAs. RequesterResponder Teardown Request Teardown Response Either MA or MKD may initiate

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 11 Backup

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 12 Review of Recent Changes to MSA Highlights of improvements already made to MSA –Improvements to PLM (11-07/0440r0: 106 comments) –Definition of MIB variables for MSA (11-07/0436r1: 25 comments) –Simplification of frame formats for key holder messages (11-07/0286r0: & 11-07/0287r1: 35 comments) –Addition of AES-128-MAC MIC algorithm (11-07/0435r1: 4 comments) –Upgrades to better support co-located MKD/MA (11-07/0437r1: 3 comments) –Integration of PLM into MSA authentication handshake (11-07/0564r2: 16 comments) –Clean up of key derivation clause (11-07/0618r0: 21 comments)

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 13 Work in Progress Areas where submissions are prepared to address comments* –Key holder communications – document 11-07/1987r1 (20 comments) –Pre-shared keys clarification – document 11-07/2037r0 (7 comments) –MSA overview and MKD description – document 11-07/2119r0 (19 comments) –Abbreviated handshake (5 comments) Resolutions to remaining comments (51) are still under discussion. *Open comments (102) in “Security” category.

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 14 Key Management within an MKD Domain When securing a mesh using 802.1X and EAP –One MP per domain (the MKD) takes delivery of keys from the AAA server for candidate peer MP –Only the MP receiving keys needs to support secure communication between itself and a AAA server When securing a mesh using mesh pre-shared keys –One MP per domain (the MKD) is configured to hold a shared key for every candidate peer MP –No matter how large the domain, every other MP only needs be configured to know its own key MKD1 domain MP1 MKD1 MP3 MP2

doc.: IEEE /2179r0 Submission July 2007 Steve Emeott, MotorolaSlide 15 Benefits of MKD Key Management Potentially simplifies network management –Smaller number of devices per mesh need to be configured to know AAA server location and AAA client secret End user devices need not be configured to know anything about AAA server to authenticate candidate peer MP –Isolates end user MP from details of how AAA servers are deployed and managed within an “infrastructure” access network Reduces number of EAP exchanges –After the initial MSA authentication, MP can establish secure links with candidate peer MP without calling on the AAA server –Reduces total elapsed time between first MSA authentication and MSA authentication with multiple candidate peer MP in a domain