>The following RFC 3580 Chapter 2.1 text is one reason for hostapd behavipr:
>
> "Within [IEEE80211], periodic re-authentication may be useful in
> preventing reuse of an initialization vector with a given key. Since
> successful re-authentication does not result in termination of the
> session, accounting packets are not sent as a result of
> re-authentication unless the status of the session changes. For
> example:"
>
>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. 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)
Really?
b. The authorizations are changed as a result of a successful
re-authentication. In this case, the Service Unavailable (15)
termination cause is used. For accounting purposes, the portion
of the session after the authorization change is treated as a
separate session.
It would be quite reasonable to interpret change of user credentials as
change of authorization.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
