what is reassociation_deadline/r0_key_lifetime?

[James Prestwood]

Hi Jouni,

On Wed, 2022-12-14 at 00:58 +0200, Jouni Malinen wrote:
> 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.

Perfect, this is exactly what I was looking for. I think this is the
issue our user ran into since in his case it was ~30 seconds between
initial association and FT-over-DS.

Thanks for the explanation!

- James