Upgrades to MSA to support multiple MKD

1. Upgrades to MSA to support multiple MKD Date: 2008-11-11 Authors: Steve Emeott, Motorola

2. Abstract In the Mesh Security Architecture (MSA), a Mesh Key Distributor (MKD) manages and distributes pairwise master keys for individual mesh stations. This presentation recommends upgrades to MSA to better support multiple key distribution centers and to add support for simultaneous MKD key pulls prior to secure session establishment Steve Emeott, Motorola

3. Outline • Review of MSA key hierarchy • MKD Authentication • Key establishment (for neighbor MP) • Support for Multiple MKD • Proposed upgrades • State diagram showing processing and error handling • Other upgrades • Simplifications to PLM processing • Support for simultaneous key pull Steve Emeott, Motorola

4. MSA key hierarchy MSK (or PSK) • Each station manages • PMK-MKD, MKDK and MPTK-KD with a MKD station • One or more PMK-MA keys with neighbor stations • PTK with neighbor stations • Each MKD manages • PMK-MKD, MKDK, MPTK-KD for its stations • Zero or more PMK-MA (the MKD can create and delete these keys as needed) • The key hierarchy facilitates key establishment • Each station authenticates with a AAA server once per MKD • MKD generates PMK-MA upon request of it stations PMK-MKD MKDK PMK-MA PMK-MA PMK-MA PTK session keyderivation with nonces Steve Emeott, Motorola

5. AAA server MKD station Candidate mesh station MSTA MKD-STA AAA Server PLM 1 Radius Initial MSA Auth 2 4WHS MKD authentication • A station joins a mesh by • Establishing a link with a candidate neighbor • Going through MKD authentication (e.g. Initial MSA) • At the conclusion of MKD authentication the station possesses a master key (PMK-MKD) • Storage requirements for the master keys are small (one per station) • The MKD creates master keys for session establishment (PMK-MA) • Since PMK-MA is derived from the PMK-MKD, storage of PMK-MA by MKD key holder is optional • In this scenario, the MKD-STA starts the mesh 4-way handshake • It does so after it receives a key from the AAA server 1 2 Steve Emeott, Motorola

6. AAA server MKD station STA-A STA-B STA-B MKD STA-A PLM Key Est. 4WHS Key establishment for neighboring MP • A station establishes a key for use with its peer by • Establishing a link with a candidate neighbor • Comparing key lists and pulling a key for its peer from MKD if necessary • At the conclusion of key establishment both stations posses a shared key • In this case, B receives a PMK-MA derived from A’s PMK-MKD from the MKD • The station that pulled the key starts the 4-way handshake • It does so after receiving a key from the MKD station 1 2 1 2 Steve Emeott, Motorola

7. Discovery 1 PLM Successful (choose authenticator) no yes Authentication Requested yes no Initial MSA Auth Succeeded Cached Key Available no no yes no yes Key Pull Successful (from authenticator only) Key Push Successful (to authenticator only) 1 no yes yes Peer Session Establishment (4WHS) Succeeded no yes Peer Session Key establishment flow chart Steve Emeott, Motorola

8. Analysis of MSA key hierarchy • Competitive key storage requirements • MKD • One PMK-MKD per station • Zero or more PMK-MA per station • Station • A PMK-MKD for each MKD • Either a derived or a pulled PMK-MA for each secure link • Less complex than alternatives • Key pull from a key hierarchy involves two and only two parties, station requesting key and MKD delivering key • Only one form of protocol needed • With alternatives, two forms are needed, 1) for a device that relays a request through its peer and 2) for a device that contacts MKD directly (if its peer has no path to MKD) • Time taken to complete protocol generally less than more complex alternatives • Error recovery is less complex than alternatives • Station simply resends a pull after a timeout • With alternatives, complicated error recovery needed because there is more that can go wrong and because two of the parties do not share a key Steve Emeott, Motorola

9. AAA server MKD1 station MKD2 station STA-A1 STA-B2 Multiple MKD scenario • How do STA-A1 and STA-B2 establish a secure link? • Assume they have just discovered one another • Neither has a cached key for the other • They have authenticated with different MKD Steve Emeott, Motorola

10. Proposed upgrade to MSA • Upgrade proposed to MSA key selection • Improved procedure, which occurs after link establishment • After searching for a common cached key, two stations determine if they have a common MKD • If so, then at least one of the two stations pulls a key from the common MKD • If not, one of the stations authenticates with its peer’s MKD • At the conclusion of the procedure, the stations will share a common MKD Steve Emeott, Motorola

11. AAA server MKD1 station MKD2 station STA-A1 STA-B2 MS-A1 MS-B2 MKD2 AAA Server PLM Radius MKD Authentication Key Est. 4WHS Multiple MKD example • Two stations with PMK-MKD at different MKD establish a key by • Establishing a link with each other • Searching for a common MKD • If the search fails, one of the stations runs MKD authentication with its peer’s MKD • At the end of key establishment, the two stations share a common MKD and possess a shared key • The station that received the key from its MKD starts the 4-way handshake 1 2 1 2 Steve Emeott, Motorola

