PATCH: identity change while reauth

[Gunter Burchardt]

On 2004-07-29 - 21:21:38, Jouni Malinen wrote:
> Date: Thu, 29 Jul 2004 21:21:38 -0700
> From: Jouni Malinen <jkmaline at cc.hut.fi>
> To: hostap at shmoo.com
> Mail-Followup-To: hostap at shmoo.com
> Subject: Re: PATCH: identity change while reauth
> 
> On Thu, Jul 29, 2004 at 09:52:37AM +0200, Gunter Burchardt wrote:
> 
> > I found a problem with reauthentication. While reauthentication a user
> > can answer to the identity request with an other identity as in first
> > request. hostapd saves the new identity and lost the old one. As a
> > result all accounting request will be send with the new identity. The
> > traffic statistic is commulated with the traffic of the first identity.
> 
> Hmm.. How is the accounting session defined? hostapd is currently
> mapping each IEEE 802.11 association to an accounting session. Can you
> point me to a standard that defines that changing identity in EAP
> authentication should be considered to always terminate the accounting
> session?

RFC2866 says:

   session   Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record with
             its own Acct-Session-Id.

The problem is that hostapd has the same sessionid for two different
users. Im a bit unlucky to match a accounting session with a 802.11
session, 802.1x would be better to avoid such problems. But its hard to
implement this with valid accounting data (bytes and packtes).

> > Ok, someone could say that a radius-server could reject the
> > access-request from the ap with an opened session with same NAS-PORT
> > but other identity, but this would be only a workaround. hostap should
> > close the old session and open a new one. In this way the old session
> > is closed in the right way (Accounting-Stop packet) and the user didnt
> > get a reject with a valid authentication.
> 
> I would agree with the part that if this is the desired functionality,
> it should be done in the Authenticator. However, is IEEE 802.11
> deauthentication the correct way of doing this? One option would be to
> send Accounting-Stop and still continue the new IEEE 802.1X/EAP
> authentication without disassociating (and finally generate
> Accounting-Start if the authentication completes successfully).

Additionaly with a new SessionID! But how to clear the accounting data?
hostap driver hasn't (yet) an interface to clear these counters. I will
implement this in this way and send you a patch. If identity changes
hostapd will do:

 * accounting stop
 * clear acct counters (command to driver)
 * generate new sessionid
 * accounting start

Did I miss someting?
(By the way: Closing 802.11 session does the same things)

> > +		/* check whether identity has changed */
> > +		if (sta->acct_session_started &&
> > +			((sm->identity_len != len) || 
> > +			 (memcmp(sm->identity,data,
> > +				(len<sm->identity_len?len:sm->identity_len)) != 0))) {
> 
> sm->identity_len == len if the memcmp() is being run, so there is no
> point in verifying again whether len < sm->identity_len..

OK

regards
gunter