1. “Not Ready” Response in FT Auth Messages
Paul Funk, Funk Software
2/23/2019 r

2. 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 r

3. 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 r

4. 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 r

5. 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 r

6. 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 r

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

8. 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 r

9. 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 r

10. 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 r

11. 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 r