RadSec – A better RADIUS protocol

Stig Venaasvenaas@uninett.no

Stefan Winterstefan.winter@restena.lu

Overview

RADIUS overview RadSec overview What is wrong with RADIUS RadSec benefits Radsec implementations, deployment and

standardisation

RADIUS overview (1)

Remote Authentication Dial In User Service First defined in RFC 2058 from 1997 Typically used for modem pools/terminal servers

RADIUS uses UDP and a shared secret between client and server for authentication and encryption of passwords

A user may specify a username/password RADIUS client sends message to RADIUS server with

username in clear-text and password encrypted RADIUS server returns accept or reject Accept might contain attributes that tell terminal

server what access group, IP address etc the user should get

RADIUS overview (2)

Now used a lot for wireless access Enhanced with EAP

Eduroam Makes use of a hierarchy of RADIUS servers The wireless access point in a network you visit may talk

RADIUS to your home RADIUS servers RADIUS messages may travel through many servers and

over long distances EAP is used between client host (e.g. laptop) and the

home RADIUS server TLS connection between host and home RADIUS server Good protection of credentials, but some information related

to the user may be sent as unprotected attributes to the RADIUS client

Roaming in eduroam

root Server

.de .lu .nl .au . ...

org1.lu org2.lu uni.au

dep1.uni.au dep2.uni.auauthenticator1 authenticator2

han.solo@dep1.u

ni.au

RadSec overview

RadSec is RADIUS over TLS A new transport layer for RADIUS

Replaces UDP

Benefits Security Reliability Convenience We will explain these benefits after discussing

issues with RADIUS over UDP

RADIUS security

Not very secure Uses MD5 and a shared secret for each client –

server connection Message authentication Encryption of some attributes (passwords/keys)

There are several weaknesses Particularly if one can listen in on the traffic for a long time Or, input known data and see how it gets encrypted http://www.untruth.org/~josh/security/radius/radius-auth.html Most attributes in clear-text, might help an attacker (privacy)

For good security, one can use EAP with TLS tunnel between mobile node and home radius

RADIUS transport issues

UDP client – server, simple retransmission scheme One RADIUS message == one UDP datagram Not working well for large messages (>MTU)

In particular over longer distances, congested links RADIUS messages can get very large with EAP If a RADIUS message is fragmented, loss of one

fragment means loss of entire message For EAP/TLS this can be avoided with EAP

fragmentation Each EAP fragment results in a RADIUS request going all

the way from client to home RADIUS server, and a response back

Results in many messages and long authentication time

RadSec security

TLS for all RADIUS communications TLS connection per client – server

Both client and server use certificates Strong encryption

Encrypts everything, good for privacy Strong authentication

With proper use of certificates Certificates provide additional benefits

Later slide

RadSec reliability

RadSec uses TLS over TCP TCP ensures reliable transport One can send RADIUS messages larger than the

MTU without fragmentation Copes better with packet loss than UDP fragments EAP message (fragments) can then be up to 1500 bytes, and

the RADIUS messages will still not be fragmented It’s common to set EAP MTU to a much lower value to avoid

RADIUS fragmentation This means less RADIUS messages going back and forth,

and less delay (an EAP message can easily be 8KB) Makes it easier to detect when a RADIUS server is

down/unreachable (better server failover)

Other RadSec benefits

Certificate based client authentication Does not care about IP addresses Can have e.g. travel kits with APs that can move to

any location on the Internet that connect to the home RADIUS server Home server need only verify the certificate

Certificate based server authentication Dynamic roaming

What if RADIUS client could look at user identity schmidt@uni.de, find uni.de server using DNS SRV records, contact uni.de server, and get a certificate from server stating that it is authorised to serve uni.de

Eduroam without a RADIUS hierarchy?

RadSec implementations

RADIATOR The first implementation, commercial RADIUS

radsecproxy (http://software.uninett.no/radsecproxy/) A RADIUS proxy that also supports radsec Can be used to radsec-enable clients/servers

Has been installed in Linux-based APs to make them support RadSec, package for OpenWRT

Also used on hosts running FreeRADIUS servers Also useful in hierarchies like eduroam where most nodes

only do proxying (routing of RADIUS messages)

LANCOM access points APs with built in RadSec client

Mobile eduroam-in-a-fonera

Eduroam travel kit 7x9x2cm AP RadSec enabled Fonera AP

with OpenWRT Can be brought wherever

eduroam is needed With normal RADIUS, the

server would need to be configured with the IP address of the client

Using certificates, the server just need to verify the AP certificate

Hence, mobile with no re-configuration

Deployment and standardisation

Used between .lu root and some sites In limited production use in .nl for 2 years Several NRNs (.de .no .pl and more) have

done tests and are planning for deployment IETF standardisation

IETF radext wg considering adoption Hope to get an RFC specifying RadSec Current specification is

http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt