Jouni Malinen wrote:
The following RFC 3580 Chapter 2.1 text is one reason for hostapd behavipr:
Hmm... OK.
As far as I can tell, that is describing multiple re-authentications for a single RADIUS session. Should the Supplicant decide to change its identity (e.g., switch between user and machine credentials) without stopping the session (disassociate/EAPOL-Logoff), I don't see how the Authenticator (NAS) should handle this case.
That's really a problem with RADIUS. There is no definition of what defines a "session".
It sounds like you are asking to arbitrarily pick the first identity (or create a new session, which would not comply with this RFC 3850 text) while hostapd is arbitrarily picking the last used identity within the same session.
Look at it from the point of view of the RADIUS server, or the administrator running it. A session starts, with a particular User-Name, an Acct-Session-Id, and a bunch of other attributes "identifying" the session. Then at some later point, the same Acct-Session-Id is used with a *different* set of attributes "identifying" the session. This is confusing. The administrator *cannot* rely on Acct-Session-Id to uniquely identify sessions, and then ignore other attributes such as User-Name. There are just too many broken NASes that send the same Acct-Session-Id for completely independent sessions. So... the administrator has to rely on a *collection* of attributes as "identifying" the session. That collection traditionally includes User-Name. This means that changing User-Name in the middle of a "session" will wreak havoc with people's accounting setups. The NAS, of course, is stuck in the middle here. If the supplicant suddenly changes it's EAP identity on re-authentication, it's not unreasonable for the NAS to simply copy that into the User-Name attribute. But this means that the supplicant is broken (IMHO). If the supplicant can't keep the same identity during a session, that seems very strange to me. Alan DeKok.