1. MSA Key Hierarchy Analysis and Alternatives
May 2008
MSA Key Hierarchy Analysis and Alternatives
Date:
Authors:

2. May 2008
Abstract
This document analyzes the architectural issues of MSA key hierarchy and suggests alternatives that may radically simplify the architecture that supports security of peer links in mesh

3. Agenda Background Summary of analysis MSA operation analysis
May 2008
Agenda
Background
Summary of analysis
MSA operation analysis
Function 1: one key hierarchy per MP
Function 2: multiple key hierarchies per MP with single MKD
Function 3: multiple MKDs
Key hierarchy operation dilemma
Alternatives

4. MSA Authentication Use initial authentication to
May 2008
MSA Authentication
Use initial authentication to
Authenticate MP
Create key hierarchy through MKD
Establish first secure peer link with its authenticator MP
Used PMK: from the MP’s key hierarchy
Use subsequent authentication to
Establish subsequent secure peer links with other MPs
Used PMKs: either from the MP’s key hierarchy or other MPs’ key hierarchies
Important assumption: these keys exist and are available for each pair of MPs

5. MSA Key Hierarchy … Support MKD SA Support SA between MPs MSK or PSK
May 2008
MSA Key Hierarchy
MSK or PSK
PMK-MKD
MKDK
PMK-MA
PMK-MA
MPTK-MKD …
Support MKD SA
PTK
PTK
Support SA between MPs

6. Binding of Key Hierarchies
May 2008
Binding of Key Hierarchies
Each key hierarchy bound to specific MP and specific MKD
This binding seems to work for MKD-SA
MKD-SA is bound to each MP-MKD pair as authenticated communication channel
Implications to MP-MP pairs
Normally each MP pair has two PMKs to secure communications between them
The MPs must select one of the two PMKs to form a secure link
Each MP must possess the PMK selected to complete the Abbreviated Handshake or MSA 4-Way Handshake

7. May 2008
Analysis Summary
An i/r/EAP-like key hierarchy appears to be very far from optimal in a mesh
Using a key hierarchy appears to interact negatively with the decentralized structure of a mesh and greatly increase system complexity
Dubious compatibility with need for multiple MKDs
Dubious compatibility with the need to reauthenticate to heal partitions
Most of the problems can be eliminated by replacing PMK derivation with PMK distribution
Break the dependency of PMKs on authentication
MKDs to generate random keys as PMKs and distribute them to MPs
Key hierarchy only for MKD-SAs
Consider adding an MKD-MKD trust relationship

8. Function 1: One hierarchy per MP
May 2008
Function 1: One hierarchy per MP

9. Enable Security Handshake Between MPs
May 2008
Enable Security Handshake Between MPs
MP 1
MP 2
Protocol
Notes
Case 1 MP
Failure
No cached key available
No key holder
Case 2
MP/MKD
Initial authn
MP2’s key hierarchy is always redundant
Case 3 MA
MP2’s PMK is not used, since MP1 doesn’t have access to it
Case 4
Subseq authn
Two PMKs always play in establishing link between MP1 and MP2
Successful handshake depends on
Available key hierarchies and cached keys, and
Connection to MKD
Case 2 and case 3 are client/server case—no surprise
Key hierarchies cause protocol complexities in case 4

10. Both MPs have a path to the same MKD
May 2008
Case 4
Both MPs have a path to the same MKD
MP1
MKD
MP2
Both PMKs always play in establishing a link in this scenario
MP1 must offer to use MP2’s PMK, because it cannot know MP2 can fetch its own
Similarly MP2 must offer to use MP1’s PMK
Rules that give preference to one MP’s PMK over another do not appear to work
MP2, e.g., may discover MKD is no longer reachable while fetching MP1’s PMK, impacting performance
* Note: see backup slides for detailed case 4 analysis

11. Function 2: Multiple key hierarchies per MP
May 2008
Function 2: Multiple key hierarchies per MP
Caused by Re-authentication with the same MKD

12. Implication of Re-authentication
May 2008
Implication of Re-authentication
If an MP reauthenticates, this creates a new key hierarchy for the MP
Two options: use both key hierarchies, or delete one
Surprise: Deleting the old key hierarchy is a wrong choice
Surprise: Continuing to use both hierarchies is also the wrong choice
Summary: Binding per-link keys to the authentication creates a dilemma
Authentication pulls one direction (create a new key hierarchy)
Existing links and caches pull the other (keep the existing PMKs)
Heuristic: When no design choices are good, usually we need to rethink aspects of the architecture related to the choices

