1. Protocol Coexistence Issue in MSA Subsequent Authentication 2008-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
Case A B 1 MP 2 MA 3 4

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. 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 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 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

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*
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.

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