Connect. Communicate. Collaborate Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains Henk Eertink †, Arjan Peddemors †, Roy.

Connect. Communicate. Collaborate

Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains

Henk Eertink†, Arjan Peddemors†, Roy Arends†, Klaas Wierenga‡, Remco Poortinga†

†‡

Connect. Communicate. CollaborateBackground

• Core issue of this paper: roaming• Roaming has to do with trust between parties• Trust is made tangible via

– Shared secrets– Credentials validated by a trusted third party (e.g. PKI)

• EDUROAM enables secure wireless LAN access among participating organisations

• Our focus: solving problems in the authentication infrastructure of EDUROAM

Connect. Communicate. CollaborateTrust - Properties

• Trust is relative to a given context• Trust is directed• Trust is a measurable belief• Trust exists in time• Trust evolves in time• Trust is transferable

Connect. Communicate. CollaborateOverview of this talk

• Limitations of EDUROAM• Our RADIUS-DNSSEC solution

– Overall architecture– DNS interaction– Secure connection establishment

• Alternative Solutions • Current status & next steps

Connect. Communicate. CollaborateEDUROAM Architecture Connect. Communicate. Collaborate

visiting

cliente.g. 802.11

access point

RADIUSproxy for

other realms

visit.org user

account db

home

RADIUSserver

home.org user

account db

EDUROAM infra

Shared key

p2p

16

2 3

45OKroam.org

visit.org home.org

Shared key

Shared keys

Connect. Communicate. CollaborateProblems of RADIUS-proxy chaining

• Delay: All authentication traffic must flow across the chain• Confidentiality: Intermediate proxies are able to analyze

authentication traffic• DoS: Fixed proxy-chains may have single points of failure• Mgt: Manual shared-secret configuration effort is required,

based on off-line secret establishment procedures• Mgt: There is no insight in the web of proxy-servers

‘behind’ the next hop.

Analysis: RADIUS wears two hats: trust-establishment and authentication

Connect. Communicate. CollaborateOur approach: Trust via secure DNS

• DNSsec guarantees correctness of DNS records• And can therefore be used as a safe certificate store• We translate a roaming structure into a secured DNS domain

– Managed by an administrative authority that enforces the roaming policies

– Register all participating organisations in that zone(e.g. surfnet.nl.eduroam.org; telin.nl.eduroam.org; soton.ac.uk.eduroam.org )

• For each subdomain below the roaming agreement– register SRV records, A-records & certificates for each authoritative

authentication server in DNS. • During authentication of user@domain

– Do a DNS-lookup of _radius_udp_.domain.<roaming-domain>– Retrieve A-records & certificates of authentication server from DNS– Set up a trusted association between home&visited server

Connect. Communicate. CollaborateSecure DNS scenario Connect. Communicate. Collaborate

visiting

cliente.g. 802.11

access point

RADIUSserver

proxy for other realms

visit.org user account db

home

RADIUSserver

home.org user

account db

DNS serverauthoritativefor roam.org

p2p

1authenticate / authorize [email protected]

6

2

3

4

5

OK

roam.org

visit.org

home.org

DNS servercaching forwarder

secure lookup radius server associated with

home.org.roam.org

7

establish connection dynamically

89

A:111.222.111.222 CERT:key=a;sd98yhq3ra

secure lookup radius server associated with

home.org.roam.orgDNS

infrastructure

Connect. Communicate. CollaborateDynamic setup of secure connection

• This is not supported by RADIUS• For our prototype we defined our own RADIUS key-

establishment protocol, called RKE• RKE is used to negotiate a RADIUS shared key over a

mutually authenticated dynamically established TLS session

• And therefore RADIUS implementations keep (almost) the same

• Alternative: use TLS / ipsec / DTLS transport inside RADIUS instead of using another protocol

Connect. Communicate. Collaborate

version: 1.0

RADIUS server

push key/ttl to shared secret cache

RADIUS Key Exchange Protocol (RKE)

• Straightforward exchange of a shared secret between RADIUS peers,

assuming a secure reliable channel (here: TLS)

• No concurrent RKE sessions may take place to the same peer

RKE handler

RADIUS server

RKE handler

client side server side

key: 0ffe92a690b255

ok

1

3

2

ttl: 86400

push key/ttl to shared secret cache

4

version: 1.0

Connect. Communicate. CollaborateIETF alternative: DIAMETER

• Generic AAA protocol, that should replace/complement RADIUS

• Supports peer discovery (using DNS + TLS + PKI)– RFC 3588: section 5.2 and section 13.3– IPsec less suitable: only one certificate for all

applications. RFC 3588 recommends the use of TLS for inter-domain authentication

– Server discovered through NAPTR/SRV records– Trust between peers who have their certificates signed

by the same roaming domain Certificate Authority (CA)• Lack of available implementations

Connect. Communicate. CollaborateComparison

RADIUS (DNSSEC)1. Trust based on pre-configured set of

roaming domains2. DNS used to locate proper

authentication server3. Multiple roaming agreements? Select

