Key Distribution for Mesh Link Security

1. Key Distribution for Mesh Link Security Date: 2008-11-06 Authors: Jesse Walker (Intel Corporation) et al

2. Abstract • This document proposes a key distribution architecture to address serious architectural problems in MSA key hierarchies • This proposal addresses additional issues: • Remove unnecessary protocols • Offload unnecessary operations in PLM • clarify the interactions between security related protocols • 33 security comments addressed: CIDs 115, 175, 176, 182, 187, 188, 209, 469, 470, 472, 475, 476, 479, 481, 485, 486, 819, 821, 822, 824, 828, 837, 839, 1069, 1070, 1071, 1072, 1073, 1074, 1261, 1262, 1747, 1066 Jesse Walker (Intel Corporation) et al

3. Agenda • Background • Establishing secure peer link • MSA Key Hierarchy problems • Proposal overview • Proposal details • Protocol decision procedure • Key distribution protocol Jesse Walker (Intel Corporation) et al

4. MSA Key Hierarchies … m MKDs MSK-MKD MSK-MKD • Each MP maintains a key hierarchy with each MKD it has authenticated with • Key hierarchy for communication both between MP-MKD and MP-MP • Key selection for peer link security – one PMK-MA out of up to 2m PMK-MAs PMK-MKD MKDK PMK-MKD MKDK PMK-MA PMK-MA PMK-MA MPTK-KD PMK-MA MPTK-KD PMK-MA PMK-MA PMK-MA PMK-MA PTK PTK Jesse Walker (Intel Corporation) et al

5. Functions for Setting Up a Secure Link Peer Discovery Peer link establishment Key establishment Session establishment • Key establishment options • Authentication: derive PMK from authentication • SAE before setting up peer link • MSA authentication after peer link establishment • Key transport: MKD delivers a PMK from the MP’s key hierarchy to its candidate peer MP • Session establishment • Use PMK to establish a secure session and render session keys • Key hierarchies offer multiple PMKs for setting up a session between two MPs • Key selection is required (can be very complicated) • Key hierarchies severely complicate key establishment and interactions with session establishment Peer link establishment Peer Discovery Key establishment Session establishment Jesse Walker (Intel Corporation) et al

