doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 1 Refining the Security Architecture Date: Authors:

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 2 Abstract This presentation provides a brief overview of some security issues being discussed during the LB 126 comment resolution process.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 3 Overview TGs Draft 2.0 contains several new components that have been considered during the recent letter ballot. –Compared to Draft 1.0, the current TGs draft has new features and many refinements of previously-existing features. –We can now discuss the synthesis of the security architecture, since the necessary components can now be found in the draft. We can identify areas where further refinement is needed to ensure the components work together.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 4 Topics to discuss Introduction to security, and making the security topics more accessible. Providing security goals Key Hierarchies and management Multiple MKDs

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 5 Introduction to Security Security sections are split (§8, §11B.2, §11B.5). It can be difficult for readers not already familiar with the architecture to understand how security is achieved. Protocol names should be improved to provide additional information to new readers –For example, rename MSA Authentication as “Link Security Establishment.” –Rename Initial MSA Authentication as “Mesh Authentication.” Introduce SAE along with other security components. Explain to unfamiliar readers how SAE may be used in contrast to other authentication techniques. –MSA specifies centralized authentication (e.g., MKD-based). This can be “Mesh Authentication.” –Alternatively, SAE permits “peer authentication,” between two MPs, without a centralized point of control.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 6 Security Goals Security goals would help the reader understand the purpose for the mechanisms defined in the specification. The following goals, addressing the entire architecture for mesh security, should be considered for inclusion: –Mutual authentication of MPs before communicating –Per-hop Confidentiality (from those outside the mesh) of data traffic –Per-hop Integrity of data traffic –Authorization to send traffic on the mesh –Management functions limited to “member” MPs (i.e., outsiders cannot influence mesh functions, such as routing) –Provable security (i.e., the design should permit analysis and development of a proof).

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 7 Key Hierarchies & their management MSA utilizes a mesh key hierarchy to derive keys for use in securing links with candidate peer MPs. –Top of the hierarchy created when an MP authenticates to an MKD. This creates fixed-size state information, an MKD security association. –Also defines keys to protect key holder communication. With a key hierarchy, an MP computes the keys it needs for new candidate peer MPs on-demand. –For example, a mobile MP may derive PMK-MAs as it discovers peers. –Session keys (e.g., a PTK) are established from the PMK-MAs. Comment spreadsheet includes suggestions for clarifying some details of the key hierarchy. For example, the following additions would be helpful: –Definitions of created state (i.e., security associations) –Policies for deleting security associations –Explanation of the process of reauthenticating

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 8 Key Hierarchy Benefits Only one of two peer MPs needs to obtain a PMK-MA from the MKD. –This reduces the required information transfer between devices that is needed before establishing a peer link. –This may help reduce error situations, such as by avoiding extra protocols. The amount of state related to the key hierarchy that an MP must maintain is flexible. –PMK-MAs for use with other MPs can be computed on-demand, such as before establishing a secure peer link. –Because the MP can always re-create the PMK-MA from the MKDSA, these may be deleted to free memory. –On the other hand, some MPs may choose to pre-compute and cache keys, especially if memory is cheap. A revised KDF accelerates the key derivation procedure for PMK-MAs. –(A partial computation applicable to all PMK-MAs can be performed and stored.) For any link, one of two PMK-MAs may be selected to secure it. This provides redundancy in the event that one MP cannot reach an MKD.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 9 Multiple MKDs: Why? Multiple MKDs may be present in a mesh. Why might a mesh deploy multiple MKDs? 1.Avoid single point of failure. –A single MKD must be reachable by an MA whenever the MA is establishing a peer link with a new neighbor. –Failure of the MKD will prevent new link establishment in the mesh. Multiple MKDs would increase the probability of availability. 2.Merging & faster startup. –Mesh links must be built out from the MKD. Multiple MKDs provide several “seeds” to begin growing the mesh, rather than from a single node. (Example, next slide.) 3.Distribution of load, for the purpose of reducing key pull delays. –At the MKD: in a large mesh, the MKD might become too busy handling requests for key distributions and handling authentications. With multiple MKDs, the load may be distributed. –On mesh paths: Path to the MKD may be congested, of poor quality, etc., but is needed whenever new peer links are established. Multiple MKDs would increase the number of mesh paths that can be used to obtain a PMK-MA.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 10 Merging meshes example AS MKD AMKD B MP wired network Authentication through MKD B Multiple MKDs have been configured identically, with the same AS. Two disjoint meshes begin forming, with different MKDs. When the meshes merge, one MP must authenticate through the other MKD. But, the mesh is unified. Two MKDs allowed the mesh to grow more quickly than with just 1 MKD.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 11 Multiple MKDs: improvements The draft could be improved to give implementers a better guide for managing multiple MKDs. An MA and an MKD use the key holder security association (KHSA) to secure communications. Additional work is needed on managing KHSAs with multiple MKDs. The comment spreadsheet includes some suggestions for improvement: –Remove the restriction of an MP having a single KHSA. –The concept of an MKD domain causes confusion and is not needed. The text can be made more applicable to a mesh with multiple MKDs. –Improve the MSA authentication mechanism for better accommodation of multiple MKDs

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 12 Conclusions Tying together the security sections and providing security goals will help readers and implementers understand the purpose of our security components. A key hierarchy has benefits for use in a mesh. –For example, an MP uses local information to compute keys, and has flexibility in maintaining key hierarchy state information. –The draft should provide more information on managing the key hierarchy. Multiple MKDs also provide important features, such as fault tolerance and load distribution. –Protocol improvements could allow better utilization of the features provided by multiple MKDs.

doc.: IEEE /0617r0 Submission May 2008 Tony Braskich, MotorolaSlide 13 Questions?