different user names for the same session

[Saber Zrelli]

Hi,

On Fri, Nov 14, 2008 at 7:27 AM, Jouni Malinen <j at w1.fi> wrote:
> 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."

RFC 3580 also says :

      accounting packets are not sent as a result of
      re-authentication unless the status of the session changes.  For
      example:

   [...]

      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.

When the peer re-authenticates successfully using a new Identity, IMHO
that means that the new identity was authorized to access the network.
Probably, new QoS parameters are also set for the session after
re-authentication with the new identity. For this reason, IMHO, it
makes sense to terminate the ongoing accounting session and start a
new one.

regards,
saber.



>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>