Overview
z
RADIUS overview
zRadSec overview
z
What is wrong with RADIUS
zRadSec benefits
z
Radsec implementations, deployment and
RADIUS overview (1)
z Remote Authentication Dial In User Service
z First defined in RFC 2058 from 1997
z Typically used for modem pools/terminal servers
z RADIUS uses UDP and a shared secret between
client and server for authentication and encryption of passwords
z A user may specify a username/password
z RADIUS client sends message to RADIUS server with
username in clear-text and password encrypted
z RADIUS server returns accept or reject
z Accept might contain attributes that tell terminal
server what access group, IP address etc the user should get
RADIUS overview (2)
z Now used a lot for wireless access
z Enhanced with EAP
z Eduroam
z Makes use of a hierarchy of RADIUS servers
z The wireless access point in a network you visit may talk
RADIUS to your home RADIUS servers
z RADIUS messages may travel through many servers and
over long distances
z EAP is used between client host (e.g. laptop) and the
home RADIUS server
z With EAP/TLS, there is a TLS connection between host and
home RADIUS server
z 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.au
authenticator1 authenticator2
han.solo @dep1.u
RadSec overview
z
RadSec is RADIUS over TLS
z TLS is more or less SSLv3
z A new transport layer for RADIUS
z Replaces UDP
z
Benefits
z Security z Reliability
z Convenience
z We will explain these benefits after discussing
RADIUS security
z Not very secure
z Uses MD5 and a shared secret for each client –
server connection
z Message authentication
z Encryption of some attributes (passwords/keys)
z There are several weaknesses
z In particular if someone can listen in on the traffic for a long
time
z Or, input known data and see how it gets encrypted
z http://www.untruth.org/~josh/security/radius/radius-auth.html z Most attributes in clear-text, might help an attacker (privacy)
RADIUS transport issues
z UDP client – server, simple retransmission scheme z One RADIUS message == one UDP datagram
z Not working well for large messages (>MTU)
z In particular over longer distances, congested links
z RADIUS messages can get very large with EAP z If a RADIUS message is fragmented, loss of one
fragment means loss of entire message
z For EAP/TLS this can be avoided with EAP
fragmentation
z Each EAP fragment results in a RADIUS request going all
the way from client to home RADIUS server, and a response back
RAD 1024 bytes EAP chunk IUS
Long EAP authentication time
z normally, EAP auth in RADIUS takes ca. 8 round-trip
times when EAP frags of 1024 are used
z 8 round-trips:
z 8 RADIUS Request messages, 8 UDP on the wire z 8 answers, 8 UDP on the wire
z Shorter delay if EAP fragments can be larger
RAD EAP IUS go-on
RadSec security
z
TLS for all RADIUS communications
z TLS connection per client – server
z
Both client and server use certificates
z Public Key encryption, no shared secrets
z
Strong encryption
z Encrypts everything, good for privacy
z
Strong authentication
z With proper use of certificates
z
Certificates provide additional benefits
RadSec reliability
z RadSec uses TLS over TCP z TCP ensures reliable transport
z One can send RADIUS messages larger than the
MTU without fragmentation
z Copes better with packet loss than UDP fragments
z EAP message (fragments) can then be up to 1500 bytes,
and the RADIUS messages will still not be fragmented
z It’s common to set EAP MTU to a much lower value to avoid
RADIUS fragmentation
z This means less RADIUS messages going back and forth,
and less delay (an EAP message can easily be 8KB)
z Makes it easier to detect when a RADIUS server is
Other RadSec benefits
z
Certificate based client authentication
z Does not care about IP addresses
z Can have e.g. travel kits with APs that can move to
any location on the Internet that connect to the home RADIUS server
z Home server need only verify the certificate
z
Certificate based server authentication
z Dynamic roaming
z What if RADIUS client could look at user identity
[email protected], 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
RadSec implementations
z RADIATOR
z The first implementation, commercial RADIUS
z radsecproxy (http://software.uninett.no/radsecproxy/)
z A RADIUS proxy that also supports radsec z Can be used to radsec-enable clients/servers
z Has been installed in Linux-based APs to make them support RadSec, package for OpenWRT
z Also used on hosts running FreeRADIUS servers
z Also useful in hierarchies like eduroam where most nodes
only do proxying (routing of RADIUS messages)
z LANCOM access points
Mobile eduroam-in-a-fonera
z Eduroam travel kit
z 7x9x2cm AP
z RadSec enabled Fonera AP
with OpenWRT
z Can be brought wherever
eduroam is needed
z With normal RADIUS, the
server would need to be configured with the IP address of the client
z Using certificates, the server
just need to verify the AP certificate
z Hence, mobile with no
Deployment and standardisation
z
Used between .lu root and some sites
z
In limited production use in .nl for 2 years
zSeveral NRNs (.de .no .pl and more) have
done tests and are planning for deployment
z
IETF standardisation
z Being discussed in radext wg etc in the IETF z Hope to get an RFC specifying RadSec
z Current specification is
