On Fri, 2022-05-27 at 16:35 -0400, Alan DeKok wrote: > On May 27, 2022, at 4:09 PM, James Prestwood <prestwoj at gmail.com> > wrote: > > > 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. > > I don't see why it's looking up any identity. The identity in the > EAP packet doesn't matter. And your first message said that hostap > was doing lookups before it had any identity from the supplicant. It's not exactly looking up the identity, eap_sm_Policy_getDecision() uses the identity to look up the list of EAP methods for the client. It's using the wrong saved identity for that lookup though, nothing to do with the RFC. If your user database (hostapd.eap_user) file was something like: "anonymous" PEAP "non-anonymous" MD5 "password" [2] ...then after a successful initial EAP-PEAP+EAP-MD5 authentication, the reauthentication will fail because hostapd will have cached "non-anonymous" in sm->identity. It will try to find a phase 1 method for this identity but there's only a phase 2 method allowed by the user database. eap_sm_Policy_getDecision() fails with DECISION_FAILURE like James said. eap_server_peap.c/eap_server_ttls.c may need to be modified to store the inner identities inside eap_{peap,ttls}_data, or in a new eap_sm field to avoid overwriting eap_sm.identity. Best regards _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap