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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
