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

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

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

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

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

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

May 2008 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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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: 802.11i/r-like key hierarchies for PMKs key management appear undesirable for meshes

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

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

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

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

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

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

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

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

May 2008 Backup Slides

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

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

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

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

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