Yesterday’s patch for FreeRadius turns out to be superfluous, as the functionality is already present, its just undocumented!
I submitted the patch to the FreeRadius bug tracking system (#392) and got back a quick reply from Alan DeKok saying the following:
It isn’t well documented, but it’s already supported, via the
EAP-TLS-Require-Client-Cert attribute. This allows you to have
the cert requirement on a per-realm, or per-user basis.
Oh well, at least the patch didn’t take too long to write! I had seen the code that handles the EAP-TLS-Require-Client-Cert attribute, but I couldn’t find any references to it elsewhere in the daemon, so I assumed it was a fragment that was unused and ignored it.
Moral of the story: Assume less and spend more time understand the code you’re patching!
Comments Off
For the project that I’m dealing with at work I wanted to be able to authenticate devices in a two stage process. Stage 1 should authenticate the device to the network (via an x509 certificate) and then Stage 2 should authenticate the user who possesses the device with a username and password.
Unfortunately none of the methods shipped by default with FreeRadius will support this sort of configuration.
- EAP-TLS supports mutual certificate authentication between the server and the client but does not allow for a second stage to verify the username and password
- EAP-TTLS and EAP-PEAP both support mutual certificate authentication between the server and the client followed by a second stage password verification, however the current FreeRadius implementation doesn’t let you require a client certificate. If one is present it will use it, but it is just as happy to continue on without one, which is not ideal for my circumstances.
- The remaining EAP- methods don’t support certificates at all, so they’re not even an option.
A quick skim through the FreeRadius source code revealed that it wouldn’t be too hard to add support for requiring client certificates with EAP-TTLS and EAP-PEAP. The following patch adds a new configuration option to the tls section of eap.conf which if set to true will require the client to present a certificate before authentication will succeed.
Example eap.conf
eap {
default_eap_type = ttls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
md5 {
}
tls {
private_key_file = ${raddbdir}/certs/radius.key
certificate_file = ${raddbdir}/certs/radius.pem
CA_file = ${raddbdir}/certs/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
# This is the new option
# If set to no, or missing, client certificates are
# not required for EAP-TTLS or EAP-PEAP
require_client_cert = yes
}
ttls {
default_eap_type = md5
}
}
David Cunliffe has just announced this morning that the Government has finally decided to approve 5 of the urban Broadband Challenge applications to build urban fibre networks.
Hamilton is one of the accepted proposals, getting $3.3m of government funding to help cover the start-up costs of the network. Under the conditions of the Broadband Challenge the networks must be open access and provide a full duplex transfer rate of at least 1Gbps.
Should be interesting to see how this develops!
Press Releases:
Comments Off
