11 10 0374-00-000m Pmk Clarification Preso

7/30/2019 11 10 0374-00-000m Pmk Clarification Preso

1/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010

Dan Harkins, Aruba NetworksSlide 1

Clarifying the Behavior of PMK CachingDate: 2010-03-08

Name Affiliations Address Phone email

Dan Harkins Aruba Networks 1322 Crossman ave,

Sunnyvale, CA

+1 408 227

4500

dharkins at arubanetworks

dot dom

Authors:


2/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Abstract

This presentation provides an overview on how to clarify

the use of PMK caching in our standard.


3/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


PMK Caching

A way to avoid costly EAP authentications when a PMK already

exists at the Authenticator of the AP to which a STA is attempting a

BSS transition.

Support is negotiated at (Re)Association time

Supplicant includes a list of PMKIDs in its (Re)Associate Request. If Authenticator has a PMKSA identified by one of the PMKIDs EAP

authentication is skipped.

Robust

If a Supplicant wants to do it and an Authenticator does not then its just the

same behavior as if the Supplicant never asked in the first place. If the Supplicant doesnt want to do it, it wont happen

Either side controls its own cache and can flush it for any reason.

No extra messages if negotiation of PMK caching fails.

No loss of security if it succeeds or if it fails.


4/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


PMK Caching

This is not a new feature to add to the standard!

PMK caching is already in the standard, its just poorly worded.

PMK caching is implementedthe laptop in front of you right now

most likely supports it!

There are multiple, independent, and interoperable

implementations of PMK caching.

Existing support is in spite of, not due to, the way it is

specified in our standard today.

We need to clarify current behavior.

With high probability, someone should be able to make an

interoperable implementation by just reading the standard.


5/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


PMK Caching

Some vendors have no problems, others have problems. Closely correlates to vendor presence in 802.11.

Common questions include: Do I used the same PMKID for different AAs or do I generate a

new PMKID for each target AA? How many PMKIDs do I include in a (Re)Association Request?

The particular implementation of a PMKSA databaseis outside the scope of our standard.

We dont need to impose requirements on implementation of the

database. We need to clarify how to support PMK caching in our

standard.

Describe what each side should expect of the other.

See 11-10/0209r0.


6/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Traditional fat AP

EAP

AAA

4-Way HS

data

PMK

PMKPMK

PMK

AAA

server

Authenticator/AP


7/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


WLAN Controller and thin APs

EAP

AAA

4-Way HS

data

CAPWAP

PMK

PMKAAA

server

Authenticaor

AP


8/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Clarification of PMK Caching

A PMK SA can have multiple authenticator addresses, and

therefore multiple PMKIDs.

STAs PMKSA is dynamically updated through ESS interaction

Using the Neighbor Report a STA can determine that another AP has the

same Authenticator as the AP to which it is associated and compute aPMKID for its BSSID to avoid EAP when doing a BSS transition.

Alternately, a STA can opportunistically compute PMKIDs from valid

PMKs and the target APs BSSID and hope that one of them is valid.

If it works, great, a costly EAP exchanage has been avoided.

If it doesnt work, then the behavior is just like it wouldve been had the STAnot tried in the first placeanother EAP exchange.

No loss of security!

Authenticator PMKSA can be viewed statically

Authenticator adds PMKIDs for all its AAs at creation time


9/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


A motion!

Instruct the editor to incorporate changes from

submission 11-10/0209r0 into the draft and resolve

CIDs 2098, 2099, 2100, and 2101.


10/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Backup


11/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Spurious Claims against PMK Caching

IEEE 802.11-2007 prohibits using one PMK with

different Authenticator addresses

PMK caching voids security guarantees of the 4-Way

Handshake in IEEE 802.11-2007

There is a contract between the AS and Supplicant to

only use the PMK with a single AA.

PMK caching violates NIST recommendations

PMK caching violates IETF guidelines

PMK caching is insecure


12/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Prohibited by IEEE 802.11-2007

(Authenticator Can Have Only 1 Address) PMK caching was added by 802.11i

Original contribution specified a single bit to indicate support. One bitneeded because no ambiguity about what PMK (only one per AA).

Subsequently changed to include a list of PMKIDs because ambiguity can

ariseclient is not aware of back-end topology and may repeatedly cross acontroller boundary. It has to be able to send multiple PMKIDs.

