Protocol Coexistence Issue in MSA Subsequent Authentication 2008-05-11

1. Protocol Coexistence Issue in MSA Subsequent Authentication2008-05-11 Authors:

2. Abstract • This presentation analyzes two protocol operational issues in MSA subsequent authentication procedure: • The interaction with the Key Transport Protocol is complex • Supporting both AbbrHS and “PLM4WHS” for subsequent authentication increases non-interoperetability and deployment complexity and suggests using only the Abbreviated Handshake for subsequent handshake to address these issues

3. MSA Subsequent Authentication Peer Link Establishment Key Transport Key Transport Abbreviated Security Handshake MSA 4-Way Handshake

4. Issue 1: Interaction of Handshakes and Key Transport • The interaction of the key transport protocol with the handshake protocols is complex • Current design does not appear to be robust

5. Executing Key Transport Protocol • PLE  Key Transport  MSA 4-Way Handshake • A stop-and-wait protocol, with the attendant performance issues • PLE negotiates  1 PMKs for the later MSA 4-Way Handshake • If the chosen PMK is not cached locally, one MP executes the key transport protocol to fetch the key from its MKD • MSA 4WHS is initiated if the MP successfully fetches the selected PMK

6. Operational Issues • Peer MP reaches the MKD via a multi-hop path through the mesh • This is an unreliable path • The MP can’t assume its peer MP can fetch the key successfully in time • An MP’s announcement that it maintains a security association with MKD, such announcement does not imply that the peer MP can communicate with MKD at the moment needed • Requiring one MP to wait on the other to execute key transport protocol is not a robust design • A single failure stalls the entire procedure

7. Suggested Changes to Invoke Key Transport Protocol • If “PLE  4WHS” (more details in backup) • Use PMK selection procedure to select a PMK both MPs have cached locally • If such a PMK does not exist, BOTH MPs (if they have MKDSA) shall execute key transport protocol to fetch the peer’s PMK • Note this step can happen as soon as an MP realizes there’s a need • Not necessarily to wait until PLE completes • When the MP fetches the key, initiate an MSA 4-way handshake • If “Abbreviated Handshake” • Select the PMK using the AbrevHS key negotiation procedure • If fail, BOTH MPs may execute the key transport protocol • When one of the MP completes, initiate a new AbbrHS instance

8. Issue 2: How to Select MSA 4WHS or AbbrevHS? • One MP chooses to use the MSA 4-Way Handshake for MSA Subsequent Authentication; the other chooses to use the Abbreviated Handshake • This can prevent the two MPs from communicating … Oops • Draft 2.0 is unclear how MPs make a choice in an interoperable way • When may “PLE  4WHS” be expected? When “AbbrvHS”? • How do these two procedures interact? • Is there a need to interact? • Is it correct?

9. Analysis and Examples • Suppose MP A wants to establish a secure link with MP B • MP A decides how to proceed based its context • A’s own state • A’s understanding of B’s state • Suppose, from B’s Beacon, A can tell whether B has an MKDSA • There are at least 4 cases

10. Case 1 • Case 1: Both A and B are only MPs, not MAs (neither has an MKDSA) • Since A and B only have their own PMK, they can’t share a PMK • Since neither is an MA, neither can authenticate the peer • Result: failure in establishing a secure link

11. Cases 2 and Case 3 • Case 2: A is an MP and B announces it is an MA • A will initiate the Abbreviated Handshake using its own PMK • Case 2.1: If B already has A’s PMK, the Abbreviated Handshake will succeed • However, if B does not have A’s freshest PMK, AbbrevHS may fail; fall back to Case 2.2 below • Case 2.2: If B doesn’t have A’s PMK, B can fetch A’s PMK and, when complete, initiate the Abbreviated Handshake or MSA 4WHS with A • Case 3: A announces it is an MA and B is an MP • Mirror image of Case 2, with the roles of A and B reversed

