what is reassociation_deadline/r0_key_lifetime?

[Jouni Malinen]

On Tue, Dec 13, 2022 at 01:50:34PM -0800, James Prestwood wrote:
> I'm trying to debug an issue related to FT-over-DS authentications
> expiring (unknown if the AP is even running hostapd) and I came across
> these options:
> 
> # Default lifetime of the PMK-RO in minutes; range 1..65535
> # (dot11FTR0KeyLifetime)
> #r0_key_lifetime=10000
> 
> # Reassociation deadline in time units (TUs / 1.024 ms; range
> 1000..65535)
> # (dot11FTReassociationDeadline)
> #reassociation_deadline=1000
> 
> So my first question is more pointing out the fact that these values
> are used to populate the TIE element, but don't see any timeouts to
> enforce these. Is this intended? Or maybe these options were merely for
> testing the presence of TIE but not actually used?

ft_r0_key_lifetime is the new name for the first one of those. It is
used in setting the expiration time for PMK-R0 entries. The purpose of
indicating the lifetime of the PMK-R0 to the station is to allow that
station to know when it needs to perform reauthentication to generate a
new PMK, i.e., when an attempt to perform FT protocol (over air or DS)
is expected to fail with the old key.

hostapd does not enforce any particular deadline for reassociation when
using FT, so this parameter is really more for testing purposes at least
for now.

> My second question is how this relates to FT/reassociation. The spec
> isn't clear what these timeouts are for. Maybe someone knows? Is it for
> rekeys? or for future FT attempts? or?

I described the main use for dot11FTR0KeyLifetime above.
dot11FTReassociationDeadline is the limit on how long a time a station
can wait between performing the FT authentication (the first two
messages of FT protocol either over-the-air or over-the-DS) and
completing the reassociation. It might be used to schedule parallel
operations (etc.) on a station to be quick enough for the target AP's
needs or alternatively, to decide when to abandon an FT protocol attempt
if too long time has passed between those operations. Even the minimum
(and default) value of 1000 TUs should be long enough to cover normal
single pending authentication cases and this might be of real use only
if the station is performing multiple parallel authentications to be
ready for a reassociation at some point in time in the future, i.e.,
when there might be a significant amount of time between those two
steps.

> The reason I'd like to know this is because IWD does FT-over-DS quite
> early, and this user is seeing their AP 'expire' his station. He then
> cannot reassociate when its time to roam. This is the first time I'd
> ever seen this and we are trying to figure out if maybe these timeouts
> point to some ultimate expiration for FT keys. Again, the spec is
> totally unclear about this AFAICT.

It is relatively clear to me, but I did participate in IEEE P802.11r
development, so that might explain that.. These are indeed for the AP to
indicate a minimum lifetime for keys (PMK-R0 and PTKSA, respectively)
that the STA should expect to be able to use them (and while not
strictly disallowed from using them after, be prepared for operations
failing if such a late attempt is tried).

So if there could be more than a second between FT-over-DS completion
and the following reassociation exchange, I would recommend looking at
the reassociation deadline value the AP advertises during the initial
mobility domain association (in FT 4-way handshake) and using that to
determine whether there is risk of not being able to meet the advertised
time limit. And for the PMK-R0 lifetime, the STA might trigger
reauthentication at a convenient point in time to avoid getting
disconnected or prevented from using FT protocol after the key hierarchy
might have expired.

-- 
Jouni Malinen                                            PGP id EFC895FA