The data structure useda listwould be unnecessary if a PMK wasbound to a single Authenticator address. Its a list for a reason and thereason is to enable PMK caching!

Neighbor Report includes aKey Scope bit

Indicates that this BSSID [in the Neighbor Report] has the sameauthenticator as the AP sending the report.

The standard explicitly says an authenticator can have multiple BSSIDs!

Claim is incorrect!


13/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Voids the Security Guarantees of 4-Way

Handshake in IEEE 802.11-2007 Analysis of 4-Way Handshake in 8.5.3.7 says

Supplicants STA and the Authenticators STA are only entities that know thePMK

SPA is the Supplicants IEEE 802 address

AA is the Authenticators IEEE 802 address

Protocol assumes the AS delivers the correct PMK to the AP with 802address AA.

None of these things are voided by PMK caching regardless of whichAA is used for a particular instance of the 4-Way Handshake.

Even so, the 4-Way Handshake has been proven secure without theSPA and AA! They are not required for the security of the exchange.

C. He and J. Mitchell,Analysis of the 802.11i 4-Way Handshake states [t]heMAC addresses of the authenticator and the supplicant do not appear to benecessary for the authentication process.

4-Way Handshake provides proof-of-possession of the PMK. Thatdoesnt change if different Authenticator addresses are used withdifferent 4-Way Handshakes.

The claim is incorrect.


14/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


There is a Contract Between AS and

Supplicant Constraining PMK to One AA Not found anywhere in IEEE 802.11-2007

The AS has no knowledge of a BSSID!

EAP is used to establish the PMK and IEEE 802.11-2007 is

therefore bound by the EAP Key Management Framework Section 2.3 of that document states: Since an authenticator can have

multiple ports, the scope of the authenticator key cache cannot be described

by a single endpoint address.The port is the AP and the endpoint

address is its BSSID.

IEEE 802.11-2007 is forbidden from imposing such a constraint. Contract is neither express nor implied in IEEE 802.11-2007. The

AS can not constrain a key to something it knows nothing about!

The claim is incorrect.


15/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Violates NIST SP800-108, Cannot be FIPS

certified This claim is made because SP800-108 says

, the identity (or identifier, as the term is defined in [1] and [2]) of each

entity that will access (meaning derive, hold, use and/or distribute) any

segment of the keying material should be included in the Contextstring

input to the KDF, provided that this information is known by each entitywho derives the keying material.

But this is in regard to key derivation. The PMK is derived by the

AS and Supplicant and, regardless of whether PMK caching is

used or not, does not include the AA.

The PTK does have the AA and PMK caching doesnt change that. Implementations supporting PMK caching have been FIPS

certified! Evidence abounds to disprove this claim.

This claim is incorrect.


16/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


Violates IETF Guidelines

Following quote from RFC 4962 is used as evidence to support thisclaim: [M]any base stations may share the same authenticatoridentity. The authenticator identity is important in the AAA protocolexchange and in the secure association protocol conversation.

However, the preceding sentence from RFC 4962 is always omittedwhen this claim is presented: When multiple base stations and acontroller (such as a WLAN switch) comprise a single EAPauthenticator, the base station identity is not relevant; the EAP

method conversation takes place between the EAP peer and the EAPserver.

The authenticator identity is the NAS-Id which is not used by802.11 (proposal to include it in a beacon was defeated). The basestation identity is the BSSID, and is not relevant.

CAPWAP explicitly describes the Controller/thin AParchitecture with the Authenticator on the controller.



17/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


PMK Caching is Insecure

This claim is followed by: Suppose an authenticator iscompromised. But thats not an attack against PMK caching!

The same security flaw also applies to 11r. Is 11r insecure?

Then the tables are turned: you cant prove PMK caching issecure. But: There is no cryptographic binding of any authenticator address into the

PMK.

If the AA is not necessary for the security of the 4 way HS then making itvariable instead of static cannot introduce a security problem!

A one-way function does not leak information about an inputseeing a PMKID does not give an attacker information about the

PMK! PMK caching isNOTPMK sharing. The PMK never leaves the

Authenticator. None of the security assumptions in IEEE 802.11-2007 change.



18/18

doc.: IEEE 802.11-10/0374r0

Submission

March 2010


References

Documents

11 10 0374-00-000m Pmk Clarification Preso