There’s normally hardly any point using PEAP if you’re already using EAP-TLS for network client authentication over RADIUS. The vast majority of the EAP conversation is encrypted with EAP-TLS anyway. The general consensus seems to be that it’s a waste of time adding the complexity of the PEAP layer too, just to hide the client certificate.

For this reason, examples of how to actually do it in FreeRADIUS are few and far between. In fact, they seem to be rather non-existant. The easy answer via a simple Google search is that you just probably can’t do it. However, there’s now a reason to consider this slightly unusual method, which is that FreeRADIUS now has support for Microsoft Statement of Health (SoH). This is a method where an agent, built in to Windows from XP SP3 and above, can supply a report about the anti-virus software and firewall, etc, upon connection to the network. It’s one component that can be used as part of Network Access Control in deciding whether to permit a client to connect.

Unfortunately for those that want to use TLS and certificates for network authentication, SoH fits into the PEAP layer. Which neatly brings us back to ‘how do I do PEAP/EAP-TLS?’

It turns out that with a recent FreeRADIUS this will now work, and it’s not actually that hard. As always, the key is knowing what to put where. The main configuration, as expected, goes in eap.conf. It needs to look something like this:

eap {
    default_eap_type = peap
    timer_expire     = 60
    ignore_unknown_eap_types = no
    cisco_accounting_username_bug = no

    tls {
        private_key_file = ${raddbdir}/certs/radius.key
        certificate_file = ${raddbdir}/certs/radius.pem
        # Don't add CA_file here unless you also
        # want to allow plain EAP-TLS.

        dh_file = ${raddbdir}/certs/dh
        random_file = /dev/urandom
        # must be around 50 or more bytes greater than
        # fragment_size in innereap below:
        fragment_size = 1200
        check_crl = no
        cipher_list = "DEFAULT"
    }

    peap {
        default_eap_type = tls
        copy_request_to_tunnel = yes
        use_tunneled_reply = yes
        proxy_tunneled_request_as_eap = no
        virtual_server = "inner-tunnel"

        # SoH configuration goes here
        # soh = yes
        # soh_virtual_server = "soh-server"
    }
}

eap innereap {
    default_eap_type = tls
    timer_expire     = 60
    ignore_unknown_eap_types = no
    cisco_accounting_username_bug = no

    tls {
        check_cert_issuer = "/DC=com/DC=example/CN=Test CA"
        private_key_file = ${raddbdir}/certs/radius.key
        certificate_file = ${raddbdir}/certs/radius.pem
        CA_file = ${raddbdir}/certs/ca.pem

        dh_file = ${raddbdir}/certs/dh
        random_file = /dev/urandom
        fragment_size = 1024
        check_crl = no
        cipher_list = "DEFAULT"

        # OCSP configuration goes here
        #ocsp {
        #        enable = yes
        #        override_cert_url = yes
        #        url = "http://ocsp-responder.example.com/ocsp/"
        #}
    }
}

The main server configuration needs to call ‘eap’ as usual. A very basic config might contain:

authorize {
    eap {
        ok = return
    }
}
authenticate {
    eap
}
preacct {
}
accounting {
}
session {
}
post-auth {
}
pre-proxy {
}
post-proxy {
}

However, the inner-tunnel server that is used by PEAP needs to call the second “innereap” instantiation of the eap module. Again, a very basic config might be:

server inner-tunnel {
    authorize {
        innereap
    }
    authenticate {
        innereap
    }
    session {
    }
    post-auth {
    }
    pre-proxy {
    }
    post-proxy {
    }
} # inner-tunnel server block

The key to all this seems to be the fragment_size setting. The TLS component for EAP-TLS must have a smaller fragment_size than the TLS component for PEAP. Experimentation indicated that it should probably at least be 50 bytes smaller, so using the values in eap.conf above is probably safe — your mileage may vary. This difference also seems to be the reason why you can’t just use the same eap instantiation for both the outer and inner servers, as otherwise the configuration could be identical.

(Note: Please don’t put these examples into production as they are — I can’t guarantee they are secure, they’re just examples from the way I got this to work. You should base your server on the default FreeRADIUS configuration until you really know what you are doing.)

After this is working, which hopefully it should do fairly easily, you can start to add the extras, such as SoH (see FreeRADIUS SoH.txt documentation) or client certificate checking with OCSP.