On Sun, Mar 04, 2012 at 10:46:00AM +0100, Alan DeKok wrote:
I've pulled most of the coce in, with some minor changes.
OK, thanks! I'm pondering a few more small things - I've tested templates with the tls config, and it works fine - so I wonder if it's worth an example in the templates.conf for tls? Not sure how much would normally be shared to be worth it, though. Server certificate and a few other bits, maybe. On PEAP/TTLS client certificates, I think it would now be nice to have a require_client_cert = yes option in the peap {} and ttls {} sections. Maybe that can be overridden by EAP-TLS-Require-Client-Cert (or maybe even EAP-PEAP-Require-* and EAP-TTLS-Require-*, although not sure if that's worth it). I'll put together a patch for the option to peap/ttls if it's worth it. There's a comment in the code about the EAP-TLS-Require-Client-Cert needing fixing, but I don't know what the thoughts on that were at the time? I'm still not 100% sure on the tls-config tls-common directive. It seemed the best way a few days ago, because the eap module treats all conf_sections inside eap {} as eap-type modules to load. Having tls-config as a 'virtual type' meant it was easier to avoid. I'm starting to look at it and think it's not that clean, though. The following might tidy it up. eap { common_settions = here tls-config { common { ... } } tls { tls = common } peap { ... } gtc { ... } md5 { ... } ... } Possibly also have a 'types {}' section for all the eap-types to go in, to then avoid having the exception for tls-config that's not a sub-module, as the eap code could iterate over that knowing it will only contain modules (a bit like the main modules{} section). Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>