Alan DeKok wrote:
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.
For what it's worth - the cisco lightweight wireless platform does the same thing (changes the username) and as you say, it's confusing. IMHO it's annoying and wrong. It renders the accounting much, much less useful for the legal purposes one might use it for i.e. identifying mis-use. I think it's a mistake to conflate the wireless association with an 802.1x session. It also seems clear to me that the passage referenced in RFC 3580, when it says "status of the session", really ought to include the username - if that's not part of the status, I don't know what is.