150 likes | 251 Views
Summary of Updates to MSA Overview and MKD Functionality Text. Authors:. Date: 2007-07-16. Abstract.
E N D
Summary of Updates to MSA Overview and MKD Functionality Text Authors: Date: 2007-07-16 Steve Emeott, Motorola
Abstract This submission provides an overview of document 11-07/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. Steve Emeott, Motorola
Outline • Introduction to MKD Domains • Improvements to MSA overview and updates to MKD description • Summary of comments received • Overview of proposed changes Steve Emeott, Motorola
MKD1 domain MKD1 MP1 MP3 MP2 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 Steve Emeott, Motorola
Support for Multiple MKDs Mesh A MKD1 domain MKD2 domain MKD1 MKD2 • 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 MP3 MP4 MP6 MP2 MP5 Steve Emeott, Motorola
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 Steve Emeott, Motorola
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: • The MP is not a mesh authenticator. • 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. • 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). Steve Emeott, Motorola
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. Steve Emeott, Motorola
MA behavior when changing MKD domains MKD 1 MA 1 MA3 MKD 2MA 2 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. Initial MSA Authentication In MKDD 1 Key Holder Security HS Initial MSA Authentication Added by 07/2119r0. Key Holder Security HS Key Holder Security Teardown In MKDD 2 Steve Emeott, Motorola
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. Key Holder Security Teardown protocol details Either MA or MKD may initiate Requester Responder Teardown Request Teardown Response Steve Emeott, Motorola
Backup Steve Emeott, Motorola
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) Steve Emeott, Motorola
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. Steve Emeott, Motorola
MKD1 domain MKD1 MP1 MP3 MP2 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 Steve Emeott, Motorola
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 Steve Emeott, Motorola