TLS configuration

6 Feb 2012

      Hi,

We've been struggling a bit with the TLS config - not actually
configuring it, but how it appears in the config file. The basic
thoughts go something along the lines of:

  PEAP uses TLS
  EAP-TTLS uses TLS
  EAP-TLS uses TLS

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

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" :)

This it not from a programming point of view - I can see why it's
done like that. It's more for ease of understanding the configuration.

There are other places where TLS crops up too, such as RADSEC and
LDAP. The RADSEC one specifically says it's the same config as
EAP-TLS (but at least it doesn't *use* EAP-TLS's config!)

We wondered whether something like the following would be
feasable, or worth trying to implement?

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

  tls {
    outer-peap {
      certificate_file = ${certdir}/server.pem
      ...
    }

    inner-eap {
      private_key_file = ${certdir}/server.pem
      certificate_file = ${certdir}/server.pem
      CA_file = ${cadir}/ca.pem
      ...
    }

    outer-tls {
      ...
    }

    radsec {
      ...
    }

    ldap {
      ...
    }
  }

where the sub-headings are just labels - instantiations of the 'tls' config.

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

For example, modules:

  eap {

    tls {
      tls = outer-tls
      fragment_size = 1200
      ...
    }

    peap {
      tls = outer-peap
      default_eap_type = mschapv2
      copy_request_to_tunnel = no
      use_tunneled_reply = no
      virtual_server = "inner-tunnel"
      ...
    }

  }

  eap inner-eap {
    tls {
      tls = inner-tls
      cache {
        ...
      }
      fragment_size = 1024
      verify {
        ...
      }
    }
  }

This then makes it quite clear which TLS config belongs to which
section, and allows sharing of TLS configs if really desired.

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.

I think we were thinking "hang on a sec, TLS is a generic server
thing, nothing really to specifically do with EAP-TLS or PEAP,
etc, so why is the config just in EAP-TLS - that's confusing".

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.

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. :)

Thanks,

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>