1 / 4

Flexible Pre-key Overview

Flexible Pre-key Overview. Jon Edney, Stefan Faccin Nokia. Key points. Establish PTKs for both STA and AP prior to reassociation request Negotiate AP resources prior to or during reassociation Use only reassociation request and response for transition

moultrie
Download Presentation

Flexible Pre-key Overview

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. Flexible Pre-key Overview Jon Edney, Stefan Faccin Nokia

  2. Key points • Establish PTKs for both STA and AP prior to reassociation request • Negotiate AP resources prior to or during reassociation • Use only reassociation request and response for transition • Entire environment on new AP can be setup in advance • Avoid resource exhaustion attacks by “last second” reservation at new AP • New AP has option to defer decision on resource allocation until reassociation

  3. AP Authenticator Summary of the Flexible Pre-key Approach Client Supplicant Pre-transition Client determines new AP for roam, increments ANONCE Generates SNonce, Generates new PTKi, Generates STnonce Generate Resource Rq-Blob {SNonce} Ek{STKey, Resource Rq Blob, STA_RSN_IE} {MIC} AP validates ANONCE Generates new PTK, validate 802.1X Pre-Key 1 Generate ATnonce & Resource_Rsp_blob Ek{ATnonce, [Resource Rsp Blob], GTK, AP_RSN_IE} {MIC} Reassociate request Include MIC & ATnonce to prove live STA Transition Reassociate response Include value of MIC & STnonce to prove live AP

  4. Summary of Resource Blob • Tree structure for scalability • Related resource requests can be grouped • Resource requests have index number • Each node of tree can have “mandatory” indicator • Each node of tree can have “defer” indicator • AP can allocation upon request or defer allocation decision until reassociation • If deferred, STA only provide list of index numbers in secondary request.

More Related