Cannot lookup EAP user on reauthentication (PEAP/TTLS)

James Prestwood prestwoj at
Fri May 27 13:09:54 PDT 2022

On Fri, 2022-05-27 at 14:09 -0400, Alan DeKok wrote:
> On May 27, 2022, at 1:06 PM, James Prestwood <prestwoj at>
> 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

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.

More information about the Hostap mailing list