Tgi draft 5 0 comments
1 / 13

TGi Draft 5.0 Comments - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'TGi Draft 5.0 Comments' - mayten

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Tgi draft 5 0 comments

TGi Draft 5.0 Comments

Nancy Cam-Winget, Cisco Systems Inc

N. Cam-Winget

Key naming
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

Pmk name
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

Pmk name cont d
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

Ptk name can be derived from hierarchy

Pairwise Transient Key (PTK)

(X bits)

Temporal Key

TKIP: L(PTK,256,256)

CCMP: L(PTK,256,128)


EAPOL-Key Key Encryption Key L(PTK,128,128) (KEK)

EAPOL-Key Key Confirmation Key L(PTK,0,128) (KCK)



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

Dlp key establishment



DLP Key Establishment

1a DLP Request

1b DLP Request

2b DLP Response

2b DLP Response

3. EAPOL Key Request STA1-STA2 Link



5.b EAPOL Key Confirm

5.a EAPOL Key Confirm

N. Cam-Winget

Dlp establishment cont d
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

A better alternative dlp is a 3 party protocol



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

How are the sta sta gtk s consumed
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

Ibss why 2 4 way handshakes
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

Why 2 distinct 4 way handshakes
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

Simplifying ibss
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

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