Question about cui.post-auth in FR 3
Hi, I've just spotted something that I'm not entirely sure is right: I get a reply from another host and it feeds back into my post-auth section. I happen to have the 'cui' module set in it. The existing 'cui' policy will strip the User-Name property regardless of whether the conditions for the CUI were met or not, is that correct? Shouldn't it strip the User-Name only if a CUI was generated? I'm just wondering... Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Stefan Paetow wrote:
I get a reply from another host and it feeds back into my post-auth section. I happen to have the ‘cui’ module set in it. The existing ‘cui’ policy will strip the User-Name property regardless of whether the conditions for the CUI were met or not, is that correct?
Yes.
Shouldn’t it strip the User-Name only if a CUI was generated?
Yes. Alan DeKok.
Shouldn’t it strip the User-Name only if a CUI was generated? Yes.
Ok, I'll submit a pull request if you haven't already fixed it ;-) Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Hi,
Shouldn’t it strip the User-Name only if a CUI was generated? Yes.
Ok, I'll submit a pull request if you haven't already fixed it ;-)
hi, I seem to have missed somethign here. when did this change to strip the User-Name if theres a CUI come into being? thats not a behaviour I would want....the CUI is there for a form of user identification but there should be no reason no remove it (which may break a local sites system/accounting) alan
Alan, Would you want to throw the User-Name out even if no CUI was generated? Because that's certainly the current behaviour (and bolloxed up some testing here). Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: 08 July 2014 11:36 To: FreeRadius users mailing list Subject: Re: Question about cui.post-auth in FR 3 Hi,
Shouldn’t it strip the User-Name only if a CUI was generated? Yes.
Ok, I'll submit a pull request if you haven't already fixed it ;-)
hi, I seem to have missed somethign here. when did this change to strip the User-Name if theres a CUI come into being? thats not a behaviour I would want....the CUI is there for a form of user identification but there should be no reason no remove it (which may break a local sites system/accounting) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Stefan Paetow wrote:
Alan,
Would you want to throw the User-Name out even if no CUI was generated? Because that's certainly the current behaviour (and bolloxed up some testing here).
Yes. Because the CUI is supposed to be an opaque user identifier. The User-Name is a non-opaque user identifier. So... handing out User-Name means that you've just told everyone who the user is. Which means the secrecy added by CUI is pointless. Alan DeKok.
On 8 Jul 2014, at 13:54, Alan DeKok <aland@deployingradius.com> wrote:
Stefan Paetow wrote:
Alan,
Would you want to throw the User-Name out even if no CUI was generated? Because that's certainly the current behaviour (and bolloxed up some testing here).
Yes. Because the CUI is supposed to be an opaque user identifier. The User-Name is a non-opaque user identifier.
So... handing out User-Name means that you've just told everyone who the user is. Which means the secrecy added by CUI is pointless.
The outer-identity was seen in the first instance anyway when the client initiated its eap conversation. True the inner identity shouldn’t be leaked, but that is the case whether a CUI is present or not. Surely the User-Name in the Access-Accept should be the original outer-identity. Scott Armitage
Hi,
Yes. Because the CUI is supposed to be an opaque user identifier. The User-Name is a non-opaque user identifier.
So... handing out User-Name means that you've just told everyone who the user is. Which means the secrecy added by CUI is pointless.
its not about 'handing out' the User-Name...the current stuff now strips the User-Name from the outerID - thats the outerID that has already been seen by the visited site or anyone along the proxy path - i would never proscribe putting the innerID into the outerID...the server never did that unless you told it to - but suddenly removing the User-Name from the outerID means that many RADIUS servers no longer have a key element that they use for local RADIUS accounting - anonymousID is one thin...but totally blank with no idea of realm etc is quite another. these sites dont support CUI , know about it or care :( alan
Alan B,
its not about 'handing out' the User-Name...the current stuff now strips the User-Name
In FR 3.0.x prior to my query (and Alan D's fix), if you called 'cui' in default's post-auth (please note, *not* cui-inner, which still functions as advertised), User-Name was stripped regardless of whether a CUI was generated in the outer Access-Accept or not. IMO that was wrong. If anything, if it didn't generate a CUI, it should leave the User-Name well alone (which it does now).
anonymousID is one thin...but totally blank with no idea of realm etc is quite another. these sites dont support CUI , know about it or care :(
The fix Alan D has put in place means that *only* if a CUI exists in the outer Access-Accept, will User-Name be stripped. :-) Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Hi,
In FR 3.0.x prior to my query (and Alan D's fix), if you called 'cui' in default's post-auth (please note, *not* cui-inner, which still functions as advertised), User-Name was stripped regardless of whether a CUI was generated in the outer Access-Accept or not. IMO that was wrong. If anything, if it didn't generate a CUI, it should leave the User-Name well alone (which it does now).
yes, that is wrong - and I dont know where that came from as we have the older stuff here and it didnt do that
The fix Alan D has put in place means that *only* if a CUI exists in the outer Access-Accept, will User-Name be stripped.
..and that is wrong too IMHO - CUI isnt anonymous - CUI is an identifier that cannot be influenced by the end user so can be trusted by a visited site to be something that will mark the same person no matter what client (or change to CSI they do ) they use or change to their outerID that they do alan
yes, that is wrong - and I dont know where that came from as we have the older stuff here and it didnt do that
When you say 'the older stuff', are you referring to FR 2.x? Because yes, there that was never in there. That was a change in 3.0.0.
..and that is wrong too IMHO - CUI isnt anonymous - CUI is an identifier that cannot be influenced by the end user so can be trusted by a visited site to be something that will mark the same person no matter what client (or change to CSI they do ) they use or change to their outerID that they do
But is it better than before, i.e. where the username simply disappeared? Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Scott Armitage -
Stefan Paetow