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:
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
2/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 2
Abstract
This presentation provides an overview on how to clarify
the use of PMK caching in our standard.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
3/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 3
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
4/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 4
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
5/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 5
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
6/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 6
Traditional fat AP
EAP
AAA
4-Way HS
data
PMK
PMKPMK
PMK
AAA
server
Authenticator/AP
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
7/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 7
WLAN Controller and thin APs
EAP
AAA
4-Way HS
data
CAPWAP
PMK
PMKAAA
server
Authenticaor
AP
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
8/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 8
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
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
9/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 9
A motion!
Instruct the editor to incorporate changes from
submission 11-10/0209r0 into the draft and resolve
CIDs 2098, 2099, 2100, and 2101.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
10/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 10
Backup
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
11/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 11
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
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
12/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 12
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!
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
13/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 13
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
14/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 14
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
15/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 15
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.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
16/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 16
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.
This claim is incorrect.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
17/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 17
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.
This claim is incorrect.
7/30/2019 11 10 0374-00-000m Pmk Clarification Preso
18/18
doc.: IEEE 802.11-10/0374r0
Submission
March 2010
Dan Harkins, Aruba NetworksSlide 18
References