“Not Ready” Response in FT Auth Messages Paul Funk, Funk Software 2/23/2019 11-05-0829-00-000r

Problem During Fast Transition, TTAP may need to: Request a PMK-R2 from upper levels of the key hierarchy Consult other network elements prior to satisfying resource (RIC) request This will delay the TTAP’s response to the STA’s FT request. As currently specified, STA must remain on TTAP’s channel to listen for response. This time is better used by STA returning to channel of current AP to continue trafficking in data. 2/23/2019 11-05-0829-00-000r

Solution In response to FT Auth request, TTAP may quickly respond with “Not Ready”. STA temporarily returns to channel of current AP to resume data exchange. STA then reissues FT request, hoping TTAP is now ready. Either the TTAP is now ready, or this process repeats. 2/23/2019 11-05-0829-00-000r

New Data Items Two new Status Codes are added: New Time Interval type: “Security Not Ready” indicates PMK-R2 not yet available “Resources Not Ready” indicates resources cannot immediately be allocated New Time Interval type: “Defer Time” (ms) indicates suggested interval after which STA may try again 2/23/2019 11-05-0829-00-000r

TTAP M2 Response May set SC = Security Not Ready M2/SNR includes: Defer Time Reassociation Deadline EAPKIE with ANonce M2/SNR does not include: Key Lifetime (as it is not known) 2/23/2019 11-05-0829-00-000r

STA Action on M2/SNR STA does the following: * Question: Delays for Defer Time interval Then either: Reissues M1, or Proceeds to next messaging phase [M3 (reservation) or (re)association request] * Note that STA is able to compute PTK, as it has ANonce from TTAP * Question: Allowing STA to proceed to next messaging phase may be an optimization but introduces variability. Is it worth it, or should STA be required to reissue M1? 2/23/2019 11-05-0829-00-000r

TTAP M4 Response to M3 If TTAP still does not have PMK-R2: It may set SC = Security Not Ready in M4 response. Contents of M4/SNR are same as M2/SNR, except for auth transaction sequence number If TTAP has PMK-R2 but needs time to allocate resources: Sets SC = Resources Not Ready in M4 Includes same IEs as per spec for M4, except: Omits RIC Adds Defer Time Otherwise, TTAP responds with M4 as per spec. 2/23/2019 11-05-0829-00-000r

STA Action on M4/Not Ready STA does the following (upon receipt of either SNR or RNR): Delays for Defer Time interval Reissues M3 (typically but not necessarily with the same RIC as before) Question: upon receipt of Resources Not Ready: Should STA be allowed to proceed directly to (re)association, including its resource request in that message? Resource semantics may preclude this, would like input from RIC experts 2/23/2019 11-05-0829-00-000r

TTAP (Re)Association Response If TTAP still does not have PMK-R2: It must acquire PMK-R2 prior to issuing successful (re)association response There is no provision for Not Ready response in (re)association response 2/23/2019 11-05-0829-00-000r

Key Replay Counter in EAPKIE I don’t think it is mentioned in the current spec It should be there: incremented by STA on each message echoed by TTAP In particular it is needed for Not Ready usage, as identical messages may be reissued and, thus, replayed. 2/23/2019 11-05-0829-00-000r

Action Frames Should Not Ready mechanism be permitted in Action frames for FT over-the-DS? The problem of keeping the STA from passing traffic does not exist with over-the-DS. However, there might be value in informing the STA quickly that the TTAP is processing the request. 2/23/2019 11-05-0829-00-000r