Matthew Newton wrote:
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.
Sure. Examples are always good.
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.
Yes. Have that EAP-TLS-Require-Client-Cert attribute over-ride the configuration setting.
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?
No idea. It works, so... that's that, I guess.
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.
It works.
The following might tidy it up.
eap { common_settions = here tls-config { common { ... } }
That looks complicated and weird. I'd just leave it the way it is. The most I would change is to have the "tls = ..." be a *reference*. If the configuration section isn't found in "eap", start looking from the top-level configuration.
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).
That's an extra layer which is confusing, and doesn't add a lot of value. I'd say it's not necessary. Alan DeKok.