13. Implications of Deleting Older Key Hierarchy
May 2008
Implications of Deleting Older Key Hierarchy
MSK or PSK
PMK-MKD
MKDK
Must delete keys on the old key hierarchy
It must delete all PMKs
It must delete all KCKs, KEKs, and TKs
Must tear down security associations and peer links
Terminate all links protected by deleted TKs
For former peers to re-establish secure peer links
They must get PMK from the MP’s new key hierarchy
If former peer reached MKD only through this MP, it has to re-authenticate to recover
Offering the “wrong” PMK degrades link establishment performance
Surprise: Deleting old hierarchy causes egregious performance and network stability problems
Root cause: All the keys are related and bound together!
PMK-MA
PMK-MA
MPTK-MKD …
PTK
PTK

14. Implications of NOT Deleting Older Key Hierarchy
May 2008
Implications of NOT Deleting Older Key Hierarchy
If MP1 does not delete its old key hierarchy, then
Complicates secure link establishment
Case 4 requires multiple pairs of PMKs from different key hierarchies (one for each authentication)
Surprise: Not deleting old PMK bloats memory
One MKD SA per MDK + one PMK per MKD for each peer in the mesh
Although “lazy evaluation” can minimize storage cost of each key hierarchy: cache and derive only keys for neighbors met thus far

15. May 2008
Discussion
Possibly we could avoid some of these issues by requiring the MKD to push PMKs after authentication
But this results in worse memory bloat than fetching PMKs as needed
This creates huge network burden as many PMK-SAs are transferred over the mesh
A PMK-SA will be pushed to n – 1 MPs of an n MP mesh
Under the push model, every MP has to cache PMK-SAs for MPs that will never be neighbors

16. Function 3: Supporting Multiple MKDs
May 2008
Function 3: Supporting Multiple MKDs

17. May 2008
Multiple MKDs
Multiple MKDs needed for availability when the mesh partitions
But, each PMK is bound to an MKD 
Communication possible only between MPs that share the same MKD
Create disjoint MKD domains
When completing handshake with a new MKD, the MP has two options:
Either keep both MKD-SAs
Or delete the old MKD-SA
MSA specification intends to delete the old MKD-SA

18. Two MKDs do NOT have a trust relation (MSA spec doesn’t define one)
May 2008
Case 5
Two MKDs do NOT have a trust relation (MSA spec doesn’t define one)
MKD1
MP1
MP2
MKD2
MPs’ handshake request has to include MKDD-ID with the PMKID
An MP can attempt to fetch the peer’s PMK only if it has established an MKD SA with the peer’s MKD
If it has an MKD SA with the peer’s MKD, it must attempt to fetch the peer’s PMK
If PMK fetch fails or MKD SA doesn’t exist, MP must authenticate with the peer’s MKD (Case 3) to establish communication
Since it does not know the peer can authenticate with its own

19. Drop old MKD-SA after authentication
May 2008
Case 5a
Drop old MKD-SA after authentication
MKD1
MP1
MP2
MKD2
Both MPs must (re)-authenticate with the peer’s MKD (Case 3)
Each MP must also offer its own PMK for handshake in case its peer completes authentication but it cannot (Case 4)
In case 3, if MP1 authentication finished 1st, MP2 uses only MP1’s PMK
Similarly, MP2’s PMK from MKD1 is used if MP2’s authentication finishes 1st
Surprise: Trouble if both authentications complete simultaneously
MP1 now has an MKD SA with MKD2, so per spec must delete its MKD SA with MKD1; similarly for MP2
Now MP1 and MP2 don’t share MKD  can’t establish link!
More details in analysis of simultaneous operations and their interactions:
MP1’s authentication with MKD2 may not necessarily go through MP2, and vise versa.
This means both MPs need to be prepared that the peer may completes authentication first and offer the keys
There’s also a chance the MP cannot complete authentication with the new MKD.
Hence, MP1 should start AbbrHS for this case, and vise versa
Similarly, once MP1 completes authentication, it should start to offer its own PMK with the new MKD while trying to fetch the peer’s PMK (case 4)
This is useful to reduce the time gap for surprise 6 to happen.
Because of this, MP1 and MP2 should both try to fetch the peer’s PMK from the current MKD while attempting to authenticate with the new MKD.
This requirement of simultaneous operations (authentication, abbrHS, and key transport) is similar to case 4b and case 4c, with one exception:
In case 4, when abbrHS completes first, the MP can allow the key transport complete.
In case 5, when abbrHS completes, the MP should kill the authentication with the new MKD; and if the authentication completes first, the MP should kill any operation regarding the old MKD (abbrHS and key transport)

20. What if we temporarily “relax” the “delete old MKD SA” rule?
May 2008
Case 5a (Continued)
What if we temporarily “relax” the “delete old MKD SA” rule?
MKD1
MP1
MP3
MP4
MKD2
MP5
MP2
Surprise: Trouble even without simultaneous authentication completions: a stable topology can be impossible under the rule to delete old MKD SA after establishing a new one
Need to delete keys from old MKD, since they can’t be revoked
Stability is topology-dependent under the “delete old” rule
Root problem cause: All the keys are related and bound together with an MKD

