1 / 13

TGi Draft 5.0 Comments

TGi Draft 5.0 Comments. Nancy Cam-Winget, Cisco Systems Inc. Key Naming. Current draft specifies: PMKID = HMAC-SHA1-128(PMK, “PMK Name” || BSSID || STA-MAC-Addr) PTK = HMAC-SHA1-128(PTK, “PTK Name” || SSID). PMK Name.

mayten
Download Presentation

TGi Draft 5.0 Comments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGi Draft 5.0 Comments Nancy Cam-Winget, Cisco Systems Inc N. Cam-Winget

  2. Key Naming • Current draft specifies: PMKID = HMAC-SHA1-128(PMK, “PMK Name” || BSSID || STA-MAC-Addr) PTK = HMAC-SHA1-128(PTK, “PTK Name” || SSID) N. Cam-Winget

  3. PMK Name • PMK Name may be vulnerable to offline dictionary attacks if it is low entropy (like PSKs) • PMK Name does not need to be keyed from PMK • There are alternatives to current derivation: • Use the MS-MPPE-Send-Key as the key to HMAC-SHA1: PMKID = HMAC-SHA1-128(MS-MPPE-Send-Key, “PMK Name” || BSSID || STA-MAC-Addr) N. Cam-Winget

  4. PMK Name (cont’d) • Do we need to name PSK’s? Not clear there is a use for this, but if needed, we can extend the the Password-to-key hash function to generate 64 octets vs. 32, can use the extra 32 octets as the 32 octets as the MS-MPPE-Send-Key for: PMKID = HMAC-SHA1-128(MS-MPPE-Send-Key, “PMK Name” || BSSID || STA-MAC-Addr) N. Cam-Winget

  5. Pairwise Transient Key (PTK) (X bits) Temporal Key TKIP: L(PTK,256,256) CCMP: L(PTK,256,128) (TK) EAPOL-Key Key Encryption Key L(PTK,128,128) (KEK) EAPOL-Key Key Confirmation Key L(PTK,0,128) (KCK) PTKID L(PTK,XXX,128) (PTKID) PTK Name can be derived from hierarchy: Pairwise Master Key (PMK) Or, from the PMKID: PTKID = HMAC-SHA1-128(PMKID, 032 || “PTK Name” || SNonce || ANonce) N. Cam-Winget

  6. STA1 STA2 DLP Key Establishment 1a DLP Request 1b DLP Request 2b DLP Response 2b DLP Response 3. EAPOL Key Request STA1-STA2 Link 4.b EAPOL Key STA1-STA2 GTK 4.a EAPOL Key STA1-STA2 GTK 5.b EAPOL Key Confirm 5.a EAPOL Key Confirm N. Cam-Winget

  7. DLP Establishment (cont’d) • How do STA1 and STA2 know when they both have the same STA1-STA2 GTK? • DLP confirm message between STA’s is required to prove GTK liveness. • DLP abort message required to allow 3-party protocol to resync • How does a STA distinguish it’s multicast rekey of GTK from DLP GTK? • There is a race condition between STA1 and STA2 since neither know when they have the key plumbed • There is no proof between STA1 and STA2 that they have a live key: DLP confirm message can resolve this • Each can commence protected transmission, but if decrypt errors occur, they have no way to know if it is due to a race condition, liveness, rekey synchronization errors (as each one could trigger a rekey and become desynchronized) N. Cam-Winget

  8. STA1 STA2 A better alternative: DLP is a 3 party protocol 1a DLP Request New Link 2b DLP Response include STA1-STA2 GTK) 1b DLP Request ( include STA1-STA2 GTK) 3. DLP AP Confirm( confirm STA1-STA2 GTK) 2b DLP Response( confirm STA1-STA2 GTK) DLP Live ( STA1-MACAddr, STA2-MACAddr, nonce1, MIC) DLP Confirm (nonce1, MIC) N. Cam-Winget

  9. How are the STA-STA GTK’s consumed? • Does the AP generate a unique STA-STA GTK for every DLP request? This is not specified in the draft! • Who defines the GTK lifetime? Who revokes and renews it? • If not, the STA-STA link must invoke a 4-way handshake, or something similar to establish fresh and unique STA-STA link keys. • AP should embed the GTK for the intended DLP channel in the DLP response versus a separate GTK exchange to better bind the security association. • DLP Live/Confirm exchange between STA’s must be a minimum requirement to ensure the STA’s are communicating with the intended DLP channel N. Cam-Winget

  10. IBSS, why 2 4-way handshakes? • 4-way handshake is intended to establish the unicast keys to protect STA-STA link • GTK handshake is intended to establish the group keys to protect authenticator-supplicant link. • In an IBSS, there does not need to be strict enforcement of authenticator-supplicant roles when distributing keys: • Single 4-way handshake is sufficient to establish the STA-STA link • 2 GTK handshakes can be used to establish the group keys: initiator of GTK handshake is the “authenticator”, each STA must initiate it’s own GTK handshake N. Cam-Winget

  11. Why 2 distinct 4-way handshakes? • STA’s establishing IBSS connection may simultaneously commence the 4-way handshakes. Which one wins? • Spec indicates to use PTK of STA with the lower MAC address. However, if EAP authentication is used, each STA is invoking a full security association which results in 2 PMKs, so the STA with the lower MAC will still have 2 PTKs. • Is the intention to have the STA with the lower MAC address be the sole Authenticator and void the 4-way handshake initiated from the higher MAC address STA? If so, then it proves that only a single 4-way handshake is needed! • Two concurrent 4-way handshakes will lead to conflicting PTKs. • Two concurrent 4-way handshakes will confuse security policy negotiation: what if one STA negotiates TKIP in its 4-way handshake but the other initiates its 4-way handshake with WEP for unicast? For multicast? • Only a single security negotiation (e.g. 4-way handshake) should be required • If one finally specifies this, then there is no reason whatsoever for the 4-Way Handshake initiated by the STA with the higher MAC address; it is simply gratuitous. N. Cam-Winget

  12. Simplifying IBSS • Each STA behaves as both authenticator and supplicant. • A single 4-way handshake is used, lower MAC-Address can be the initiator. Since both sides have derived a common PTK (and KEK), each party can use this to distribute it’s own GTK. • Each STA initiates it’s own GTK handshake to plumb it’s group key to the receiving STA. N. Cam-Winget

  13. Pre-Authentication • Is a useful concept but draft has only introduced the concept: • TGi uses 802.1X as a Layer 2 protocol; pre-authentication requires either Layer 2 AP to AP which is not scalable or a switch of roles from bridging to routing. • 802.1aa will not address it in its PAR; group had stated it will not address it either. • Security model must be reviewed as pre-authentication now allows access of a wireless node either via the air or wired medium. • Authenticator port access must now control access via both the wireless and wired layer, this breaks the • MN’s not associated to target AP and thus no rate capability and other distribution service capabilities are negotiated. Thus, at minimum, pre-authentication allows MNs to flood APs with 802.1X traffic. • Richer security context is required for an MN, because MN can now pre-authenticate via wired or wireless medium. When does the PMK lifetime commence? At the time of pre-authentication or at association? • How does the session accounting and other L3 context become affected? N. Cam-Winget

More Related