1 / 37

MSA Key Hierarchy Analysis and Alternatives

MSA Key Hierarchy Analysis and Alternatives. Date: 2008-05-09. Authors:. 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. Agenda. Background

gaius
Download Presentation

MSA Key Hierarchy Analysis and Alternatives

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MSA Key Hierarchy Analysis and Alternatives Date: 2008-05-09 Authors:

  2. 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 • 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 • 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 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 • 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. Analysis Summary • An 802.11i/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

  9. Enable Security Handshake Between MPs • 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. Case 4 Both MPs have a path to the same MKD MP1 MP2 MKD • 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 Caused by Re-authentication with the same MKD

  12. 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 MSK or PSK PMK-MKD MKDK PMK-MA PMK-MA MPTK-MKD • 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! … PTK PTK

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

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

  20. Case 5a (Continued) What if we temporarily “relax” the “delete old MKD SA” rule? MKD1 MP1 MP3 MKD2 MP4 MP2 MP5 • 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. 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. 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. 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: 802.11i/r-like key hierarchies for PMKs key management appear undesirable for meshes

  24. 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 • Add MKD-MKD trust relationship and supporting protocols MSK or PSK PMK-MKD MKDK PMK-MA PMK-MA MPTK-MKD … PTK PTK

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

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

  31. 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. Backup Slides

  33. 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 MP1 MKD MP2 Case 4a

  34. 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 MP1 MKD MP2 Case 4b

  35. 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 MP1 MKD MP2 Case 4c

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

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

More Related