Cannot lookup EAP user on reauthentication (PEAP/TTLS)

Andrew Zaborowski balrogg at googlemail.com
Wed Jun 1 10:33:02 PDT 2022


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



More information about the Hostap mailing list