1 / 25

Roaming timings and PMK lifetime

Explore in-depth data on roaming timings and PMK lifetime by Tim Moore from Microsoft, involving APs, channel associations, packet captures, authentication durations, and key management delays in wireless networks.

leppert
Télécharger la présentation

Roaming timings and PMK lifetime

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. Roaming timings and PMK lifetime Tim Moore Microsoft Tim Moore, Microsoft

  2. Roaming timing • 2 APs with same SSID • Channel 1 and channel 11 • Associate to one AP • Force roam to other AP • Some timings with no data and some with data flowing • Capture 802.11 packets using Airopeek • Timings based on Airopeek timestamp • Checked by tracing supplicant: user mode and kernel timing • Station • PIII 1200MHz, Broadcom 11b MiniPCI NIC • PIII, Intersil 11b PCMCIA NIC • APs • 125MHz MIPS, Broadcom 11b • 160MHz ARM9, Intersil 11b Tim Moore, Microsoft

  3. Timings (Milliseconds) Message Client AP Total Auth -> 0 Auth <- 0.4-0.5 0.4-0.5 Re-ass Request 0.5 -> 0.9-1 Re-ass Response <- 0.7-1 1.6-2 Message 1 <- 0.5-2 2.1-4 Message 2 11-12.2 -> 13.1-16.2 Message 3 <- 2-3 15.1-19.2 Message 4 1-14 -> 16.1-33.2 Group 1 <- 2.6-4 18.7-37.2 Group 2 1-6 -> 19.7-43.2 Note: Times after first round of testing and improvements Intersil times similar, slightly longer to re-associate (2-4ms), longer to respond to Message 3 (11ms) Tim Moore, Microsoft

  4. Timing notes • Message 1 variation: AP transmits data packets • Since AP is scheduling packets, AP can avoid this • Message 2: • No scheduling delay on receive: already processing media connect • Scheduling of transmit (~8ms) • Message 4: • Scheduling of receive • Scheduling of transmit • Group 2 variation: • Scheduling of receive • Scheduling of transmit • Mac retransmissions seen • Debug tracing on supplicant affects timing • Turned off for best times • AP message processing much faster than client • i.e. times are not crypto bound, they are scheduling delays • Long delay (120ms) in client on first association with a NIC • Supplicant processing • Roaming not affected • Difference in AES key wrap/HMAC-SHA1 to TKIP key wrap/HMAC-MD5 too small to notice Tim Moore, Microsoft

  5. Key management delays • OS scheduling delays • Data packets interleaved between key management messages • 40% < 40 octets: 0.2ms • 80% < 600 octets: 1ms • 85% < 1400 octets: 1.7ms • VoIP systems should use 802.11e to prioritize EAPOL-Key messages • EAPOL-Key messages < 200 octets Tim Moore, Microsoft

  6. Summary • Authentication/association • 2-4ms • <50ms roaming time using 4-way handshake • Not including Group acknowledgement • Total time pairwise and group keys to supplicant • 17.1-35.6ms • Removing supplicant scheduling delays • 9.1-13.1ms • Crypto is a small amount of the key handshake time • Issues found in all implementations looked at • First round of improvements ~35%-90% depending on the implementation • Still have another 25%-45% improvement • Note: IP duplicate address detection is 3 seconds Tim Moore, Microsoft

  7. PMK Lifetime • PMK from 802.1X may have a lifetime supplied • PMK is discarded on disassociate even if lifetime has not expired • PMK from PSK has no lifetime • Lifetime is when user changes the PSK • 4-way handshake exchanges two 32 octet nonces • 2^256 4-way handshakes before PTK reuse • Less because Nonces start from Random number on system start • 4-way handshake on association/re-association • Years of associations with a PMK before PTK reuse • Cache PMKs and use 4-way handshake for PMK authentication and fresh PTKs Tim Moore, Microsoft

  8. PMK caching • Supplicant and Authenticator cache PMK • Reduces current authentication load on Authentication Servers • Bad roaming decisions • Edge of radio range • Load balancing • ~50% authentications at MS within Windows group are due to supplicants roaming for one of the above reasons • Examination of a week of ~5000 authentications a day • 5 clients: 300-700 auths/day, 1000 clients: 2-10 auths/day • Reduces AS load from pre-authentication • Reduces need for pre-authentication to only when supplicant/authenticator doesn’t already have PMK for AP • Always use PMK if available and only re-authenticate when PMK expires or is not available • Reduces roaming times to ~20-40ms when PMK available • Increased system reliability if AS is not available Tim Moore, Microsoft

  9. PMK cache • MAC address for PMK 6 bytes • PMK value 32 bytes • PMK lifetime (sec) 4 bytes • Authentication server attributes N bytes • VLAN id, etc. • PMK start time (sec) 4 bytes • PMK last time used (sec) 4 bytes • ~50 bytes per PMK • Supplicant doesn’t get PMK lifetime from AS Tim Moore, Microsoft

  10. PMK cache size (Normal MS building) Tim Moore, Microsoft

  11. PMK cache size (Conference center) Tim Moore, Microsoft

  12. Use of PMK caching • 1 bit in RSN IE capabilities • Authenticator sets bit in Beacon and probe response: • Supports PMK caching • Supplicant set bit in assoc request: • PMK available for the AP’s MAC address • Authenticator on receiving association request • If (PMK available bit is set and PMK for station is in cache) or PSK • Respond with Message 1 of 4-way handshake • Else • Respond with EAP-Request/Identity • Supplicant is authenticated and PMK lifetime is X% expired, authenticator sends EAP-Request/Identity to re-authenticate the supplicant and get a new PMK Tim Moore, Microsoft

  13. Use of PMK cache • Supplicant and Authenticator can delete PMKs at any time e.g. when cache full • Authenticator must delete PMK at end of lifetime • Supplicant deletes PMK on failed 4-way handshake • PMK in cache updated when 802.1X completes successfully • Multiple PMKs per MAC address are not required Tim Moore, Microsoft

  14. Authentication load • 1000 clients -> 5000 authentications per day • Every roam is an authentication • 50% is bad roaming decisions, see earlier • Of remainder majority are between 9am and 10.30am at users office • Rest of authentications are mobile users and PMK timeout (2 hours) • PMK lifetime > 8 hour < 24 hours • Bad roaming decisions doesn’t need AS • Mobile users doesn’t need AS for home location • PMK lifetime > 24 hours • Start of day authentication doesn’t need AS • Roaming to home locations doesn’t need AS Tim Moore, Microsoft

  15. Flushing PMKs • If PMKs are cached in APs for long periods of time, how to manage the PMKs • Use draft-chiba-radius-dynamic-authorization • Defines how RADIUS servers can send messages to APs to terminate sessions Tim Moore, Microsoft

  16. MIB variables • PMK lifetime re-authentication period • 1 octet, percentage of PMK lifetime • Default 50% • PMK max lifetime • 4 octets in seconds • Default 0xffffffff, lifetime from AS Tim Moore, Microsoft

  17. PMK caching and fast roaming • Fast authentication needs a PMK cache • Cache can be filled in by the AS rather than via 802.1X authentication through the AP • draft-aboba-pppext-key-problem-06.txt recommends using a different part of MSK for fast roaming key derivation • Allows fast roaming without affecting current key derivation • Different PMKs for each AP for each 802.1X authentication • Cache will need to hold PMK and multiple fast roaming PMKs per AP MAC address • Synchronization problem with fast roaming PMK (PMK-1) • Sync problem doesn’t exist with PMKs via auth or pre-auth • A station updates PMK via 802.1X, time delay before PMK-1 is updated by AS • So station doesn’t know to use old or new PMK-1 on a roam Tim Moore, Microsoft

  18. STA AS AP1 AP2 PMK-0 PMK-0 PMK-1/2 PMK-1/2 Roam here should use PMK-1/2 PMK-0’ PMK-1’/2 PMK-0’ PMK-0’’ PMK-0’’ PMK-1’’/2 Roam here may use PMK-1/2 or PMK-1’/2 or PMK-1’’/2 Since station doesn’t know which revision of PMK-1/2 has be delivered to AP2 by the AS Tim Moore, Microsoft

  19. Issues • How is the revision number allocated? • AS has to specify revision number to AP since it generates the PMK-1s • How is the revision number consistent between station and AS? Across restarts? • Does the revision number need to passed in the EAP method? • Hash of the PMK could be used as the PMK-1 identity • Need a RADIUS attribute to carry PMK-1 identity to AP • How many revisions should the station cache? • Does station really need to cache all PMKs until the PMK lifetime expires? • Cache only the last PMK and require full 802.1X handshake if not available? Tim Moore, Microsoft

  20. Key derivation • From keying-problem IETF draft • PMK0 = MSK(0,31) • Current Radius key derivation • MSK(32,63) is already used • PMK1-X = PRF(EMSK(0, 31), “Roaming PMK” PMK0 || AP-X-MAC-Address || STA-MAC-Address) • Note EMSK = MSK(64, 127) Tim Moore, Microsoft

  21. Key Identifier • PMK0 • HMAC-SHA1-64(PMK0, “MSK”) • PMK1 • HMAC-SHA1-64(PMK0, “EMSK”) Tim Moore, Microsoft

  22. PMK processing • Associate request contains • PMK identifier • Add an 8 octet field for the PMK identifier to the RSN IE • AP response • If PMK identifier supplied and PMK for identifier available • Message 1 of 4-way handshake • Else • EAP-Request/Identity • Station and AP only caches last PMK0 and PMK1 • If latest PMK1 hasn’t arrived at AP then full 802.1X auth • Station should use PMK0 if available • Add identity to PMK cache Tim Moore, Microsoft

  23. Question • An IRTF group is being proposed to look at fast roaming • Do we define this or wait until IRTF completes? Tim Moore, Microsoft

  24. Motion • Motion to incorporate section “Version 1 PMK caching” from document 11-03-160ar0-I-PMK_lifetime_and_caching.doc into 802.11i draft to support PMK caching • Overview of PMK caching • 1 bit in IE capabilities and description of its use • Description of processing required • MIB variables to control PMK caching Tim Moore, Microsoft

  25. Motion • Motion to incorporate section “Version 2 PMK caching including fast authentication” from document 11-03-160ar0-I-PMK_lifetime_and_caching.doc into 802.11i draft to support PMK caching and fast authentication • Overview of PMK caching • PMK identifier in IE capabilities and description of its use • Description of processing required • Description of generation of PMK identifiers • Description of key derivation for PMKs to authenticators other than original Authenticator • MIB variables to control PMK caching Tim Moore, Microsoft

More Related