Cannot lookup EAP user on reauthentication (PEAP/TTLS)
prestwoj at gmail.com
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 gmail.com>
> > 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
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