Hi, I have been using freeradius for many years now to authenticate WiFi users against active directory, and it all works perfectly. I am now trying to integrate it with the identity awareness built into our Checkpoint firewall system, this is able to take radius authentication packets and build a list of users against IP addresses. I understand that you can replicate the accounting data on from freeradius but for this to work obviously the WiFi client's IP address needs to be in the radius accounting data. At the moment it isn't because at the point when the accounting data is sent the client has not yet sent its DHCP request. Am I correct that to get the IP address into the radius accounting the freeradius server needs to be configured to send out the IP addresses rather than different DHCP server. If this is correct, could I create different IP pools to be used for each site, and have the correct IP data sent out for for different sets of wifi access points (NAS). Many thanks for reading this, I just want know I am going in the correct direction. Regards, Bruce Richardson -- This e-mail and any attachments are confidential and solely for the use of the intended recipient. They may contain material protected by legal professional or other privilege. If you receive it in error, please delete it from your system, make no copies of it, do not disclose its contents to any third party or use it for your own or any other person's benefit. Please advise the sender of its receipt as soon as possible. Although this email and its attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by the company for any loss or damage arising from receipt or use thereof. Any opinions expressed that do not relate to the official business of the company are those of the author, not the United Biscuits group of companies. United Biscuits (UK) Limited Registered in England number 2506007 Registered Office: Hayes Park, Hayes End Road, Hayes, Middlesex, UB4 8EE
Bruce Richardson wrote
I understand that you can replicate the accounting data on from freeradius but for this to work obviously the WiFi client's IP address needs to be in the radius accounting data. At the moment it isn't because at the point when the accounting data is sent the client has not yet sent its DHCP request.
Yes many such schemes put the cart before the horse.
Am I correct that to get the IP address into the radius accounting the freeradius server needs to be configured to send out the IP addresses rather than different DHCP server.
Depends on your NAS, and the firewall. As an alternative, some NAS units can send a status update accounting request after their DHCP-snooping or "ip device tracking" facilities notice an IP address. If the firewall will heed these you may be in luck. On some this works perfectly, on others you'll find that old authentication sessions stick around in the switch and continue to send these status updates even when the client has gone and moved to another port/NAS.
On 24 Mar 2014, at 15:12, Bruce Richardson <bruce_m_richardson@unitedbiscuits.com> wrote:
Hi,
I have been using freeradius for many years now to authenticate WiFi users against active directory, and it all works perfectly.
I am now trying to integrate it with the identity awareness built into our Checkpoint firewall system, this is able to take radius authentication packets and build a list of users against IP addresses.
I understand that you can replicate the accounting data on from freeradius but for this to work obviously the WiFi client's IP address needs to be in the radius accounting data. At the moment it isn't because at the point when the accounting data is sent the client has not yet sent its DHCP request.
Am I correct that to get the IP address into the radius accounting the freeradius server needs to be configured to send out the IP addresses rather than different DHCP server.
If this is correct, could I create different IP pools to be used for each site, and have the correct IP data sent out for for different sets of wifi access points (NAS).
Many thanks for reading this, I just want know I am going in the correct direction.
Usually this is a feature of the NAS which snoops the DHCP conversation between the client and the DHCP server, and adds it to Accounting-Requests (as the Framed-IP-Address) The only way I can really think of doing this, is to proxy accounting data through a server which has access to the lease database, which augments the Accounting-Requests with the current lease info. You could use Calling-Station-ID and the DHCP-Client-Hardware-Address to do the matching. It's open to various forms of subversion though... But no worse than DHCP-Snooping. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
The accounting start packet won't have an IP address. .. but the interim updates should have... depending on your NAS you might find an interim is fired out as soon as the client has a known address (ie before they need to go out through the firewall) Alan
I have been having fun implementing a SSO framework for Microsoft's NPS (when used as the EAP terminating RADIUS server)... but the project is on hold while I pester Microsoft for hotfixes: http://www.nicklowe.org/2013/08/nps-class-attribute-bug/ The generic requirements for your NASes are pretty high to do this properly. A few common pain points are: 1) The NAS MUST support RADIUS accounting for 802.1X authenticated sessions and sending interim updates. This should be obvious, but not all NASes that support 802.1X authentication via RADIUS support RADIUS accounting. 2) Where IPv4 is to be used, the NAS MUST support DHCPv4 snooping and use this information, and only from this source, to populate and include the Framed-IP-Address attribute with a client's IPv4 address in Interim-Update RADIUS accounting packets. A NAS must, of course, make a client's IPv4 address available for Single-Sign-On (SSO) to work in an environment where IPv4 has been deployed. For security reasons, it is imperative that only the information from the DHCPv4 snooping process be used as a source of address information. 3) Where IPv6 is to be used, the NAS MUST support DHCPv6 snooping and use this information, and only from this source, to populate and include Framed-IPv6-Address attributes with a client's IPv6 addresses in Interim-Update RADIUS accounting packets. A NAS must make a client's IPv6 addresses available for Single-Sign-On (SSO) to work in an environment where IPv6 has been deployed. For security reasons, it is imperative that only the information from the DHCPv6 snooping process be used as a source of address information. 4) Either the NAS MUST immediately send an RADIUS accounting Interim-Update packet when a client's IP address becomes known or changes after its DHCP process concludes. Or the NAS MUST send an Interim-Update RADIUS accounting packets at an interval that is sufficiently short that it ensures there is a minimal and acceptable delay before an Interim-Update packet is sent that contains the client's IP address. It is important that the client's IP address be made available in a timely manner. It is best where this is imperceptible to an end user and the load on a RADIUS server is kept to a minimum. It is best where the first approach is adopted. Conceptually, this is like polling vs. event based notification, the latter is nearly always better design where achievable. 5) The NAS SHOULD support sending Accounting-On and Accounting-Off RADIUS accounting packets. This allows expedient handling of stale sessions when a NAS is shutdown or restarted without requiring a timeout to kick in. 8) A NAS that supports handoff to another NAS MUST include an Acct-Multi-Session-Id attribute in the RADIUS accounting packets that are sent. The Acct-Multi-Session-Id attribute MAY be introduced within a session via an Interim-Update RADIUS accounting packet, but it MUST be sent before a handoff event occurs. Where roaming occurs, it is imperative that the connection can be tracked across the multiple RADIUS sessions that result. Otherwise, the previous session will be considered stale after a timeout and expunged. (The replacement session will usually be accounted without a corresponding authentication and authorisation exchange.) 8) A NAS SHOULD include the Event-Timestamp attribute and the Acct-Delay-Time attribute in all its RADIUS accounting packets. This allows determination to be made on the correct way to handle the event in context to the state of a session. 9) A NAS SHOULD support processing the User-Name attribute in RADIUS Access-Accept packets, overwriting the value used from the EAP outer identity if one is present. In Single-Sign-On systems, where the Authentication/Authorization process is opaque because there is no direct integration with it, it is necessary that the RADIUS server return the User-Name attribute with the client's real identity AND that the NAS support processing this in order to not end up with a deployment vulnerable to identity spoofing. Nick On Mon, Mar 24, 2014 at 11:12 PM, Bruce Richardson <bruce_m_richardson@unitedbiscuits.com> wrote:
Hi,
I have been using freeradius for many years now to authenticate WiFi users against active directory, and it all works perfectly.
I am now trying to integrate it with the identity awareness built into our Checkpoint firewall system, this is able to take radius authentication packets and build a list of users against IP addresses.
I understand that you can replicate the accounting data on from freeradius but for this to work obviously the WiFi client's IP address needs to be in the radius accounting data. At the moment it isn't because at the point when the accounting data is sent the client has not yet sent its DHCP request.
Am I correct that to get the IP address into the radius accounting the freeradius server needs to be configured to send out the IP addresses rather than different DHCP server.
If this is correct, could I create different IP pools to be used for each site, and have the correct IP data sent out for for different sets of wifi access points (NAS).
Many thanks for reading this, I just want know I am going in the correct direction.
Regards,
Bruce Richardson
This e-mail and any attachments are confidential and solely for the use of the intended recipient. They may contain material protected by legal professional or other privilege. If you receive it in error, please delete it from your system, make no copies of it, do not disclose its contents to any third party or use it for your own or any other person's benefit. Please advise the sender of its receipt as soon as possible. Although this email and its attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by the company for any loss or damage arising from receipt or use thereof. Any opinions expressed that do not relate to the official business of the company are those of the author, not the United Biscuits group of companies.
United Biscuits (UK) Limited Registered in England number 2506007 Registered Office: Hayes Park, Hayes End Road, Hayes, Middlesex, UB4 8EE
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I managed to bungle the numbering on those points! There are also complications when a NAS supports multiple interfaces, say a wireless access point offering service on the same SSID at 2.4 GHz and 5 GHz, and you get roaming from one to the other. If the Called-Station-ID isn't populated in a way that discriminates properly, you lose scoping. Nick
On 26 Mar 2014, at 07:48, Nick Lowe <nick.lowe@gmail.com> wrote:
I have been having fun implementing a SSO framework for Microsoft's NPS (when used as the EAP terminating RADIUS server)... but the project is on hold while I pester Microsoft for hotfixes:
Ok, but the requirements you list below appear to be specific to NPS. It's feature set is very limited. I'm sure you have a good reason for using NPS, but it's really not a good platform to do any sort of complex policy work. FreeRADIUS is significantly easier to integrate with arbitrary data sources.
http://www.nicklowe.org/2013/08/nps-class-attribute-bug/
The generic requirements for your NASes are pretty high to do this properly. A few common pain points are:
As you've not explicitly stated these are requirements for NPS, i'm going to respond as if they were general requirements for implementing SSO based on IP address.
1) The NAS MUST support RADIUS accounting for 802.1X authenticated sessions and sending interim updates.
This should be obvious, but not all NASes that support 802.1X authentication via RADIUS support RADIUS accounting.
You can always trigger the 'check whether session is active' process when you detect a duplicate login. In which case there's no need for accounting. You can periodically poll most NAS to see whether a session is still active. Most implement the standard 802.1X MIB even if they don't do RADIUS accounting.
2) Where IPv4 is to be used, the NAS MUST support DHCPv4 snooping and use this information, and only from this source, to populate and include the Framed-IP-Address attribute with a client's IPv4 address in Interim-Update RADIUS accounting packets.
Again not completely true, if you have an integrated DHCP and RADIUS server, or any DHCP server which makes the IP address of the client easily available, you can resolve the client's Mac-Address to a currently valid lease. The NAS does need to send the Calling-Station-ID, but almost all do.
A NAS must, of course, make a client's IPv4 address available for Single-Sign-On (SSO) to work in an environment where IPv4 has been deployed. For security reasons, it is imperative that only the information from the DHCPv4 snooping process be used as a source of address information.
Why? I can see it being imperative that the NAS must enforce the L2/L3 association, but it's not at all imperative that DHCP-Snooping is the source of address information. A NAS may support DHCP-Snooping/IP-Lockdown, but not include that info in Accounting-Requests.
3) Where IPv6 is to be used, the NAS MUST support DHCPv6 snooping and use this information, and only from this source, to populate and include Framed-IPv6-Address attributes with a client's IPv6 addresses in Interim-Update RADIUS accounting packets.
Again not true, this can come from the DHCP server itself. You just need the NAS to enforce the association between MAC and IP address to prevent someone ignoring the assigned IP/Prefix (more likely for V6).
A NAS must make a client's IPv6 addresses available for Single-Sign-On (SSO) to work in an environment where IPv6 has been deployed. For security reasons, it is imperative that only the information from the DHCPv6 snooping process be used as a source of address information.
Nope.
4) Either the NAS MUST immediately send an RADIUS accounting Interim-Update packet when a client's IP address becomes known or changes after its DHCP process concludes. Or the NAS MUST send an Interim-Update RADIUS accounting packets at an interval that is sufficiently short that it ensures there is a minimal and acceptable delay before an Interim-Update packet is sent that contains the client's IP address.
You do want an accounting-request to propagate through the system to interested parties, and yes it should be after the lease has been acquired, but it doesn't necessarily have to come from the NAS.
It is important that the client's IP address be made available in a timely manner. It is best where this is imperceptible to an end user and the load on a RADIUS server is kept to a minimum. It is best where the first approach is adopted. Conceptually, this is like polling vs. event based notification, the latter is nearly always better design where achievable.
DHCP server knows :)
5) The NAS SHOULD support sending Accounting-On and Accounting-Off RADIUS accounting packets.
This allows expedient handling of stale sessions when a NAS is shutdown or restarted without requiring a timeout to kick in.
Though in reality this isn't a huge issue. If your entire edge has DHCP-Snooping/IP-lockdown enabled there's no way someone can jump on a stale session.
8) A NAS that supports handoff to another NAS MUST include an Acct-Multi-Session-Id attribute in the RADIUS accounting packets that are sent. The Acct-Multi-Session-Id attribute MAY be introduced within a session via an Interim-Update RADIUS accounting packet, but it MUST be sent before a handoff event occurs.
Where roaming occurs, it is imperative that the connection can be tracked across the multiple RADIUS sessions that result. Otherwise, the previous session will be considered stale after a timeout and expunged. (The replacement session will usually be accounted without a corresponding authentication and authorisation exchange.)
This is only a limitation because of NPS's limited policy capabilities.
8) A NAS SHOULD include the Event-Timestamp attribute and the Acct-Delay-Time attribute in all its RADIUS accounting packets.
This allows determination to be made on the correct way to handle the event in context to the state of a session.
Sure.
9) A NAS SHOULD support processing the User-Name attribute in RADIUS Access-Accept packets, overwriting the value used from the EAP outer identity if one is present.
Or CUI, or you can use Class, or the Framed-IP-Address :)
In Single-Sign-On systems, where the Authentication/Authorization process is opaque because there is no direct integration with it, it is necessary that the RADIUS server return the User-Name attribute with the client's real identity AND that the NAS support processing this in order to not end up with a deployment vulnerable to identity spoofing.
Nah. There are so many ways to skin this particular cat, listing a bunch of requirements doesn't make that much sense. If you want to guarantee you'll get the system working then sure, but even some of the musts above, I can't see being a huge problem with NPS, if you really think how all the components interact. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Aran, Sorry, I should have been far more specific in what I wrote and less copy-and-paste hasty. Those requirements were written in the context that: 1) Integration would only be with RADIUS, not with the particular DHCP server that is in use on a site and not with SNMP back to the NASes. 2) Identity spoofing would not be able to occur via the EAP outer identity, given the first requirement. If you have that integration with DHCP and better yet with SNMP, as you point out, many of the requirements melt away. It was written with a bias that the solution be something that is easily deployable in existing environments and also with an NPS specific bias. If you can touch more of the stack, you have more options. So, apologies to the OP for not writing something more reasoned Regards, Nick
Nick Lowe wrote:
2) Identity spoofing would not be able to occur via the EAP outer identity, given the first requirement.
The outer identity is required to be anonymized in many EAP methods. So it should be "anonymous", or "anonymous@example.com", or "@example.com". Anything else is probably wrong. FreeRADIUS could arguably look for that, and issue warning messages if it wasn't seen. Alan DeKok.
To prevent identity spoofing in other dependent systems and make identity privacy explicit, I think it would be a very sensible default to make FreeRADIUS mandate that the user portion of the EAP outer-identity must be "anonymous" where the EAP outer-identity and inner-identity do not resolve to the same discrete user. Nick On Wed, Mar 26, 2014 at 9:45 PM, Alan DeKok <aland@deployingradius.com> wrote:
Nick Lowe wrote:
2) Identity spoofing would not be able to occur via the EAP outer identity, given the first requirement.
The outer identity is required to be anonymized in many EAP methods. So it should be "anonymous", or "anonymous@example.com", or "@example.com". Anything else is probably wrong.
FreeRADIUS could arguably look for that, and issue warning messages if it wasn't seen.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 26/03/14 14:33, Nick Lowe wrote:
To prevent identity spoofing in other dependent systems and make identity privacy explicit, I think it would be a very sensible default to make FreeRADIUS mandate that the user portion of the EAP outer-identity must be "anonymous" where the EAP outer-identity and inner-identity do not resolve to the same discrete user.
Well, the *default config* might mandate that by having a policy. But fairly obviously it shouldn't be hard-coded anywhere. FWIW I've seen lots of variations of a generic name as anonymous outer, not just the empty string or "anonymous". Trusting the outer ID is always wrong.
Sure, you would definitely want a list of approved user portions of outer identities and for this to be configurable. Who knows, somebody might have a real user called anonymous! I meant from a default configuration perspective, mandating that the user portion must be "anonymous" or resolve to the same discrete user. On Wed, Mar 26, 2014 at 11:14 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/03/14 14:33, Nick Lowe wrote:
To prevent identity spoofing in other dependent systems and make identity privacy explicit, I think it would be a very sensible default to make FreeRADIUS mandate that the user portion of the EAP outer-identity must be "anonymous" where the EAP outer-identity and inner-identity do not resolve to the same discrete user.
Well, the *default config* might mandate that by having a policy. But fairly obviously it shouldn't be hard-coded anywhere.
FWIW I've seen lots of variations of a generic name as anonymous outer, not just the empty string or "anonymous".
Trusting the outer ID is always wrong.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
To prevent identity spoofing in other dependent systems and make identity privacy explicit, I think it would be a very sensible default to make FreeRADIUS mandate that the user portion of the EAP outer-identity must be "anonymous" where the EAP outer-identity and inner-identity do not resolve to the same discrete user.
if you are the authenticator - ie the end RADIUS server and can see the inner and outer then you *could* do that - if you are just a remote proxy you'd never know...and thus cant enforce. however this is a bad idea...its not about 'spoofing' - its about anonymity. and the correct value should be NULL - ie '@realm.com' - as per the NAI spec. anyway, other technologies such as moonshot have already decreed anonymity for the outerID with blank userID and only realm populated...so if you enforce outer=inner your RADIUS server can never be used with moonshot (GSS-EAP) alan
Sure, I do mean only at the EAP terminating RADIUS server. And, yup, agreed a null/empty user portion should be acceptable too. It's actually better in many ways as it cannot collide with any genuine username as anonymous could - but pragmatically I think both null and "anonymous" would be needed by default. Nick On Wed, Mar 26, 2014 at 11:50 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
To prevent identity spoofing in other dependent systems and make identity privacy explicit, I think it would be a very sensible default to make FreeRADIUS mandate that the user portion of the EAP outer-identity must be "anonymous" where the EAP outer-identity and inner-identity do not resolve to the same discrete user.
if you are the authenticator - ie the end RADIUS server and can see the inner and outer then you *could* do that - if you are just a remote proxy you'd never know...and thus cant enforce.
however this is a bad idea...its not about 'spoofing' - its about anonymity. and the correct value should be NULL - ie '@realm.com' - as per the NAI spec.
anyway, other technologies such as moonshot have already decreed anonymity for the outerID with blank userID and only realm populated...so if you enforce outer=inner your RADIUS server can never be used with moonshot (GSS-EAP)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Nick Lowe wrote:
I have been having fun implementing a SSO framework for Microsoft's NPS (when used as the EAP terminating RADIUS server)... but the project is on hold while I pester Microsoft for hotfixes:
OK... some comments on that web page.
The format of the Class attribute that is generated by NPS is documented by Microsoft as follows:
That format is ridiculously complex, and serves no purpose. The Class should be just an opaque token. Any state should be maintained in a database. Having Class a complex structure means NPS is leaking private information to parties who have no business seeing it.
(Poor aspects of this format is that it is a predictable construction and is neither Base64 or UTF-8 encoded so therefore cannot be handled as text.
The Class attribute is an opaque binary blob. It is NOT text, and SHOULD NOT be treated as text by anyone.
It is also not possible to reliably and securely correlate Authentication/Authorization to Accounting based on the value of the Calling-Station-Id in an Access-Request,
You don't correlate auth/acct based on Calling-Station-Id. You do it on Class, or on Acct-Session-Id.
It is possible for roaming to occur after a session has started from an Access-Accept sent by the RADIUS server yet before the first Accounting-Start has been received, which would change the key and make correlation impossible.
If the APs allow roaming from one AP to another without re-authentication, then the APs are responsible for ensuring that the Acct-Session-Id is constant across all APs for one session, OR that the Class attribute is constant across all APs for one session. You CANNOT fix a broken AP in RADIUS. You can put band-aids on it, but nothing more.
Secondly, the User-Name attribute is sometimes rewritten in RADIUS proxying scenarios. This adds fragility where the authentication path is not fully controlled.
The User-Name attribute should not be re-written in proxying. This has historically been done, but it's a terrible idea. The new RFC (coming soon) which updates RFC 4282 says this.
Thirdly, not all NASes support processing the User-Name attribute where one is present in an Access-Accept packet so will continue to account with the EAP outer-identity.
Such NASes are unfortunately broken. They don't implement the RADIUS specs correctly. Sadly... there are many, many, NASes which don't implement RADIUS.
it is necessary either that:
1. The EAP terminating RADIUS server returns the User-Name attribute with the client’s real identity AND that the NASes support processing this attribute.
Which is a good idea. But as Arran pointed out, CUI is arguably the better choice.
2. The EAP terminating RADIUS server else mandates that the EAP outer-identity and EAP inner-identity resolve to the same discrete user, prohibiting the use of anonymous EAP outer-identities.
That will NEVER happen. Never, never, never. It's a terrible idea.
From a defense in depth perspective, it would also be beneficial to have the ability on the EAP terminating RADIUS server to constrain the EAP outer-identity so that the user portion of the User-Name must have the value “anonymous” where it does not resolve to the same discrete user represented by the EAP inner-identity.
That is a good idea.
Add functionality to allow NPS to be configured to mandate that the EAP outer-identity and inner-identity must resolve to the same discrete user. (Disabled by default.)
I don't think that will ever happen. It's a very bad idea. I'll poke my contacts at Microsoft about this. I know the people in charge of NPS, which always helps. It won't help your support ticket, but getting it prioritized at a political layer may be good. Alan DeKok.
OK... some comments on that web page.
Thanks very much for the comments Alan!
The format of the Class attribute that is generated by NPS is documented by Microsoft as follows:
That format is ridiculously complex, and serves no purpose. The Class should be just an opaque token. Any state should be maintained in a database. Having Class a complex structure means NPS is leaking private information to parties who have no business seeing it.
(Poor aspects of this format is that it is a predictable construction and is neither Base64 or UTF-8 encoded so therefore cannot be handled as text.
The Class attribute is an opaque binary blob. It is NOT text, and SHOULD NOT be treated as text by anyone.
Agreed, I am wrong here. I have revised the text in the blog post. I had meant purely from an ease of logging perspective, but then thinking about it, it should be the responsibility of whatever is logging to be able to handle it appropriately.
It is also not possible to reliably and securely correlate Authentication/Authorization to Accounting based on the value of the Calling-Station-Id in an Access-Request,
You don't correlate auth/acct based on Calling-Station-Id. You do it on Class, or on Acct-Session-Id.
I know, correlation of this nature was explored and dismissed only as a potential workaround in the full knowledge that it would be a hack, it was not viable. I have removed this from the text, however, as it serves no real purpose. Pragmatically, you cannot treat the Acct-Session-Id as being unique for a session in real world vendor heterogeneous environments, it is guaranteed to be unique only on a per-NAS basis and there is a theoretical risk of collision between vendors where they use a similar method of construction. I could not see any advice on its construction in the RADIUS RFCs? The Acct-Multi-Session-Id was meant to, and does, solve this surely? As some NASes will perform a fresh authentication and authorization exchange yet conceptually the user still has the same 'connection', I have supported roaming only where an Acct-Multi-Session-Id value is present and shouted at vendors where one has been missing and not used the Class attribute for this purpose.
It is possible for roaming to occur after a session has started from an Access-Accept sent by the RADIUS server yet before the first Accounting-Start has been received, which would change the key and make correlation impossible.
If the APs allow roaming from one AP to another without re-authentication, then the APs are responsible for ensuring that the Acct-Session-Id is constant across all APs for one session, OR that the Class attribute is constant across all APs for one session.
You CANNOT fix a broken AP in RADIUS. You can put band-aids on it, but nothing more.
I actually think use of the Acct-Multi-Session-Id is the correct solution here and there should be no requirement to persist the Acct-Session-Id.
Secondly, the User-Name attribute is sometimes rewritten in RADIUS proxying scenarios. This adds fragility where the authentication path is not fully controlled.
The User-Name attribute should not be re-written in proxying. This has historically been done, but it's a terrible idea. The new RFC (coming soon) which updates RFC 4282 says this.
Thirdly, not all NASes support processing the User-Name attribute where one is present in an Access-Accept packet so will continue to account with the EAP outer-identity.
Such NASes are unfortunately broken. They don't implement the RADIUS specs correctly. Sadly... there are many, many, NASes which don't implement RADIUS.
Should we make more of a concerted effort to call them out and open support cases over this?
it is necessary either that:
1. The EAP terminating RADIUS server returns the User-Name attribute with the client's real identity AND that the NASes support processing this attribute.
Which is a good idea. But as Arran pointed out, CUI is arguably the better choice.
Sure! Which NASes are you aware of that support the CUI attribute?
2. The EAP terminating RADIUS server else mandates that the EAP outer-identity and EAP inner-identity resolve to the same discrete user, prohibiting the use of anonymous EAP outer-identities.
That will NEVER happen. Never, never, never. It's a terrible idea.
Actually, I would have thought it can be a the better compromise choice in some deployment scenarios where experiencing identity spoofing in the dependent systems would be worse than breaking privacy. This happens where you have integrations that are not privy to anything but the User-Name attribute in RADIUS accounting packets.
From a defense in depth perspective, it would also be beneficial to have the ability on the EAP terminating RADIUS server to constrain the EAP outer-identity so that the user portion of the User-Name must have the value "anonymous" where it does not resolve to the same discrete user represented by the EAP inner-identity.
That is a good idea.
Add functionality to allow NPS to be configured to mandate that the EAP outer-identity and inner-identity must resolve to the same discrete user. (Disabled by default.)
I don't think that will ever happen. It's a very bad idea.
As above, it can be the best compromise choice when faced with identity spoofing vs privacy. I have updated the text to further push the idea that it is generally a bad idea.
I'll poke my contacts at Microsoft about this. I know the people in charge of NPS, which always helps. It won't help your support ticket, but getting it prioritized at a political layer may be good.
Thanks!
Nick Lowe wrote:
Pragmatically, you cannot treat the Acct-Session-Id as being unique for a session in real world vendor heterogeneous environments, it is guaranteed to be unique only on a per-NAS basis and there is a theoretical risk of collision between vendors where they use a similar method of construction. I could not see any advice on its construction in the RADIUS RFCs?
The RFCs are silent on a wide variety of topics. :(
The Acct-Multi-Session-Id was meant to, and does, solve this surely?
Nope. Acct-Multi-Session-Id handles IDs for multiple sessions. What does that mean? No one knows... the IETF RADIUS working group has had discussion on that topic, with no resolution.
As some NASes will perform a fresh authentication and authorization exchange yet conceptually the user still has the same 'connection',
No. Every re-auth is a new connection. Always. Anything else is madness.
I have supported roaming only where an Acct-Multi-Session-Id value is present and shouted at vendors where one has been missing and not used the Class attribute for this purpose.
Acct-Multi-Session-Id has no well-defined meaning. Most NASes don't support it.
Such NASes are unfortunately broken. They don't implement the RADIUS specs correctly. Sadly... there are many, many, NASes which don't implement RADIUS.
Should we make more of a concerted effort to call them out and open support cases over this?
Absolutely. I'd like to have Wiki pages saying "vendor X product Y firmware Z is broken". But much as people complain about docs, 1/100 people will update them.
Sure! Which NASes are you aware of that support the CUI attribute?
WiMAX ones. Alan DeKok.
Nope. Acct-Multi-Session-Id handles IDs for multiple sessions. What does that mean? No one knows... the IETF RADIUS working group has had discussion on that topic, with no resolution.
For 802.1X purposes, it is, I thought, pretty well defined in RFC 3580... No?
No. Every re-auth is a new connection. Always. Anything else is madness.
You have to correlate over these if you want to be able to limit the number of concurrent devices a user is allowed to have connected though, surely? Certainly NASes that implement the Acct-Multi-Session-Id support persist that value across re-authenication whether there is an authorisation exchange or not. Nick
Nick Lowe wrote:
Nope. Acct-Multi-Session-Id handles IDs for multiple sessions. What does that mean? No one knows... the IETF RADIUS working group has had discussion on that topic, with no resolution.
For 802.1X purposes, it is, I thought, pretty well defined in RFC 3580... No?
The document has text. I'm not sure anyone implements it.
No. Every re-auth is a new connection. Always. Anything else is madness.
You have to correlate over these if you want to be able to limit the number of concurrent devices a user is allowed to have connected though, surely?
Each session should contain information about the device. That can be used to terminate old sessions, and move them to the new AP.
Certainly NASes that implement the Acct-Multi-Session-Id support persist that value across re-authenication whether there is an authorisation exchange or not.
RFC 3580 says that the Multi-Session-Id is used where there is no re-authentication. If there's no re-authentication, there's no authorization exchange. Alan DeKok.
Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP). How/where does RFC 3580 preclude it being used when reauthentication occurs? It just says it may be used "without a corresponding authentication and authorization exchange"? I would argue it really must stick over a reauthentication to work properly... Nick On Thu, Mar 27, 2014 at 2:12 AM, Alan DeKok <aland@deployingradius.com> wrote:
Nick Lowe wrote:
Nope. Acct-Multi-Session-Id handles IDs for multiple sessions. What does that mean? No one knows... the IETF RADIUS working group has had discussion on that topic, with no resolution.
For 802.1X purposes, it is, I thought, pretty well defined in RFC 3580... No?
The document has text. I'm not sure anyone implements it.
No. Every re-auth is a new connection. Always. Anything else is madness.
You have to correlate over these if you want to be able to limit the number of concurrent devices a user is allowed to have connected though, surely?
Each session should contain information about the device. That can be used to terminate old sessions, and move them to the new AP.
Certainly NASes that implement the Acct-Multi-Session-Id support persist that value across re-authenication whether there is an authorisation exchange or not.
RFC 3580 says that the Multi-Session-Id is used where there is no re-authentication. If there's no re-authentication, there's no authorization exchange.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Nick Lowe wrote:
How/where does RFC 3580 preclude it being used when reauthentication occurs? It just says it may be used "without a corresponding authentication and authorization exchange"? I would argue it really must stick over a reauthentication to work properly...
I'd suggest it should use a re-authentication. Alan DeKok.
Hi, I'm pondering how this works with IPv6 and anonymous addressing where I'm changing my address every hour or so...but ALSO keeping my old address whilst there are still sessions persisting with it...what do the Acct interim updates reveal...would the firewall/IDS/IPS/traffic shaper add these to my identity...or drop/block etc my old addresses if only the new address is conveyed? :) I probably already know the answer to some of these things...but havent had the time to dig around other aspects (dont have the kit to try it with) alan
A.L.M.Buxey@lboro.ac.uk wrote:
I'm pondering how this works with IPv6 and anonymous addressing where I'm changing my address every hour or so
As with anything RADIUS, badly.
...but ALSO keeping my old address whilst there are still sessions persisting with it...what do the Acct interim updates reveal...would the firewall/IDS/IPS/traffic shaper add these to my identity...or drop/block etc my old addresses if only the new address is conveyed? :)
IMHO, the interim updates should include information about the user, which is known by the NAS. Exactly how that's done is... complicated. Alan DeKok.
Nick Lowe wrote:
1. The EAP terminating RADIUS server returns the User-Name attribute with the client?s real identity AND that the NASes support processing this attribute.
Alan DeKok wrote:
Which is a good idea. But as Arran pointed out, CUI is arguably the better choice.
Agreed.
2. The EAP terminating RADIUS server else mandates that the EAP outer-identity and EAP inner-identity resolve to the same discrete user, prohibiting the use of anonymous EAP outer-identities.
That will NEVER happen. Never, never, never. It's a terrible idea.
Here I dare to respectfully disagree (at least for the moment being :). There needs to be a way for (EDUROAM terminology used) the Service Provider to block a particular roaming identity access to their NAS, should such a need occur (and not a whole realm), in a timely fashion. For roaming users, SPs are typically exposed only to the outer identity through accounting of their local RADIUS server that the roaming identity uses for proxying. For me, it has two outcomes: it would require all EDUROAM IdPs to either a) mandate use of CUI (preferrably, but I cannot somehow recall how a third party could check whether particular IdP provides CUI on their terminating RADIUS server(s), or b) mandate same inner and outer identity, as suggested by Nick. AFAIK, some EDUROAM IdPs (that do not implement CUI) actually do this as a favor for any other EDUROAM participating SP so that (based on the outter identity of abusive roaming user gathered from local NAS accounting) they can immediately: 1) identify the roaming abuser, and 2) lock him/her out on their proxying RADIUS until his/her home IdP takes an action IIRC, there is a nice document describing the problem from SP sysadmin perspective (see paragraph 2.1): https://www.eduroam.org/downloads/docs/GN2-08-243-DJ5-4-1-2_Advanced_Technol... With kind regards, Jan Rafaj
Jan Rafaj wrote:
There needs to be a way for (EDUROAM terminology used) the Service Provider to block a particular roaming identity access to their NAS, should such a need occur (and not a whole realm), in a timely fashion. For roaming users, SPs are typically exposed only to the outer identity through accounting of their local RADIUS server that the roaming identity uses for proxying.
That requirement conflicts with everyone *else's* requirement that the outer ID be anonymized.
For me, it has two outcomes: it would require all EDUROAM IdPs to either a) mandate use of CUI (preferrably, but I cannot somehow recall how a third party could check whether particular IdP provides CUI on their terminating RADIUS server(s),
It can't.
b) mandate same inner and outer identity, as suggested by Nick. AFAIK, some EDUROAM IdPs (that do not implement CUI) actually do this as a favor for any other EDUROAM participating SP so that (based on the outter identity of abusive roaming user gathered from local NAS accounting) they can immediately: 1) identify the roaming abuser, and 2) lock him/her out on their proxying RADIUS until his/her home IdP takes an action
That's definitely useful. But not needed for everyone else. Alan DeKok.
a) mandate use of CUI (preferrably, but I >cannot somehow recall how a third party could check whether >particular IdP provides CUI on their terminating RADIUS server(s), or
The service provider SP requests a CUI during the authentication. If the IdP doesn't provide one with the access accept then they don't provide CUI whilst there are many many sites that have solutions that can't do CUI it is not feasible to make it mandatory. For other technology like moonshot, since the only solutions out there *can* do CUI it is possible to make it mandatory. alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Julin -
Bruce Richardson -
Jan Rafaj -
Nick Lowe -
Phil Mayers