12. Case 4 • Case 4: A and B both are MA • Both should initiate AbbrHS • Because the peer MA can fetch its own PMK • Both should start key fetching simultaneously • This is helpful since the first AbbrHS may fail

13. Implications • AbbrHS works for last 3 cases (case 1 not applicable) • PLE+key fetching  4WHS seems to work for only cases 2.1, 3.1 • Slides 15-16 suggest how to achieve this option, but with a complexity cost • AbbrHS is a better system solution for cases 2.1, 3.1 • AbbrHS binds key with session, while 4WHS doesn’t: better security • Are special cases 2.1, 3.1 worth the extra complexity?

14. Co-Existence Issue • Current draft allows both protocol options • AbbrHS or PLE  MSA 4WHS • When to choose one option unspecified • Question: Can both protocols co-exist? • Our conclusion: Freedom to choose increases • non-interoperatability • implementation and deployment complexity!

15. The Choice Cases (MA) B (MP) A • One possible situation: • B initiates AbbrHS, simultaneously A initiates 4WHS • When B receives 4WHS Message 1 from A, two options • Abandon either its own AbbrHS or ignore Message 1 • Keep both; if one of completes first, abandon the other • We are concerned about co-existence issue, so let’s analyze the latter • If B keeps both, there is always a race condition • It can’t abandon 4WHS if AbbrHS drives to ESTAB first, since it doesn’t know if A has received its last Confirm message before going to ESTAB • It can’t abandon AbbrHS if it sends Message 4 before finishing AbbrHS, since it doesn’t know whether A has received Message 4 or not • Similar issue on A’s side

16. Implications • Existence of race conditions that can be avoided imply that a decision to choose one or the other is needed • If B (MP) runs AbbrHS under case 2, A has to run AbbrHS as well to avoid race condition • Alternative: no AbbrHS is allowed, both parties run PLE4WHS • Fail to provide explicit secure session binding as AbbrHS does • Vulnerability window exists • Complex protocol interaction between PLM, 4WHS, and Key Transport • Significant performance degradation (4 messages vs. 8 messages)

17. Analysis Conclusions • “PLE  authentication  4WHS” could still be used for initial key establishment • AbbrHS and “PLE4WHS” cannot co-exist • Suggestion • Use Abbreviated Handshake to support all other cases • Improve robustness by explicitly specifying interaction with key transport protocol

18. Backup Slides

19. Initiating Key Transport Protocol

20. More Details (1) • Phase 1: Peer Link Establishment • MP A and B sends candidate PMKIDs of cached PMK-MAs, in PMKID List, ordered by expiry time (the one expires last goes first) • When receiving Open frame, compare two lists • If intersection is non-empty, selected PMK=PMK in the intersect that expires last • If intersection is empty, set “selected PMK” empty, and • If at least one MP is MA and maintains MKDSA, go to phase 2 • If no MP is MA or no MP maintains MKDSA, peer link establishment fails (because the two MPs cannot be authenticated either) • When the MP establishes an unprotected link successfully • If selected PMK is not empty, selector MP (higher MAC address) initiates phase 3 • If selected PMK is empty, initiate phase 2 and set a timer to limit time to wait for ending phase 2 • Phase 2: one MP or both MPs execute key transport protocol to fetch the peer’s latest PMK-MA • This depends on MP’s situation, not decided by key selection procedure • When the MP finishes key transport protocol successfully, proceed to phase 3 • When the MP fails to fetch the key, do nothing*

21. More Details (2) • MP goes to phase 3 (MSA 4WHS) if (1) MP receives message 1 of MSA 4WHS or (2) the selected PMK is selected successfully, or (3) the MP fetches the key successfully • If the timer expires before going to phase 3, this means fetching key is not successfully at all • Since the security association is required, the MPs should tear down the link • After initiating phase 3, if MP receives M1 from peer MP, need a tie break • Higher MAC address (selector MP) has advantage • Keep the protocol initiated by selector MP • Abandon the other