doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 1 TGi Draft 5.0 Comments Nancy Cam-Winget, Cisco Systems Inc

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 5 PTK Name can be derived from hierarchy: Pairwise Master Key (PMK) Pairwise Transient Key (PTK) (X bits) EAPOL-Key Key Confirmation Key L(PTK,0,128) (KCK) EAPOL-Key Key Encryption Key L(PTK,128,1 28) (KEK) Temporal Key TKIP: L(PTK,256,256) CCMP: L(PTK,256,128) (TK) PTKID L(PTK,XXX,1 28) (PTKID) Or, from the PMKID: PTKID = HMAC-SHA1-128(PMKID, 0 32 || “PTK Name” || SNonce || ANonce)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 6 DLP Key Establishment 4.a EAPOL Key STA1-STA2 GTK 4.b EAPOL Key STA1-STA2 GTK 5.a EAPOL Key Confirm 5.b EAPOL Key Confirm STA1 STA2 1a DLP Request 2b DLP Response 3. EAPOL Key Request STA1-STA2 Link 1b DLP Request 2b DLP Response

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 8 A better alternative: DLP is a 3 party protocol STA1 STA2 1a DLP Request New Link 2b DLP Response include STA1-STA2 GTK) 3. DLP AP Confirm( confirm STA1-STA2 GTK) 1b DLP Request ( include STA1-STA2 GTK) 2b DLP Response( confirm STA1-STA2 GTK) DLP Live ( STA1-MACAddr, STA2-MACAddr, nonce1, MIC) DLP Confirm (nonce1, MIC)

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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.

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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.

doc.: IEEE /657r0 Submission August 2003 N. Cam-WingetSlide 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?