TLS configuration

[Alan DeKok]

Matthew Newton wrote:
>   ... so why is the TLS config all inside EAP-TLS, and
>   mysteriously PEAP and TTLS use EAP-TLS's config?

  Because they all use TLS.  And because you want the server to appear
as one RADIUS server.  Having a shared configuration makes that easier.

  The alternative would be to configure TLS *separately* for PEAP and
TTLS.  When the user switches from PEAP to TTLS, a "new server" warning
pops up, along with a new certificate.  That's not nice.

> When you go to configure PEAP/EAP-TLS things get more interesting,
> as you actually have to configure EAP-TLS+PEAP (outer), and then
> EAP-TLS (inner). To be honest, configuring PEAP/MS-CHAPv2 a year
> or so ago for the first time felt wierd too - "but I don't want
> EAP-TLS" :)

  You have to configure two TLS modules if you want to use TLS in two
different ways.

> In the main top-level config in radiusd.conf, have a new 'tls'
> section, that might look something like this:

  The difficulty is that it doesn't follow the module format of the
server.  It mixes module configuration, "listen" section configuration,
and has configuration for different virtual servers in one place.

> Then wherever a TLS configuration is required, we can have just
> "tls = outer-peap".

  You can pretty much do this today.  Just re-arrange the configuration.
 See raddb/templates.conf.

  It's pretty much just reorganization.

  The current model works for me.  The TLS configuration is located in
the places where it's used.  (for the most part) That makes sense.
Putting it somewhere else is a recipe for end-user confusion.

> The only potential problem I can see is if the TLS on EAP comes up
> first, before the EAP type is determined, but having looked at the
> protocol I don't believe that is the case - so the server should
> always know that it's the PEAP tls= config that is being used, as
> the EAP type was code 25, for example.

  That isn't a problem.  EAP does negotiation of EAP types.

> As a start, I guess the modules could keep their current TLS
> settings, but have an additional tls= option that would pull
> global config in at instantiation time. I'm not sure it needs to
> be any more difficult than that - except maybe in the PEAP/TTLS
> sections which don't have their own settings already.

  Maybe... the PEAP and TTLS modules are strongly tied to the enclosing
EAP module, and share the same TLS config.  So it is *very* difficult
for them to find a TLS configuration which is located elsewhere in the code.

  See src/modules/rlm_eap/eap.c.  Look for "TLS".  Knowledge that
TTLS/PEAP uses TLS is hard-coded into the EAP module.  Changing that is
difficult.

> Are there any thoughts on this - is it worth persuing? I'm not
> sure if I'll have time to work on it or not, but thought it was
> worth throwing the idea out anyway. :)

  Independent of any code changes, I would find that configuration
confusing.

  It might be worth locating all of the TLS config in one place, but I'm
not sure that the benefit is justified.

  Alan DeKok.