Jouni Malinen wrote:
On Thu, Nov 13, 2008 at 9:22 PM, <tnt@kalik.net> wrote:
http://freeradius.org/rfc/rfc2865.html#User-Name
"It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session."
And which Access-Accept would this be referring to?
The specs are a little silent on this issue. However... One Access-Accept is pretty much one accounting session. Re-using the same Acct-Session-Id across multiple sessions is very bad. Very, very, bad. Very, very, very, bad. I really can't emphasize that enough.
The problem here is that there can be multiple authentication runs (re-authentication based on supplicant request or authenticator policy) and should the supplicant change its identity, the second Access-Accept is likely to have a different identity in that case.
There is no such thing as "multiple authentication runs" in RADIUS. Each authentication is completely independent of all other authentications. (Barring some CoA issues where State is used to tie sessions together.)
While it may be reasonable to arbitrarily decide to use User-Name (if present) from the first Access-Accept, it does not sound like that good of an idea for a RADIUS server to depend on this behavior based on current RADIUS RFCs.
The issue is less User-Name than Acct-Session-Id. From RFC 2866: 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. Individual sessions have their own Acct-Session-Id. Creating unique Acct-Session-Id's is MUCH less of an issue than re-using them. i.e. If Acct-Session-Id is something like MD5(session start time + User-Name + NAS-IP-Address), you will VERY likely not run into problems. If you re-use Acct-Session-Id... EVER, then you will have people hunting you with pitchforks. Please don't re-use Acct-Session-Id. Ever. Alan DeKok.