tgi draft 5 0 comments
Download
Skip this Video
Download Presentation
TGi Draft 5.0 Comments

Loading in 2 Seconds...

play fullscreen
1 / 13

TGi Draft 5.0 Comments - PowerPoint PPT Presentation


  • 107 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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)

(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

dlp key establishment

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

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

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

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

ad