May 2008

Tony Braskich, Motorola

Slide 1

doc.: IEEE 802.11-08/0617r0

Submission

Refining the Security ArchitectureDate: 2008-05-13

Authors:Name Affiliations Address Phone email Tony Braskich Motorola 1301 E. Algonquin Rd.

Schaumburg, IL 60196 +1-847-538-0760

Tony.Braskich@Motorola.com

Steve Emeott Motorola 1301 E. Algonquin Rd. Schaumburg, IL 60196

+1-847-576-8268

Steve.Emeott@Motorola.com

May 2008

Tony Braskich, Motorola

Slide 2

doc.: IEEE 802.11-08/0617r0

Submission

Abstract

This presentation provides a brief overview of some security issues being discussed during the LB 126 comment resolution process.

May 2008

Tony Braskich, Motorola

Slide 3

doc.: IEEE 802.11-08/0617r0

Submission

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.

May 2008

Tony Braskich, Motorola

Slide 4

doc.: IEEE 802.11-08/0617r0

Submission

Topics to discuss

• Introduction to security, and making the security topics more accessible.

• Providing security goals

• Key Hierarchies and management

• Multiple MKDs

May 2008

Tony Braskich, Motorola

Slide 5

doc.: IEEE 802.11-08/0617r0

Submission

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.

May 2008

Tony Braskich, Motorola

Slide 6

doc.: IEEE 802.11-08/0617r0

Submission

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

May 2008

Tony Braskich, Motorola

Slide 7

doc.: IEEE 802.11-08/0617r0

Submission

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

May 2008

Tony Braskich, Motorola

Slide 8

doc.: IEEE 802.11-08/0617r0

Submission

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.

May 2008

Tony Braskich, Motorola

Slide 9

doc.: IEEE 802.11-08/0617r0

Submission

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.

May 2008

Tony Braskich, Motorola

Slide 10

doc.: IEEE 802.11-08/0617r0

Submission

Merging meshes example

AS

MKD A MKD B

MP

MP

MP MPMP

MPMP

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.

May 2008

Tony Braskich, Motorola

Slide 11

doc.: IEEE 802.11-08/0617r0

Submission

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

May 2008

Tony Braskich, Motorola

Slide 12

doc.: IEEE 802.11-08/0617r0

Submission

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.

May 2008

Tony Braskich, Motorola

Slide 13

doc.: IEEE 802.11-08/0617r0

Submission

Questions?