On May 27, 2022, at 4:09 PM, James Prestwood <prestwoj@xxxxxxxxx> 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. > 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. > 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. 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@xxxxxxxxxxx". 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. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