21. Both MPs keep both MKD-SAs works better
May 2008
Case 5b
Both MPs keep both MKD-SAs works better
MKD1
MP1
MP2
MKD2
Both MPs must attempt to authenticate with the peer’s MKD (Case 3)
In case 3 if MP1’s authentication finishes first, MP2 uses PMK for MP1
Similarly, MP2’s PMK from MKD1 is used if MP2’s authentication finishes first
If simultaneously complete, similar to case 4
But requires double key storage over single MKD model; 4 keys available for handshake
If neither completes authentication, no communication

22. May 2008
Case 5b (Continued)
Surprise: The assumption that peer MPs can absolutely order PMKs by expiry time is no longer valid with multiple MKDs
PMKs from authentications that complete at different MKDs within a round trip delay from either MP cannot be totally ordered
The Abbreviated Handshake key resolution mechanism has to be re-designed

23. May 2008
Analysis Conclusions
Multiple MKDs a good (and necessary) idea to handle network partitions
Key hierarchies from a single MKD are too fragile and inflexible for mesh
Key hierarchies from multiple authentications and MKDs are architectural, operational, and management nightmare
Key hierarchies cached at many places, but they are seldom used
Deleting keys disrupts network connectivity
Keeping PMKs burdens both MPs and MKDs
Keeping multiple key hierarchies can lead to unstable mesh topology
Surprise Conclusion: i/r-like key hierarchies for PMKs key management appear undesirable for meshes

24. Recommendations Continue to support multiple MKDs
May 2008
Recommendations
Continue to support multiple MKDs
But do not require deletion of old MKD SA on establishing a new one
Continue to support MSA authentication and MKD SA
Key distribution: decouple PMK-MAs from key hierarchy
MKD generates random PMKs for each MP pair
MKD distributes random PMKs to each MP
Keep MKDK derivation to establish MKD SAs
Use the MKD SA to secure key distribution
Add MKD-MKD trust relationship and supporting protocols
Merge disjoint MKD domains to one “virtual” MKD domain
May also facilitate key distribution
MSK or PSK
PMK-MKD
MKDK
PMK-MA
PMK-MA
MPTK-MKD …
PTK
PTK

25. PMK Distribution Random keys are independent
May 2008
PMK Distribution
Random keys are independent
Valid until expiration time
Re-authentication with MKD doesn’t affect PMKs’ validity
Authenticating with a new MKD has no impact on existing PMKs
Maintain communication stability
PMK is generated only upon request by an MP
Existing PMKs are all used by MP pairs for secure communication
Each MP pair only share one PMK, not two
Dramatically simplify key negotiation for handshake
Much better memory scaling
Memory burden comes from the security associations with the keys
Let k = # MKD SAs, n = # MPs
MSA: each MP maintains at least 2k(n – 1) PMKs + k MKD SAs
Suggested: each MP maintains at most n – 1 PMKs + k MKD SAs
Suggested mechanism: a Kerberos-like protocol
2k(n – 1) instead of k(n – 1), because each MP must cache its peer’s PMK as well as its own

26. MKD-MKD Trust Relationship
May 2008
MKD-MKD Trust Relationship
Allow MKDs to form a “virtual MKD domain” for MPs
An MP can authenticate with one MKD once and then work with other MKDs without re-authentication
Example: MKD2 considers all MPs authenticated with MKD1 also to be authenticated
Will often obviate the need for an MP to form multiple MKD SAs
MKD-MKD trust relationship could be established by extending the MKD SA
e.g., perhaps redefine the MKD SA as an MKD-MKD-SA when both ends are active MKDs
MKD-MKD-MP protocol to “proxy” and complete key distribution also useful
MP1 and MP2 could share only one PMK, not two from each of their MKDs

27. Case 5b: Suggested Addition
May 2008
Case 5b: Suggested Addition
Both MPs keep both MKD-SAs, and
construct trust relationship between MKDs
MKD1
MP1
MP2
MKD2
Both MPs attempt to authenticate with the peer’s MKD (Case 5b)
If Case 5b succeeds, MKD1 and MKD2 could form a trust relationship with each other if one doesn’t already exist
Because a path via MP1 and MP2 exists between them

28. Suggested Case 6 May 2008 Both MPs have MKD-SAs with their own MKDs.
The MKDs have a trust relation
MKD1
MP1
MP2
MKD2
MPs’ initial handshake request has to include MKDD-ID with the PMKID
Both MPs need help from their MKDs to fetch the peer’s PMK
MP1 contacts MKD1 to fetch MP2’s PMK from MKD2
MP2 contacts MKD2 to fetch MP1’s PMK from MKD1
PMKs from both MKDs always in play for establishing a link (Case 4)
With help of “proxy” function between MKDs, MP1 and MP2 could only share a single PMK

