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