12. Upgraded key establishment Discovery If no then go here a PLM Successful (choose selector) no yes Authentication Requested no yes Cached Key Available no no Common MKD Available? MKD Auth Succeeded yes yes yes no no Key Pull Successful (optional for non-selector) Key Push Succeeded (selector only) a yes no Peer Session Establishment (4WHS) Succeeded yes no yes Peer Session Steve Emeott, Motorola

13. Other revisions • Simplified PLM processing • Idea: PLM performs the same processing steps whether the link instance is secured or left unsecured • If we adopt a new key establishment clause, then all key selection processing can be taken out of PLM • Added support for simultaneous key pull • If two stations share a common MP, one might get a quicker response from the MKD than the other • Proposed upgrade allows both to pull keys during key establishment (and before key selection) Steve Emeott, Motorola

14. Simplified PLM processing • Current PLM processing impacts key selection • PLM processing fills out the selected key field in peer link confirm message some times, but not others • If we allow simultaneous key pull, the PLM key selection is premature • Recommend moving key selection processing out of PLM and fully into key establishment • Greatly improves readability; much simpler • Key selection occurs entirely within key establishment; for cached keys, pulled keys or keys obtained by authenticating • All selections are verified and confirmed during session establishment; which means PLM processing is redundant anyway • Result is simplified PLM processing • PLM messages carry security information, but processing is performed by key establishment procedures • Goal should be to have PLM perform the same processing steps whether the link instance is ultimately secured or left unsecured (another simplification) Steve Emeott, Motorola

15. Simultaneous key pull • Propose modifying key selection to accommodate simultaneous key pull • New procedure involves three steps • Key selection terminates successfully if a pair of MP determine during PLM that they share a common key • If no common key is found, key establishment is invoked to determine if one or both nodes can retrieve a key from the MKD • Session establishment starts once key establishment has completed • If the non-selector node completes key pull first, it sends a kick start message to the selector node to request an instance of 4WAY be started • If the selector node completes key pull first, it starts an instance of 4WAY; the selector node is responsible for key selection decisions after key establishment • A kick start message allows the non-selector to pass the results of its key establishment activities back to the selector • An existing EAPOL-Key request message defined for RSNA may be used by the non-selector to kick-start the selector Steve Emeott, Motorola

16. start listening {protoFailure}/close_link {protoFailure}/close_link {protoFailure, timeout}/close_link {timeout}/close_link {S-MSAauth}/start_EAP {PMKdelivery}/run_4whs relay {discoverPeer}/list_keys {needKeyPull}/start_keypull {recv4WHSrequest, recv4WHSmsg1, S-PMKdelivery}/run_4whs key pull {N-PMKdelivery}/run_4whs {recv4WHSmsg1}/run_4whs {N-chosenPMK}/-- PLM Waiting 4WHS {timeout}/close_link {N-MSAauth}/-- {protoSuccess}/-- EAP Auth {protoFailure, timeout}/close_link {protoSuccess}/bind_session {S-chosenPMK}/run_4whs Secured State transition diagram & error handling S: selector MP N: non-Selector MP Steve Emeott, Motorola

17. Discussion • Proposal extends the capabilities of MSA by recommending incremental changes • Improvements include • Support for multiple key distribution centers • Support for flexible key establishment • Simultaneous key pull • Request message for accelerating key selection • Reduction to complexity of PLM processing • Impact on draft • Addition of new key establishment section • Removal of key selection from PLM processing instructions • Addition of request message for 4-way handshake • Enhancement of MSA introductory text Steve Emeott, Motorola

18. Discussion (cont.) • Advantages • Quicker access to keys from MKD • Proposal uses request and response approach for key pull, meaning fewer messages and less processing than alternatives • Less complexity than alternatives • Alternatives can involve 3 parties in key establishment, namely the MKD and two stations • A 3 party protocol may be more complex and sophisticated than the abbreviated handshake • Error recovery on a 3 party protocol likely to be considerably more complex than current approach • Fewer implementation and testing challenges • Two and only two parties are involved in both the mesh 4-way protocol and the key delivery protocols • In both cases the messages and transmitted and received in a predictable order; independent of the protocol instance state Steve Emeott, Motorola

19. Questions? Steve Emeott, Motorola

20. Backup Steve Emeott, Motorola

21. Avoiding race conditions between PLM and the Abbreviated Handshake • Recommend placing restrictions on a pair of MP after link establishment to better control session establishment • Assume that a link has been established between a pair of nodes • As part of link establishment, one of the two nodes will be chosen as a selector • A selector node is allowed to run an instance of 4WHS or ABBH for a given pair of nodes, but not both simultaneously • The non-selector node runs instances of both simultaneously, if needed • Allows non-selector to respond to 4WHS messages received from the selector even if the non-selector has initiated an ABBH instance • Under the new procedures, the selector avoids race conditions by determining which session establishment protocol runs to completion • Requests by the non-selector to kick start an instance of 4WHS are ignored by the selector if it has already started an AbbrHS instance • Only the selector may send Message #1 of the 4WHS (new restriction, which will involve a minor modification to procedure for determining the selector) • If the selector starts 4WHS and the non-selector starts AbbrHS, the selector does not respond to the AbbrHS messages Steve Emeott, Motorola

22. Reference: list of states Steve Emeott, Motorola

23. Reference: list of state machine inputs (events) Steve Emeott, Motorola

24. Reference: state machine outputs (actions) Steve Emeott, Motorola