Checking TLS-Cert-* and and accept/reject based on them
Dear all, 1-2 years ago this topic was discussed and there was a patch by Matthew Newton that was approved for the master branch. I'm now facing the difficulty of accepting/rejecting requests based on the contents of the TLS-Client-Cert for 2.1.12 which does not contain this patch. This is done in an exec module script in the authorize section which needs to decide on the request information and the certificate data whether to allow or disallow access. Other than applying this patch to 2.1.12 or switching to master, is there any other way to use the binaries of 2.1.12 and still be able to use the client cerficate date in the exec script? The reason I'm not simply applying the patch is that this system is covered by support by Red Hat and replacing the vendor shipped freeradius (2.1.12) with a self-compiled one voids the support. So any other solution that would allow me to keep the system under support and still be able to check the certs Subject/CN would be great! Some more details for anyone interested: The RADIUS client is an AP and the devices are Wifi clients like Android, iPads, laptops etc with Client certificates. Some devices should be allowed to access some SSIDs and others are not. freeradius gets the certificate and needs to extract the embedded username (which is just the device's serial number and displayed in the logs as BUF-name) for checking whether this device is allowed to connect to this SSID. The decision is made in an exec module in the authorize section, but I cannot pass any certificate information to it for checking. Thanks, Axel. -- Axel.Thimm at ATrpms.net
On 29/08/13 13:21, Axel Thimm wrote:
The reason I'm not simply applying the patch is that this system is covered by support by Red Hat and replacing the vendor shipped freeradius (2.1.12) with a self-compiled one voids the support. So any other solution that would allow me to keep the system under support and still be able to check the certs Subject/CN would be great!
Ask RedHat? Since it's "supported"... Otherwise, you could look at the "verify { }" stanza of the "tls { }" block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you want to access the various issuer/subject fields.
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the "verify { }" stanza of the "tls { }" block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the request data at hand to check for the requested SSID? Or is there a way to set variables in this script to check later in the authorize section's modules (with an exec script)? -- Axel.Thimm at ATrpms.net
On 29/08/13 14:25, Axel Thimm wrote:
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the "verify { }" stanza of the "tls { }" block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the request data at hand to check for the requested SSID?
It's run using the standard exec helper, so it has access to all the stuff that a normal exec module has; specifically there should be environment variables matching each request attribute, mangled into upper-case + underscores. e.g. Calling-Station-Id ...should appear as: CALLING_STATION_ID Suggest you try it and see.
Or is there a way to set variables in this script to check later in the authorize section's modules (with an exec script)?
No. The output of the verify script is thrown away, so in that respect it's not like a normal exec. It's a binary yes/no. Obviously you could work around this; you could set a request variable to a unique value e.g. timestamp+random, have your verify{} script use that as the basis of a filename to dump the info to, then read it with *another* exec module lower down. Or you could abandon the prejudice against upgrading because "it's supported" (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in.
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote:
Or you could abandon the prejudice against upgrading because "it's supported" (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in.
I don't think it's in 2.2.0 - it is in 2.x HEAD, though, so should be in 2.2.1. Agreed on the support contract thing. If something is apparently "unsupported" when it's broken, just run the "supported" version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did. If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Agreed on the support contract thing. If something is apparently "unsupported" when it's broken, just run the "supported" version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did.
If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-)
RedHat does follow this list, so perhaps it is worth contacting them to point out that this patch would really be appreciated, even if it ends up in an EPEL package (which should still be acceptable). That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do. Regards Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 29/08/13 15:49, stefan.paetow@diamond.ac.uk wrote:
That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do.
Failing to direct these queries towards your paid support option creates moral hazard, as it generates a positive externality for the paid vendor (they get to charge you for the easy stuff, but don't pay the cost for their unwillingness to forward-port features). You ABSOLUTELY should be opening tickets with your paid vendor every time something like this comes up. Not "maybe".
On Thu, Aug 29, 2013 at 02:49:17PM +0000, stefan.paetow@diamond.ac.uk wrote:
Agreed on the support contract thing. If something is apparently "unsupported" when it's broken, just run the "supported" version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did.
If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-)
I'm discussing this within Red Hat already. They are not that upgrade-shy (if it doesn't change the API/ABI), but it takes longer to get approvals from all people involved.
RedHat does follow this list, so perhaps it is worth contacting them to point out that this patch would really be appreciated, even if it ends up in an EPEL package (which should still be acceptable).
freeradius belongs to the core group of technologies in Red Hat, so it's unlikely to allow a replacing package in EPEL (unless it is called freeradius3 or freeradius221 or similar).
That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do.
Thanks! -- Axel.Thimm at ATrpms.net
On 29/08/13 15:09, Matthew Newton wrote:
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote:
Or you could abandon the prejudice against upgrading because "it's supported" (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in.
I don't think it's in 2.2.0 - it is in 2.x HEAD, though, so should be in 2.2.1.
Ah, my mistake.
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote:
On 29/08/13 14:25, Axel Thimm wrote:
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the "verify { }" stanza of the "tls { }" block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the request data at hand to check for the requested SSID?
It's run using the standard exec helper, so it has access to all the stuff that a normal exec module has; specifically there should be environment variables matching each request attribute, mangled into upper-case + underscores.
e.g.
Calling-Station-Id
...should appear as:
CALLING_STATION_ID
Suggest you try it and see.
Thank you, that looks very promising!
Or is there a way to set variables in this script to check later in the authorize section's modules (with an exec script)?
No. The output of the verify script is thrown away, so in that respect it's not like a normal exec. It's a binary yes/no.
Obviously you could work around this; you could set a request variable to a unique value e.g. timestamp+random, have your verify{} script use that as the basis of a filename to dump the info to, then read it with *another* exec module lower down.
That is very nasty! I love it! :) I'll try to go with the verify for now.
Or you could abandon the prejudice against upgrading because "it's supported" (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in.
For systems I know I will be the long term support I can talk to the customer and he will agree to have me patch up specific binaries, but in this case I'm just setting this up. -- Axel.Thimm at ATrpms.net
participants (4)
-
Axel Thimm -
Matthew Newton -
Phil Mayers -
stefan.paetow＠diamond.ac.uk