different user names for the same session

[Jouni Malinen]

On Thu, Nov 13, 2008 at 11:05:37PM +0100, Alan DeKok wrote:

>   But... there's no "re-authentication" in RADIUS.  Unless there is a
> State attribute that ties an Access-Accept to a previous session, the
> two sessions are completely unrelated.
> 
>   If you choose to re-authenticate before your earlier session expires,
> that's nice.  But it's semantically the same as dialing in on a
> *different* line, and then hanging up on the first one.

RFC 3580, Chapter 2.1 seems to indicate that the re-authentication case
in IEEE 802.11 does not result in termination of the session and there
are to be no accounting packets in this case. This does not seem to
match with your interpretation on what would happen on
re-authentication.

>   IMHO, the only way the two sessions can be the "same" is if the RADIUS
> server returns the first Acct-Session-Id in the second Access-Accept.
> This tells the NAS to re-use that Acct-Session-Id for the second
> session.  If this doesn't happen, then the NAS *should* invent a new
> Acct-Session-Id.

The way I read RFC 3580 results in different behavior. RFC 3580 is only
informational, but taken into account that I don't see clear definition
for this particular case in RFC 2865 or RFC 2866, the closest thing I
can find in RFCs describing this particular case is the following
paragraph from RFC 3580:

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

Consequently, I do not see an IEEE 802.11 AP could invent a new
Acct-Session-Id while following the behavior described here.

-- 
Jouni Malinen                                            PGP id EFC895FA