29. Recommendation Analysis
May 2008
Recommendation Analysis
No change required in cases 1, 2, 3, or 6
No change required in case 5, because MKDs don’t have a trust relationship, so MPs must authenticate to other MKD
However, now case 5 works properly, because no need to delete “old” MKD SA
Change in case 4
Key transport request triggers MKD to generate a PMK for the MP pair if it hasn’t done so
Then MKD distributes the key to both MP1 and MP2

30. Case 4 Example May 2008 Both MPs share same MKD MKD MP1 MP2
Randomly generate PMK, PMKID
 = encrypted key ticket for MP1
 = encrypted key ticket for MP2
MP2 || MP1 || R1 || R2
KCK-2,KEK-2
[R2 || [R1 || ]KCK-1 || ]KCK-2
KCK-1,KEK-1
MP2 || MP1 || R1
MP1
MP2
[R1 || ]KCK-1
This is only an example; other approaches to PMK distribution will also work

31. Summary Keep the basic MSA architecture intact
May 2008
Summary
Keep the basic MSA architecture intact
MKDs and MKD SAs for managing MPs
Key hierarchy for PMKs appears to be too inflexible for a mesh
Create key management dilemma
Aggressively deleting old key hierarchies causes link instability
Keeping key hierarchies causes memory bloating and excessive network overhead
We suggest replace PMK derivation with PMK distribution for PMKs
Manage PMKs and TKs independently from the MP’s authentication
Minimize number of keys for management
Radically simplify the architecture
Plan to bring normative text in July/September

32. May 2008
Backup Slides

33. Case 4a Further actions depend on completion of key fetch operation(s)
May 2008
Case 4a
MP1
MKD
MP2 MP
Role
Peer’s key cached
action
Case 4a
MP1 MA No
Fetch key (handshake)
MP2
Further actions depend on completion of key fetch operation(s)
MP1’s fetch completes first, it initiates handshake offering both PMKs
If handshake message arrives before MP2 completes fetch key, simply choose its own key and complete handshake
If handshake message arrives after MP2 completes fetch key, key choice can be arbitrary, e.g., choose the yongest
Similar analysis if MP2’s fetch completes first
MP1 and MP2 complete simultaneously, similar to b)
Neither key fetch completes, communication is impossible

34. May 2008
Case 4b
MP1
MKD
MP2 MP
Role
Peer’s key cached
Action
Case 4a
MP1 MA
Yes
Handshake
MP2 No
Fetch key (handshake)
MP2 will go fetch MP1’s key while offering its own key in handshake
Actual operations depend on communication results
If MP1’s handshake instance communicate with MP2’s active handshake successfully
Handshake may succeed with MP2’s PMK
Otherwise, if MP1’s handshake message comes after MP2’s key fetch completes, key choice can be arbitrary
If MP1 has cached a stale key, reduce to case 4a

35. Case 4c Both start handshake offering both keys
May 2008
Case 4c
MP1
MKD
MP2 MP
Role
Peer’s key cached
Action
Case 4a
MP1 MA
Yes
Handshake
MP2
Both start handshake offering both keys
Key choice can be arbitrary, e.g., expires last
If one cached key is stale, reduce to case 4b
If both cached keys are stale, reduce to case 4c

36. How Might Case 6 Work? May 2008 MP1 MP2 MKD2 MKD1 KCK-2, KEK-2 CK, EK
PMK-ID || MKD1 || MP2
PMK-ID || MKD1 || MP2 || MP1 || N2
Generate random K1, K2, NM
 = EKEK-2(K1 || K2 || MP2 || N2)
 = EEK(K1 || K2 || MKD1 || NM)
[PMK-ID || MKD1 || MP2 || MP1 || N2 || MKD2 || NM ||  || ]CK
 = EK2(PMK || PMK-ID || MP2 || N2 || MP1)
[NM || MKD2 || [N2 || MP2 ||  || ]K1]CK
[N2 || MP2 || [N2 || MP2 ||  || ]K1]kCK-2

37. Case 4 Example May 2008 Both MPs share same MKD MKD MP1 MP2
Randomly generate PMK, PMKID
 = EKEK-1(PMK || PMKID || MP2 || MP1 || R1)
 = EKEK-2(PMK || PMKID || MP1 || MP2 || R2)
MKD
KCK-1,KEK-1
[R2 || [R1 || ]KCK-1 || ]KCK-2
MP2 || MP1 || R1 || R2
MP2 || MP1 || R1
MP1
MP2
[R1 || ]KCK-1
This is only an example; other approaches to PMK distribution will also work