6. Problems Caused by Key Hierarchy • Details in docs 11-08/483 (comment spreadsheet) and 11-08/0501 • Key hierarchy design forces gratuitous and unnecessary role determination into PLM design • Addressing the unaddressed multi-MKD issues makes problems explode • Race conditions abound!! • Per MP state explodes ~ O((# of MKDs)  (# of MPs in mesh)) • Forces peer MPs to somehow choose among multiple available PMKs during PLM • PLM negotiation and multi-MKD functionality unspecified • Adding these will increase overall complexity • Experience with prior stds: too many choices for successful interoperability • e.g., too many different protocols to establish PMK, invokable in too many different sequences • Authentication, key pulling before/after/during peer link setup, … • e.g., design does not deal with protocol failures systematically • Every implementation will recover from problems differently • Insufficient interaction between candidate peers to recover from failures • Sometimes impossible to start over, but insufficient information to know when • Due to too many choices and lack of information • Test and debug nightmare Jesse Walker (Intel Corporation) et al

7. Share the MKD? PMK may be available? no yes SAE preferred? no yes fail AbbrHS fail SAE fail PLM succeed succeed succeed AbbrHS Am I the authenticator? yes fail no succeed Have supplicant’s key? Need authentication? no yes yes no fail fail Key pulling EAP authentication Initiate AbbrHS? fail MSA 4WHS/AbbrHS succeed MSA 4WHS yes fail no succeed fail MSA 4WHS/AbbrHS AbbrHS Wait to respond to 4WHS Unspecified, suggestion: succeed timeout Protocol Decision Procedure (as per current draft) Peer discovered Single MKD announced, can’t authenticate with multiple MKDs Serious protocol synchronization issues Complicated negotiation outcome from PLM Jesse Walker (Intel Corporation) et al Session

8. What if we announced MKDs in Beacon to enable multiple MKDs? Peer discovered Could be multiple shared MKDs…Oops yes Shared an MKD? no yes SAE preferred? MKD identified? Only one...Oops no Which MKD to use for authentication? PMK available? yes no Requires MKD negotiation in PLM…Oops PLM SAE PLM no MKD decided? fail Am I the authenticator? yes AbbrHS yes no yes Have supplicant’s key? Need authentication? no EAP authentication no yes no yes Key pulling EAP authentication Initiate AbbrHS? AbbrHS 4WHS MSA 4WHS/AbbrHS succeed yes MSA 4WHS no yes AbbrHS Wait to respond to 4WHS Succeed? MSA 4WHS/AbbrHS succeed Session Jesse Walker (Intel Corporation) et al

9. Agenda • Background • Establishing secure peer link • MSA Key Hierarchy problems • Proposal overview • Details • Protocol decision procedure • Key distribution protocol Jesse Walker (Intel Corporation) et al

10. Proposal Overview • Keep the basic MSA architecture when centralized authentication used • EAP authentication • MKDs • All authenticated MPs are key holders (mesh authenticators) • EAP MSK used to create a security association (SA) between MA and the MKD • Secure peer link: Replace Key Hierarchy with Key Distribution from the MKD • MKD generates a random PMK for MP-MP pair and distributes wrapped PMK both MPs via a key distribution protocol • Reduce the number of protocol interactions • Limit options by forcing fixed decision tree to promote greater interoperability and decreased testing cost Jesse Walker (Intel Corporation) et al

11. MSK-MKD One MSK-MKD per MP MSK-MKD MSK-MKD MKD Randomly generates PMKs for MP-MP; MKD distributes PMK using MSK-MKD for respective MPs MKD MKD MSK-MKD MKD MSK-MKD Keys from EAP MSK Protect MKD-MP traffic; Enable key distribution MSK-MKD MP2 Maintain only one PMK for each MP-MP pair MSK-MKD KCK and KEK One MSK-MKD per MKD Key Distribution Proposal Overview MP1 Total SA storage cost per MP: O(m+n) m: # MKDs in mesh n: # MPs in mesh Jesse Walker (Intel Corporation) et al

12. MP1 EAP authenticates through MP2 MP2 acts as an MA MP1 pulls PMK from A through MP2 PMK from A Protected Link Protocol Interaction with a Single MKD case 1: Joining an Established Mesh MKD: A MP2 MP1 PLM Abbreviated Handshake Jesse Walker (Intel Corporation) et al

13. Protected Link Protocol Interaction with Multiple MKDs: case 2: MPs share a PMK I have THE PMK with MP2 I have THE PMK with MP1 MP1 MP2 Abbreviated Handshake Local cache is sufficient to learn whether the PMK exists Jesse Walker (Intel Corporation) et al

14. MKD: A, B, C MKD: C, B, D Protected Link Protocol Interaction with Multiple MKDs: case 3: MPs share an MKD but not a PMK MP2 MP1 PLM Simultaneous pulls OK MP1 pulls PMK from B through MP2 MP2 pulls from C through MP1 Abbreviated Handshake Simultaneous Abbr HS OK; Tie breaking decides that MP2 abandon its instance after receiving the first protected message from MP1 Jesse Walker (Intel Corporation) et al

15. MKD: A, B MKD: D Protected Link Protocol Interaction with Multiple MKDs: case 4: MPs share no MKD or PMK MP2 MP1 PLM Simultaneous authentications OK MP1 authenticate with D through MP2 MP2 authenticates with A/B (by MP1’s choice) through MP1 Simultaneous pulls OK MP1 pulls PMK from D through MP2 MP2 pulls PMK from A/B (just authenticated with) through MP1 Abbreviated Handshake Simultaneous Abbr HS OK; tie breaking decides that MP2 abandon its instance after receiving the first protected message from MP1 Jesse Walker (Intel Corporation) et al

16. Protocol Interaction with Multiple MKDsCase 5: one MP has the PMK I have NO PMK with MP1 I have THE PMK with MP2 MKD: D MP2 MP1 Abbreviated Handshake MKD: XXX PLM Reduce to case 3 or case 4 Delete the old PMK after receiving the first authenticated message from MP2 using the new PMK Jesse Walker (Intel Corporation) et al

17. Advantages • Simpler architecture with lower complexity • Only one key per MP-MP, instead of up to 2m keys • Per MP state: O(m + n) vs. O(mn) • Minimize key negotiation effort • Minimize states maintained by both MPs and MKD • Enable scalability with multiple MKDs • Each pair of MPs only maintain one PMK for communication • No MKD or key info announcement in Beacons; local cache is sufficient to determine available PMK • Minimize key info announcement in PLM • Minimize negotiation afforded by PLM • MPs only exchange available MKDs during PLM; no MKD or key negotiation is needed • Reduces complexity and removes the needs to deal with multiple key hierarchies Jesse Walker (Intel Corporation) et al

18. Advantages (cont.) • Avoid race condition in supporting multiple MKDs • Protocols support simultaneous MP-MKD relationships for each MP • Ensure system stability with dynamic MP-MKD relationships • Peer links and security associations no longer belong to any particular MKD domain • Change in MP-MKD relationships doesn’t impact on validity of peer links • Increase robustness • Simultaneous authentication and key pulling maximize chance of protocol success in mesh communication • Careful protocol interaction ensure timely failure recovery • Increase interoperability • Minimize decision choices to reduce possible protocol sequences and potential race conditions • Reduce testing and debugging cost • Reduce efforts to deal with protocol synchronizations Jesse Walker (Intel Corporation) et al

19. Discussion • “Extra” key pulling instance after every EAP authentication? • This design in fact doubles the reliability of key delivery over the mesh • Not a major performance problem; if key pulling has latency issue, then authentication has more severe issue • Key pulling has to happen after PLM • Key pulling is required to go through the peer MP to ensure consistent views of protocol execution by both MPs; PLM enables a link for authentication and key pulling • Increase reliability: well-defined protocol synchronization points: • Either both succeed or both fail • No need to guess what the other peer is doing • Latency matters: from peer discovery to secure session established • This proposal in fact shortens the latency in the error recovery Jesse Walker (Intel Corporation) et al

20. Agenda • Background • Establishing secure peer link • MSA Key Hierarchy problems • Proposal overview • Details • Protocol decision procedure • Key distribution protocol Jesse Walker (Intel Corporation) et al

21. 6 3 4 2 1 7 5 Peer Discovery Do I share PMK with Peer? SAE or EAP? SAE Succeeds? PLM Succeeds? Do I share MKD with Peer? EAP Succeeds? Abbrev HS Succeeds? Key Pulling Succeeds? Session MP Decision Procedure for Key Distribution Proposal No Yes EAP SAE No Yes Yes No No Yes Yes No Yes Yes No No * Failure case analysis in backups Jesse Walker (Intel Corporation) et al

22. Key Distribution Protocol (1) • Requirements • MP1 and MP2 each has established a key for key wrapping and encryption algorithm with MKD • Messages should involve all three parties (MP1, MP2, and MKD) • Critical for failure recovery and robust protocol interaction • All parties have good random number generator • Proposal based on 3PKD • Defined in Bellare and Rogaway, “Provably Secure Session Key Distribution – the Three Party Case,” Proceedings of 27th ACM Symposium on Theory of Computing, May 1995 • Definitions and proofs in the computational complexity model • The Bellare-Rogaway proof is flawed, but Charles Rackoff fixed it Jesse Walker (Intel Corporation) et al

23. Key Distribution Protocol (2) • Uses SIV using AES for key wrapping (RFC5297) • Deterministic authenticated-encryption is a provable-security treatment of the key wrapping problem • Provide encryption and integrity protection simultaneously • Wrapped component is encrypted and integrity protected • “Associated data” is integrity protected • Notation • A, B, and C are “associated data”, D is the wrapped key, k is the key used for encryption and integrity protection: blob = [ A, B, C, {D} ]k • Kxy is a key shared between parties whose identities are x and y. Jesse Walker (Intel Corporation) et al

24. Key Distribution Protocol at a Glance IDMP1, IDMP2 , IDMKD,a IDMP1, IDMP2 , IDMKD,g 2 MP2 1 MP1 Generates R2 IDMP1, IDMP2 , IDMKD,g , d Generates R1 Computes b [ IDMP1, IDMP2, IDMKD, {R2}] KMP2-MKD IDMP1, IDMP2 , IDMKD,a, b Computes a [ IDMP1, IDMP2, IDMKD, {R1}] KMP1-MKD 5 Verifies g Unwraps PMK 4 Verifies d Unwraps PMK 3 Verifies integrity of a and b Unwraps random numbers Generates PMK Decides lifetime Computeg  [IDMP1, IDMP2, IDMKD, R1, {PMK || lifetime} ]KMP1-MKD(ticket for MP1) d  [IDMP1, IDMP2, IDMKD, R2, {PMK || lifetime} ]KMP2-MKD(ticket for MP2) MKD Jesse Walker (Intel Corporation) et al

25. Key Distribution Protocol Discussion • A modified version of 3PKD • R1 and R2 are associated with the wrapped key • Distinguish from completely random garbage • Prevent cut-and-paste attacks on wrapped key • IDMP1 , IDMP2 , and IDMKDare integrity protected in all messages • Bind all parties to the exchange • Prevent identity mis-binding attacks. • R1 and R2 are wrapped in message 1 and 2 • Encryption is not strictly necessary but it has a side-benefit • Add IDMKD to provide context of message exchange • None of above changes affects security Jesse Walker (Intel Corporation) et al

26. Impact to Current Draft • Add text for • PMK generation • Key pulling protocol • Protocol interaction explanation • PLM update to support MKD list announcement • Remove text for • PMK-MA key derivation • Role determination and key determination in PLM • Key holder handshake protocol (update key derivation for MPTK-KD) • MSA 4WHS • Key transport protocols (or update to key pulling protocol) Jesse Walker (Intel Corporation) et al

27. Next Steps • Further strengthen the proposal • Detailed analysis • Solicit input • Bring normative text in January Jesse Walker (Intel Corporation) et al

28. Strawpoll • “Are you in favor of pursuing key distribution to replace MSA key hierarchy for secure link establishment?” Yes: No: Don’t know: I don’t care: Jesse Walker (Intel Corporation) et al

29. Backup Slides Jesse Walker (Intel Corporation) et al

30. Key Distribution Protocol Discussion • Issues under consideration • Move the ticket for MP1 into the ticket for MP2 • For integrity protection of message 2 • Need further analysis, weigh options • Communication considerations • Design new frame for message 1 & 4 • Update mesh action frame for message 2 & 3 • Need mechanism to deal with retries • Careful analysis and specification on interaction with Abbreviated Handshake under both normal case and failure recoveries Jesse Walker (Intel Corporation) et al

31. Implication of Retries during Key Distribution • Retransmission of the message from MP2 to the MKD must be allowed since MKD’s response may not be received by MP2. This has implications: • A certain amount of state must be maintained by the MKD– “when I got R1 and R2 I generated PMK and if I get R1 and R2 again I’ll send PMK back as a response”. • PMK is generated deterministically using R1 and R2 (and, for instance KMP1-MKD and KMP2-MKD). • MP2 must retain a and g until conclusion of the Abbreviated Handshake to deal with retransmissions from MP1. • Authenticated counters could be added to the first two messages to address replay but the cost may not be worth the benefit. Jesse Walker (Intel Corporation) et al

32. Failure Condition Resolution for Intel Proposal • No, I don’t share a PMK with Peer • I don’t have a PMK for this Peer, but the peer has a PMK for me • I start PLM or SAE, peer starts Abbreviated HS • I do not respond to Abbreviated HS messages • If SAE/PLM+EAP finishes before peer’s Abbreviated HS instance times out, then no conflict • If SAE/PLM+EAP finishes after peer’s Abbreviated HS instance times out, then no conflict either • The Peer and I may share different PMKs • We both start Abbreviated HS but cannot agree on a key • Abbreviated HS terminates without establishing a session Jesse Walker (Intel Corporation) et al

33. Failure Condition Resolution for Key Distribution Proposal • No, SAE did not succeed • SAE may succeed for one peer but not the other • SAE  Abbreviated HS: the peer that succeeds will time out and close the Abbreviated HS link • The SAE state machine must be able to receive new SAE requests even if a protected link is established, an Abbreviated HS instance is in progress, etc. • No, PLM did not succeed… • …due to parameter mismatch • Can’t communicate any way due to policy; restart discovery • …due to timeout • Can’t communicate due to link failure; restart discovery Jesse Walker (Intel Corporation) et al

34. Failure Condition Resolution for Key Distribution proposal • No, I don’t share an MKD with Peer • If both MPs have acquired an MKD… • …the simplest solution is for both to authenticate via the other • Each also does a key pull, and the MPs use the PMK of which ever completes first or that of the higher MAC address if both complete at the same time • If only one MP has acquired an MKD… • …the other authenticates, as per current spec • MPs use the newly distributed PMK after a key pull • A short conversation if neither MP has acquired an MKD Jesse Walker (Intel Corporation) et al

35. Failure Condition Resolution for Key Distribution proposal • No, Key pulling failed • If no simultaneous key pulling by the candidate peer MP • End the link and find a new peer • If simultaneous key pulling instance/authentication is in process • Keep the link for the other key pulling or authentication instance • Both MPs have the same view of the failure, because both involved in key pull Jesse Walker (Intel Corporation) et al

36. Failure Condition Resolution for Key Distribution Proposal • No, EAP authentication failed • Due to authentication failure • Policy says don’t talk with peer; tear down link and restart discovery • This is interesting…what about the other authentication instance? Since the same AS is behind all MKDs, the other authentication should also fail, no matter which MKD it is talking to • Due to timeout • Can’t communicate any way due to path failure; communication via this peer is not reliable; restart discovery • Meanwhile, keep the link instance if simultaneous authentication/key pulling is in process • No, the Abbreviated HS failed • Because of a parameter mismatch • Can’t communicate any way due to policy; restart discovery • Because of a key mismatch • Protocol error; restart discovery • Because of timeout • Can’t communicate any way because of link failure or peer can’t respond; restart discovery Jesse Walker (Intel Corporation) et al

37. Comparison (1) • The key distribution proposal requires MPs to maintain only one PMK for each MP-MP pair • Simplifies decision making • Reduces implementation, interoperability testing, and debugging cost • Reliable key distribution requires all 3 parties involved • Same view on failure scenario; so easier to diagnosis and start over • The key distribution proposal requires that every MP is mesh authenticator by default, once join the mesh • The MSA MKD architecture already accommodates this • This design maximize the adaptability to different deployment scenarios • Draft requires key holder handshake to enable mesh authenticator • Target at hierarchically managed mesh only • Draft requires PLM to be modified to negotiate which MKD to use if more than one established by the MPs • MPs don’t care whether there are multiple MKDs, and which of the peer’s MKDs they use with the Intel proposal • In key hierarchy design, the protocol interaction is further complicated by the requirement that there could be multiple MKDs Jesse Walker (Intel Corporation) et al

38. Comparison (2) • The key distribution does not need to advertise any MKDs in the Beacon • MP decides whether it has the key from local cache, indexed by peer’s MAC address • Draft requires that an MA advertise its MKD in its Beacons, driven by the key hierarchy design • Problem: this does not scale to multiple MKDs, but reliability and fail-over demand multiple MKDs • Execute AbbrHS to tightly bind peer link with SA • Eliminate the vulnerability window introduced by “PLM+4WHS” • 8 decisions for the key distribution roposal; draft requires 18 • Draft has more situations where interoperability problems can result because different nodes make different decisions Jesse Walker (Intel Corporation) et al

39. Solve Multi-MKD Problem • Simplifies multi-MKD problem • Encode MKDD-ID in PMK-ID • Secure session setup uses the only shared PMK, which clearly belong to the same MKD • Enable authentication with multiple MKDs • If MPs don’t share a key, they each authenticate with the peer’s favorite MKD then pull a key • 3-party protocol guarantees the same view of key pulling • A tie-breaking can be used to deal with simultaneous finishing • Enable simultaneous key pulling • Allow every MP to become an MKD Jesse Walker (Intel Corporation) et al

40. PLM Prepares for 4WHS • “PLM + 4WHS”  “PLM + AbbrHS” from protocol interaction perspective • PLM + 4WHS • PLM negotiates who is authenticator and who is supplicant for 4WHS, hence which PMK-MA to be used • PLM decides whether the PMK-MA is shared • If not, PLM negotiates whether to execute Initial MSA authentication or key pulling • Initiate MSA authentication is executed only when one of MP explicitly request so • For the rest of the cases, only one MP (acting like an MA) to execute key pulling to get PMK-MA from the supplicant’s key hierarchy • With multiple MKDs, the above negotiation steps soon blow up • Negotiation of MKD is not and should be specified Jesse Walker (Intel Corporation) et al

41. PLM Prepares for AbbrHS • None; AbbrHS uses its own negotiation mechanisms • Key hierarchy introduces additional difficulty to AbbrHS • Require efficient and effective key negotiation • Key hierarchies introduce too many choices • Possible two shared keys from each MKD domain • Some are/are not available for each peer MP • Both/one/neither has KCK/KEK with MKD • Both/one/neither has connectivity with MKD • Approach taken: best effort • Initiate AbbrHS whenever the MP sees possible shared key • Meanwhile, both MPs start key pulling to get their next best choice • AbbrHS may fail due to • incorrect immature key choice • lack of common key • Timeout: the peer MP chooses not to respond or to start PLM/SAE instead • In the first two cases, starting over usually works Jesse Walker (Intel Corporation) et al

42. Key Distribution Simplifies PLM and AbbrHS • Key hierarchies require key negotiation during PLM and AbbrHS • PLM negotiates • Who can reach MKD • Who has what keys and which key to be used • What protocol to execute next • Who should go fetch the PMK-MA • AbbrHS negotiates which key to be used • Prioritizing the keys using life time has synchronization problem • Key distribution eliminate many negotiation steps • PLM negotiates nothing; only announces MKD list • AbbrHS no longer negotiates the shared PMK, because there is only one key, even in the multi-MKD case. Jesse Walker (Intel Corporation) et al

43. Protocol Choices for Session Establishment • Abbreviated Handshake can be invoked in all cases • 4WHS assumes existing peer link • Performance implication: more message exchange • Security implication: vulnerability window between PLM and 4WHS • Allowing choices of different protocols as implied in draft (shown in the flowchart) introduces non-interoperatability (see document 11-08/502) Jesse Walker (Intel Corporation) et al

44. Proposal Discussion • Protocol sequences all end with Abbreviated Handshake • Enable consistent view of protocol state • No need to choose between AbbrHS vs. 4WHS; avoid race condition; reduce implementation and testing complexity • For PLM + (authentication) + key pulling + AbbrHS” sequence, PLM is used only for the purpose of establishing a link for the two MPs to authenticate or key pulling • When security is enabled, an unsecure link only allow traffic of authentication or key pulling • Therefore, frames for .1X authentication and key pulling are public frames and should provide their own protection mechanisms • Once the link and session is established using AbbrHS, the link by PLM will be abandoned Jesse Walker (Intel Corporation) et al