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

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

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

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

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

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

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

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?

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 Case A B 1 MP 2 MA 3 4

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

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

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

Key fetchingAbbrHS, or Implications Case A B A’s action 1 MP failure 2 MA, no PMK for A AbbrHS MA w/ A’s PMK 3 MA, no PMK for B Key fetchingAbbrHS, or PLE  key fetching4WHS MA w/ B’s PMK AbbrHS + key fetching 4 MA 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?

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!

The Choice Cases One possible situation: (MA) A B (MP) 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

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)

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

Backup Slides

Initiating Key Transport Protocol

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* Note: This is interesting. It looks like MSA needs to choose either execute authentication or key transport protocol, but not both. In above case, the authentication is not explicitly requested. Now if the peer MP comes back with failed key fetching, it means it’s not capable to be MA for authenticating the local MP. It doesn’t make sense to try authentication after failed key transport. So, when the local MP fails to fetch the key, it should wait for the peer MP to either launch 4WHS (if the peer fetches the key successfully) or wait for timeout to declare failure.

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