Cannot lookup EAP user on reauthentication (PEAP/TTLS)

[Alan DeKok]

On May 27, 2022, at 1:06 PM, James Prestwood <prestwoj at gmail.com> 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.

> 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.

  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.

  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?

  Alan DeKok.