Cannot lookup EAP user on reauthentication (PEAP/TTLS)

[James Prestwood]

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.

I believe its looking it up directly from the reauth command:

 - STA authenticates, everything is well.
 - At some point hostapd is told to reauthenticate: EAPOL_REAUTH <sta-
addr>
 - Hostapd gets this message and the only context it has is the station
address. So it first looks up this station object by address.
 - The found station object then points to an eapol_sm object which has
the EAP identity stored in it. This is the identity used to find the
EAP user/session which probably contains the TLS session key you're
talking about.

And you're right, I'm not sure why it needs to look up the identity at
this point. It could just send an identity request to the station, wait
for whatever identity is sent back, and use that for the lookup. This
would put the burden on the station to send the correct identity. But
in any case, this is what it does.

I'm betting there is more to it, because this seems like a lot of
additional work rather than just sending an identity request.

> 
> > 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.
> 
>   That seems wrong on a number of levels.  The identities shouldn't
> be the same, of course.  But I don't see why hostap needs the
> identity before it gets any packets from the supplicant.

No idea either.

> 
> > yep, and this is the identity being used for the lookup. But with
> > the
> > assumption that its a phase1 identity, which it is not.
> 
>   My point was that any cached data should be looked up based on the
> TLS session key.
> 
> > > 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.
> 
>   Again, the phase1 identities don't matter for TTLS / PEAP  etc. 
> The server should just allow for re-authentication.  Then, the server
> should use the TLS session data to look up in a cache to see what was
> in the users original session.
> 
>   I think you're looking at it from what hostap does right now, and
> trying to find a way to poke it to "make it work".  I think that's
> the wrong approach.

I don't agree. But I'll keep an open mind :) Maybe there is something
I'm not seeing as to why the lookup is done so early in the first
place, and why its hard coded to use the phase1 identity.


> 
>   hostap may need to key sessions off of identities for non-TLS EAP
> types.  But for TLS, there's just no point.  As you've seen here, it
> causes issues.  Instead, it should track TLS sessions, and then
> compare the cached session data to what it gets from the current EAP
> re-authentication attempt.
> 
>   That way a user can authenticate on ethernet port 1, and then
> resume the session on ethernet port 2.  The user can also use an
> anonymous outer identity to authenticate TTLS (e.g. "@example.com")
> and then resume the session using a PSK identity
> "PSK-4924727497 at example.com".
> 
>   None of the port / identity changes matter.  What matters is that
> the user has the correct cryptographic keys / data.  That data ties
> the resumed session to the original one.
> 
>   That data can then be used to determine the original inner && outer
> identity.  Having a cache keyed off of identity just won't work with
> TLS.
> 
>   Alan DeKok.
>