On Fri, 2022-05-27 at 14:09 -0400, Alan DeKok wrote: > On May 27, 2022, at 1:06 PM, James Prestwood <prestwoj@xxxxxxxxx> > wrote: > > Yes I misinterpreted what you said. But from what I can tell the > > supplicant isn't even involved at the point when hostapd fails to > > look > > up the user (the supplicant hasn't even received an identity > > request). > > I'm less familiar with the internals of hostap, so I'll reply from > the point of view of a RADIUS server author, which may not be exactly > the same as what hostap does. This problem is really about the internals of hostapd itself, not RADIUS or the spec. > > > In my test I issue the EAPOL_REAUTH command to hostapd which > > triggers > > the lookup based on the eap_sm's saved identity. This identity is > > phase2 since TTLS/PEAP overwrite sm->identity during the initial > > authentication. > > See RFC 9190 Section 5.7 for discussion of what needs to be cached > for resumption. While the RFC is for EAP-TLS, the same requirements > apply to PEAP / TTLS / TEAP. > > > I could care less what identity hostapd wants to use to lookup the > > session, but since sm->identity is used for both phases there needs > > to > > be some logic to determine what phase the identity goes with. Hard > > coding to phase1 in all cases is wrong if sm->identity is for > > phase2. > > Resumption SHOULD use the same outer identity as the original > authentication. I think this is what hostapd is _trying_ to do as the lookup call will always look for a phase1 identity, i.e. outer identity (this is the integer argument 'phase2=0'). But for the identity value it uses whatever sm->identity is, which was set by the EAP method. In the case of tunneled methods, this is the inner identity as thats what is stored last. So we try looking up a phase2 identity but require that any matches be a phase1 identity. And of course this fails unless: a) The identities are the same or b) The configuration uses a wildcard for phase1. > > The server SHOULD cache a set of information about the original > session, including things like inner identity, MAC addresses, etc. > This cache is typically based off of the TLS session key, because > nothing else is really relevant. > > IIRC hostap keeps information about ports it controls. So that it > can detect re-authentication, etc. for a port. This includes the > "real" identity of the user. yep, and this is the identity being used for the lookup. But with the assumption that its a phase1 identity, which it is not. > > If the supplicant hasn't received an identity request, them I don't > see why the identity matters. What, precisely is the issue? Your > original message discussed why internal hostap data structures didn't > have the values that you expected. > > OK... what's the problem? What user-visible issues are there? If hostapd tries to reauth, users will get EAP-FAILURE/disconnected and have to reauthenticate. Unless the server is configured for wildcard phase1 identities of course. > > Alan DeKok. > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
