Clarifying the Behavior of PMK Caching

1. Clarifying the Behavior of PMK Caching Authors: Date: 2010-03-08 Dan Harkins, Aruba Networks

2. Abstract This presentation provides an overview on how to clarify the use of PMK caching in our standard. Dan Harkins, Aruba Networks

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 it’s just the same behavior as if the Supplicant never asked in the first place. • If the Supplicant doesn’t want to do it, it won’t 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. Dan Harkins, Aruba Networks

4. PMK Caching • This is notanewfeature to add to the standard! • PMK caching is already in the standard, it’s just poorly worded. • PMK caching is implemented– the 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. Dan Harkins, Aruba Networks

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 database is outside the scope of our standard. • We don’t 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. Dan Harkins, Aruba Networks

6. Traditional “fat” AP PMK PMK Authenticator/AP PMK PMK AAA server EAP AAA 4-Way HS data Dan Harkins, Aruba Networks

7. WLAN Controller and “thin” APs CAPWAP Authenticaor AP PMK PMK AAA server EAP AAA 4-Way HS data Dan Harkins, Aruba Networks

8. Clarification of PMK Caching • A PMK SA can have multiple authenticator addresses, and therefore multiple PMKIDs. • STA’s 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 a PMKID for its BSSID to avoid EAP when doing a BSS transition. • Alternately, a STA can opportunistically compute PMKIDs from valid PMKs and the target AP’s BSSID and hope that one of them is valid. • If it works, great, a costly EAP exchanage has been avoided. • If it doesn’t work, then the behavior is just like it would’ve been had the STA not tried in the first place– another EAP exchange. • No loss of security! • Authenticator PMKSA can be viewed statically • Authenticator adds PMKIDs for all its AAs at creation time Dan Harkins, Aruba Networks

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. Dan Harkins, Aruba Networks

10. Backup Dan Harkins, Aruba Networks

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 Dan Harkins, Aruba Networks

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 bit needed because no ambiguity about what PMK (only one per AA). • Subsequently changed to include a list of PMKIDs because ambiguity can arise– client is not aware of back-end topology and may repeatedly cross a controller boundary. It has to be able to send multiple PMKIDs. • The data structure used– a list– would be unnecessary if a PMK was bound to a single Authenticator address. It’s a list for a reason and the reason is to enable PMK caching! • Neighbor Report includes a Key Scope bit • Indicates that “this BSSID [in the Neighbor Report] has the same authenticator as the AP sending the report.” • The standard explicitly says an authenticator can have multiple BSSIDs! • Claim is incorrect! Dan Harkins, Aruba Networks

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 • Supplicant’s STA and the Authenticator’s STA are only entities that know the PMK • SPA is the Supplicant’s IEEE 802 address • AA is the Authenticator’s IEEE 802 address • Protocol assumes the AS delivers the correct PMK to the AP with 802 address AA. • None of these things are voided by PMK caching regardless of which AA is used for a particular instance of the 4-Way Handshake. • Even so, the 4-Way Handshake has been proven secure without the SPA 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]he MAC addresses of the authenticator and the supplicant do not appear to be necessary for the authentication process.” • 4-Way Handshake provides proof-of-possession of the PMK. That doesn’t change if different Authenticator addresses are used with different 4-Way Handshakes. • The claim is incorrect. Dan Harkins, Aruba Networks

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 noknowledge 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. Dan Harkins, Aruba Networks

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 Context string input to the KDF, provided that this information is known by each entity who 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 doesn’t change that. • Implementations supporting PMK caching have been FIPS certified! Evidence abounds to disprove this claim. • This claim is incorrect. Dan Harkins, Aruba Networks

16. Violates IETF Guidelines • Following quote from RFC 4962 is used as evidence to support this claim: “[M]any base stations may share the same authenticator identity. The authenticator identity is important in the AAA protocol exchange and in the secure association protocol conversation.” • However, the preceding sentence from RFC 4962 is always omitted when this claim is presented: “When multiple base stations and a ‘controller’ (such as a WLAN switch) comprise a single EAP authenticator, the ‘base station identity’ is not relevant; the EAP method conversation takes place between the EAP peer and the EAP server.” • The “authenticator identity” is the NAS-Id which is not used by 802.11 (proposal to include it in a beacon was defeated). The “base station” identity is the BSSID, and “is not relevant”. • CAPWAP explicitly describes the Controller/”thin AP” architecture with the Authenticator on the controller. • This claim is incorrect. Dan Harkins, Aruba Networks

17. PMK Caching is Insecure • This claim is followed by: “Suppose an authenticator is compromised….” • But that’s not an attack against PMK caching! • The same “security” “flaw” also applies to 11r. Is 11r insecure? • Then the tables are turned: you can’t prove PMK caching is secure. 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 it variable instead of static cannot introduce a security problem! • A one-way function does not leak information about an input– seeing a PMKID does not give an attacker information about the PMK! • PMK caching is NOT PMK sharing. The PMK never leaves the Authenticator. None of the security assumptions in IEEE 802.11-2007 change. • This claim is incorrect. Dan Harkins, Aruba Networks

18. References Dan Harkins, Aruba Networks