proper roaming-domain.4. Dynamic secure connection setup5. Insight in membership6. Supports migration scenarios

7. Requires DNSsec key management (for at least 1 organisation)

8. Requires an additional key-establishment protocol, or support for TLS/ipsec in RADIUS itself

9. DNSSEC has not seen a lot of deployment

DIAMETER (DNS/PKI)1. Trust based on preconfigured set of

roaming CAs (PKI)2. DNS used to locate proper

authentication server3. Multiple roaming agreements? Select

proper certificate. 4. Dynamic secure connection setup5. No insight in membership6. Supports migration scenarios (through

translation agents)7. Requires PKI management (for all

organisations)8. Does support TLS and ipsec by default

9. Diameter has not seen a lot of deployment

Connect. Communicate. CollaborateConclusions

• Extending EDUROAM with dynamic trust establishment (instead of hardwired links) can be done efficiently

• secure DNS can be a good foundation for EDUROAM• Diameter is an alternative approach• There are pros and cons, and lack of deployment for both.• Adding DNSSEC-support to Diameter is maybe the way to go

Planned next steps• Real-life validation of Diameter, Radius-DNSsec, maybe also

Diameter-dnssec• Integrated with current Eduroam deployment environment

Connect. Communicate. Collaborate

Backup slides (diameter/radius pki)

Connect. Communicate. CollaborateAlternative solutions -- Diameter Connect. Communicate. Collaborate

visiting

cliente.g. 802.11

access point

DIAMETERserver

relay for other realms

visit.org user account db

home

DIAMETERserver

home.org user

account db

infra

static route

1authenticate /

authorize [email protected]

6OK

roam.org

visit.org

home.org

7

5

2

DIAMETERserver

redirector (broker)

3

4

redirect to diameter.home.org

See section 2.8.3 of RFC 3588 “Diameter Base Protocol”

static route

dynamic route; setup secure conn.

All connections between entities secured with IPSEC or TLS (using shared secret, PKI, …)

Connect. Communicate. CollaborateAlternative Solutions - DIAMETER

• Benefits– All AA traffic for roaming scenario falls within the

DIAMETER protocol definition (explicit definition of broker entity)

• Open Issues– Dynamic routes established between DIAMETER

entities in roaming domain most likely are secured using PKI; what about performance compared to RADIUS-DNSSEC?

– Quality of implementations uncertain– Limited deployment experience

Connect. Communicate. CollaborateAlternatives: Radius-PKI Connect. Communicate. Collaborate

RADIUSserver

RADIUSserver

proxy for other realms

cliente.g. 802.11

access point

visiting

visit.org user account db

home

home.org user

account db

infra

p2p

1authenticate /

authorize [email protected] OK

roam.org

visit.org

home.org

5

3

2

Certificate Authority

2a

4

verify certificate radius.home.org

setup IPSEC / TLS connection

2b2c 2d

verify certificate radius.visit.org

All parties in the roaming domain use certificates issued by the roam.org CA

Connect. Communicate. CollaborateAlternative Solutions – RADIUS / PKI• Peer discovery details

– Between step 1 and 2: RADIUS server of other realm (e.g. home.org) found through DNS SRV records: e.g. _radius._tcp.home.org or _radius._udp.home.org (note: RADIUS protocol defines UDP traffic only)

– Possible alternative approach: • Lookup certificate at CA with realm name as key (possible?)• If exists, realm is part of roaming domain• Use additional info in certificate to determine RADIUS server of realm• Interaction becomes slightly different (no need for client side certificate

lookup during TLS connection establishment; already done)• Open Issues

– What about taking part in multiple roaming domains? RADIUS server has multiple certificates; which one to provide during TLS connection establishment?

– No implementations; custom-made solution

Connect. Communicate. CollaborateNo RKE? Alternative1: RADIUS/TLS

• No need to exchange shared RADIUS secret; all traffic is over secure TLS connection

• Public keys from DNS used for mutual authentication

• TLS uses reliable transport (for most practical cases: TCP), but RADIUS is UDP based

• Possible mismatch between flow control and error recovery functionality in RADIUS server implementations and similar functionality in TCP when simply replacing UDP with TCP sockets

• Flow control and error recovery functionality probably hard to remove from RADIUS server implementation: mixed with application logic

• Conclusion: high implementation effort

Connect. Communicate. CollaborateNo RKE? Alternative2: RADIUS/DTLS

• DTLS = Datagram Transport Layer Security

• No need to exchange shared RADIUS secret; all traffic is over secure DTLS connection

• Public keys from DNS used for mutual authentication

• Current (single) implementation not (yet) of high quality

• Conclusion: no suitable implementation available

Connect. Communicate. CollaborateRKE Alternatives: IPSEC

• No need to exchange shared RADIUS secret; all traffic between hosts is protected by IPSec

• Public keys from DNS used for mutual authentication

• Requires system-level configuration on the RADIUS servers (extra deployment effort)

• All traffic between these hosts is encrypted; may be inappropriate when additional services run on these hosts

• Conclusion: good alternative