2. EAP-TLS is easy …
… for RADIUS server. At the minimum one needs only to
configure RADIUS server certificate and the CA certificate for
client certificate verification.
… to configure improperly. Understanding how certificates,
certificate revocation, root and intermediate CAs, PKI etc works
requires significant effort. Designing and deploying working
model requires even more.
… only when one does not need to care about the client
certificates, their configuration, provisioning and
management.
3. Deploying EAP-TLS
never start or settle requirements because of a product, solution
or technology
start with defining and designing
policies (validity, expiry times, authorisation, usage …)
PKI (hierarchy: CAs, intermediate CAs, certificate usage …)
configuration management
certificate provisioning
certificate requirements (roaming, use, technology …)
… but do pilot /trials simultaneously to learn and to see how
things do (or do not) work or scale with real users and
infrastructure
4. Start with simple trial …
Try self-signed CA, manually created
client certificates first (or Radiator’s
certificates directory)
eduroam managed IdP as a service for
roaming EAP-TLS tests
Verify first that your underlying network
and especially firewalls and their rules
work when using EAP-TLS
Firewalls filtering UDP fragments and
especially *BSD firewalls (scrub setting)
can cause problems.
Federation
Level
RADIUS
IdP/SP
RADIUS
Wi-Fi
network
(controller)
Client
devices
5. Add basic automatic certificate validation…
a separate Certificate Authority (CA) capable
of providing certificate revocation lists
(CRLs) or function as a Online Certificate
Status Protocol (OCSP) server is needed
several open source CAs/PKIs available:
easypki, dogtag, ejbca …
with this setup one can ensure that when
certificates expire, they do not work for
authentication anymore
automating the certificate validity check is
essential for using certificate authentication
Federation
Level
RADIUS
IdP/SP
RADIUS
Wi-Fi
network
(controller)
Certificate
Authority
(CA)
OCSP reqs.
CRLs, delta-
CRLs
Certificates
6. Add connection to authorisation database…
Authorisation database can be Active
Directory, LDAP, SQL with additional
information about the client certificate.
CA, CRLs and OCSP can be sometimes
replaced by client certificate check
against the authorisation database.
Authorisation database can contain
additional information such as VLAN
assignments, account active/locked etc.
How flexible/complex/simple the
authorisation checks can be depends on
the IdP RADIUS product.
Federation
Level
RADIUS
IdP
RADIUS
Wi-Fi
network
(controller)
Certificate
Authority
(CA)
OCSP reqs.
CRLs, delta-
CRLs
Certificates
LDAP,
SQL,
etc.
IdP
Authorisation
Database
(AD, LDAP,
SQL)
7. Deploy certificate management service…
Properly distributing and configuring
certificates in the end user devices is
difficult.
For managed devices (Windows domain/
Intune) or for Apple devices it is easier,
but Android/Linux devices are hard.
Currently there seems to be no better
approach than to have an app in the
device talking to a service.
One commercial option is SecureW2.
Certificate signing requests created in
the actual device are even harder.
IdP
RADIUS
Wi-Fi
network
(controller)
Certificate
Management
Service
OCSP reqs.
CRLs, delta-
CRLs
Certificates
LDAP,
SQL,
etc.
IdP
Authorisation
Database
(AD, LDAP,
SQL)
Certificate
(signing)
requests
Certificate
request
authorisation
requests
8. … and you are done… sort of … maybe …
If everything presented before works for you, it’s brilliant … and
you are brilliant.
Unfortunately any organisation who does not have the first step
right will break your organisation’s users’ roaming.
Sometimes even the packet filters / firewalls in front of federation
level RADIUS servers need configuration adjustments.
Deploying certificate based authentication requires design,
competence and support from infrastructure and service
vendors — choose wisely, select vendors and solutions, for
which you can get support for design, deployment and
production.
9. Questions?
Find this presentation and more from:
https://blog.radiatorsoftware.com/
https://slideshare.net/radiatorsoftware/
https://slideshare.net/khuhtanen/
https://twitter.com/OSCRadiator
Extended presentation coming to JISC govroam stakeholders’ meeting
(15th of October 2019 in Manchester, United Kingdom) and to the Internet locations above.