Dropping NAS-Port AVP from Acct-Unique-Session-Id by default
I noticed looking through the commits in FreeRADIUS 3.1 that the Acct-Unique-Session-Id is now using the Acct-Multi-Session-Id in its construction. Awesome! :) I wondered while looking at the commit if there has been consideration about dropping the NAS-Port in the construction so that FreeRADIUS interoperates, in its default configuration, with wireless controllers that keep the same Acct-Session-Id when a roam occurs from one BSS/AP to another BSS/AP? In that scenario, it is, of course, the controller that is the NAS, not the APs. Some controllers set the value of the NAS-Port attribute on per AP or BSS basis and this therefore changes where a roam occurs. In my opinion, vendors should be sending a Stop and a Start when a roam occurs with a constant Acct-Multi-Session-Id being used to allow sessions to be correlated, but this not the case today. This has been written about by others too: http://daniele.albrizio.it/how-to_/freeradiusacct-unique-session-idfix I was looking in to this area of FreeRADIUS more closely as I have been engaging with Aerohive on their Acct-Session-Ids. The upcoming HiveOS releases will have Acct-Session-Ids that have the properties of a GUID/UUID. At the moment, they're just incremented and are therefore not guaranteed to be unique across reboots. Cheers, Nick Lowe
Food for thought.... What is the expected behaviour with Class attributes in accounting when 802.1X re-authentication occurs? The clients association/connection is not terminated, so, should we expect to see a Stop and a Start for the session? With many NASes I have empirically observed that we do not see this. In my opinion, we should not. In the case that accounting for the session carries on without a Stop and a Start, should then a NAS update the value of the Class attribute(s) that it accounts with based on new value(s) returned in the Access-Accept? In my opinion, yes, it should. I am not convinced therefore that the Class attribute should ever be used as part of a unique session key therefore. A unique session key redoes what the Acct-Session-Id should be doing in the first place because of NAS deficiencies. My thoughts are that the default behaviour in FreeRADIUS should always be: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Multi-Session-ID},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier}}" I also should have mentioned before, that the NAS-Port-Id should be dropped too in addition to the NAS-Port. Thoughts? Nick
On Sep 18, 2015, at 6:43 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
What is the expected behaviour with Class attributes in accounting when 802.1X re-authentication occurs?
Class is for linking Access-Accept to subsequent Accounting-Request packets. It is not sent in later Access-Request packets.
The clients association/connection is not terminated, so, should we expect to see a Stop and a Start for the session? With many NASes I have empirically observed that we do not see this. In my opinion, we should not.
The RFCs are unfortunately silent on this topic.
In the case that accounting for the session carries on without a Stop and a Start, should then a NAS update the value of the Class attribute(s) that it accounts with based on new value(s) returned in the Access-Accept? In my opinion, yes, it should.
The RFCs are unfortunately silent on this topic.
I am not convinced therefore that the Class attribute should ever be used as part of a unique session key therefore.
Maybe. Since you control the Class attribute, you can send back the *same* Class in the second (and later) authentications.
A unique session key redoes what the Acct-Session-Id should be doing in the first place because of NAS deficiencies.
Yes. My $0.02 is that the Acct-Session-Id should probably be sent back by the RADIUS server in the Access-Accept. That way it's under the control of software which is properly written. But that's not going to happen.
My thoughts are that the default behaviour in FreeRADIUS should always be:
&Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Multi-Session-ID},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier}}"
I also should have mentioned before, that the NAS-Port-Id should be dropped too in addition to the NAS-Port.
Those are there for dial-up or DSL concentrators. They're useful for some people, and need to stay in. You're free to make changes to your local config, of course. Alan DeKok.
I am not convinced therefore that the Class attribute should ever be used as part of a unique session key therefore.
Maybe. Since you control the Class attribute, you can send back the *same* Class in the second (and later) authentications.
I didn't think we could reliably know at the RADIUS sever if it's a new authentication or a re-authentication taking place? In the case that it's a new authentication, we would want a different Class attribute so that binding from auth to accounting is reliable. Definitely an area where we could do with clarification in the spec. Hmm :( Regards, Nick
On Sep 18, 2015, at 8:15 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
I didn't think we could reliably know at the RADIUS sever if it's a new authentication or a re-authentication taking place?
You can tell if the EAP session is being resumed. You can tell if the EAP session is coming from the same MAC, AP, etc.
Definitely an area where we could do with clarification in the spec. Hmm :(
The IETF operates at a speed which sometimes outruns glaciers. I've been talking with a few people about just writing our own "best practice" documents and putting them on the FreeRADIUS web site. If we can get multiple vendors to buy into the idea, we can create our own de facto standards. Alan DeKok.
Sure, but EAP session resumption taking place is not required for 802.1X reauth, so cannot be relied upon. I'd always be loathed to use MAC addresses for anything like this as they're not a secure principle, not being cryptographically bound to anything.
On Sep 18, 2015, at 8:30 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Sure, but EAP session resumption taking place is not required for 802.1X reauth, so cannot be relied upon.
When you say "reauth", it could mean multiple things. Session resumption is re-authenticating the same session. Without session resumption, it's not "re" authentication. It's just another authentication which HAPPENS to be from the same client and to the same AP. Which you can detect by looking at the accounting table, and seeing that all of the session identification information is the same.
I'd always be loathed to use MAC addresses for anything like this as they're not a secure principle, not being cryptographically bound to anything.
You don't have to believe the MAC address. You CAN believe the AP IP, the AP Mac, etc. And you CAN believe the MAC address if it's the same as the last time. :) Remember, you don't just have the current authentication. You have the accounting information from previous sessions. So... cross-check the new session against the previous one. If the data is the same... it's likely the same person re-authenticating. Alan DeKok.
Hi Alan, I meant what RFC 3580 says here. Instructing a NAS to re-authenticate via a Termination-Action AVP of RADIUS-Request and a Session-Timeout AVP being supplied in the Access-Accept. That is entirely decoupled to EAP session resumption. It is in this case that NASes are observed not sending a Stop and a Start, which I believe is semantically correct. 3.17. Session-Timeout When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination. When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re- authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X. When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed. When sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X. 3.19. Termination-Action This attribute indicates what action should be taken when the service is completed. The value RADIUS-Request (1) indicates that re- authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate.
On Sep 18, 2015, at 9:26 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
I meant what RFC 3580 says here. Instructing a NAS to re-authenticate via a Termination-Action AVP of RADIUS-Request and a Session-Timeout AVP being supplied in the Access-Accept.
You're getting caught up in terminology, and are ignoring my comments.
That is entirely decoupled to EAP session resumption.
Not entirely... EAP session resumption can be used during a re-authentication. In which case you know it's the same user as before. If EAP session resumption isn't used, you can still look at the *other* data, and tell that it's the same user, same MAC, and same AP. Since you control Class, you can send the same Class back for the re-authenticated session. And therefore the "unique" accounting session ID will be the same. don't know what point you're trying to make. Please explain your point, instead of quoting RFCs about re-authentication. I can read the RFCs. I can't read your mind.
It is in this case that NASes are observed not sending a Stop and a Start, which I believe is semantically correct.
As I said, the RFCs are silent on this issue. There is no way to tell if this behaviour is correct or incorrect. Alan DeKok.
Yes, of course it can be used but the point that I was trying to make is that it is decoupled/unrelated because it is not required. Full EAP auth can-and-does take place during re-authentication for some clients, often depending on config. It occurs at a different layer of abstraction. (This is secure and reliable where it does take place.) The User-Name and the Calling-Station-Id are values supplied by a client so they cannot be blindly trusted. Another STA/client can spoof these which would conceptually result in the same Class attribute being returned. It is fundamentally something that is not a robust primitive to be relied upon therefore. Regards, Nick
Sorry, should clarify that it would only be the outer identity that can be spoofed so this isn't an issue. Just thought it through properly. *grin* :)
Definitely an area where we could do with clarification in the spec. Hmm :(
The IETF operates at a speed which sometimes outruns glaciers.
I've been talking with a few people about just writing our own "best practice" documents and putting them on the FreeRADIUS web site. If we can get multiple vendors to buy into the idea, we can create our own de facto standards.
That would be really awesome!
My thoughts are that the default behaviour in FreeRADIUS should always be:
&Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Multi-Session-ID},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier}}"
I also should have mentioned before, that the NAS-Port-Id should be dropped too in addition to the NAS-Port.
Those are there for dial-up or DSL concentrators. They're useful for some people, and need to stay in.
You're free to make changes to your local config, of course.
Of course, but that pushes the complexity of understanding all this on the administrator. I wonder if a better approach here would therefore be a configuration ability to easily specify intent somehow and somewhere. Intent being specifying, for typical deployment scenarios, that you're doing wired/wireless 802.1X or instead something with dial-up /DSL concentrators. Different behaviour is optimal in these diverged use case scenarios.
On Sep 18, 2015, at 8:36 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
You're free to make changes to your local config, of course.
Of course, but that pushes the complexity of understanding all this on the administrator.
I'm happy to update the server with more examples. I will NOT break the default configuration so that it works "better" for one set of users, at the expense of another set of users. It's OK for you to not need NAS-Port in Acct-Unique-Session-Id. But other people need it there.
I wonder if a better approach here would therefore be a configuration ability to easily specify intent somehow and somewhere.
Be my guest. That's very hard, tho.
Intent being specifying, for typical deployment scenarios, that you're doing wired/wireless 802.1X or instead something with dial-up /DSL concentrators.
Different behaviour is optimal in these diverged use case scenarios.
Yes. And how do you tell which scenario is which? You edit your local configuration. It is almost impossible to set up the default configuration to automatically detect these things. There are just too many unknowns. Alan DeKok.
And how do you tell which scenario is which? You edit your local configuration.
You do edit the config. but at the moment you have to understand all the AVPs and what they do here rather than expressing a higher level, easy to understand intent to FR. It's complexity that most administrators won't grasp IMO. I wasn't suggesting automatically detecting anything. Cheers, Nick
Hi,
And how do you tell which scenario is which? You edit your local configuration.
You do edit the config. but at the moment you have to understand all the AVPs and what they do here rather than expressing a higher level, easy to understand intent to FR. It's complexity that most administrators won't grasp IMO.
examples work here - eg some pretty good starting templates for eg SQL logging... where dealing with broken NAS kit is already handled by default. oh! your using Aeohive or Aruba or Cisco etc etc THIS is the accounting SQL config you should start with - needs feedback and input from people using such kit in anger your case with this attribute and accounting is a prime example of this. alan
Hi,
I will NOT break the default configuration so that it works "better" for one set of users, at the expense of another set of users. It's OK for you to not need NAS-Port in Acct-Unique-Session-Id. But other people need it there.
t'is true - but some people ave it with it making no difference...hello Cisco LWAPP/CAPWAP people who'll find their NAS-Port is always 19 or 29 (depending on firmware release version ;-) )
Intent being specifying, for typical deployment scenarios, that you're doing wired/wireless 802.1X or instead something with dial-up /DSL concentrators.
thats where something like a managed service/applicance kicks in with Wizards and various other thigns to completely tweak the configuration. what if I use my RADIUS server for more than 1 task (as I do?) :-)
It is almost impossible to set up the default configuration to automatically detect these things. There are just too many unknowns.
something I'm looking at is some further examples that will help the initial install. people are then free to choose to use such virtual-servers or module configs.... alan
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Nick Lowe