Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains

1. Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains Henk Eertink, Arjan Peddemors, Roy Arends, Klaas Wierenga, Remco Poortinga

2. Background • Core issue of this paper: roaming • Roaming has to do with trust between parties • Trust establishment is made tangible via • Shared secrets • Credentials validated by a trusted third party (e.g. PKI) • Paper’s focus is on solving problems in the authentication infrastructure of EDUROAM • EDUROAM enables secure wireless LAN access among participating organisations

3. Overview of this talk • Limitations of EDUROAM • Our RADIUS-DNSSEC solution • Overall architecture • DNS interaction • Secure connection establishment • Alternative Solutions • Current status & next steps

4. EDUROAM Architecture Connect. Communicate. Collaborate EDUROAM infra 2 3 visiting home visit.org 5 home.org 4 roam.org OK p2p RADIUS proxy for other realms p2p RADIUS server 1 6 client e.g. 802.11 access point p2p visit.org user account db home.org user account db

5. Problems of RADIUS-proxy chaining • All authentication traffic flows across the chain (delay) • Intermediate proxies are able to analyze authentication traffic (security) • Fixed proxy-chains may have single points of failure (denial of service) • 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 is used both for trust-establishment and for authentication

6. Our approach: leverage secure DNS Connect. Communicate. Collaborate roam.org secure lookup radius server associated with home.org.roam.org DNS server authoritative for roam.org DNS infrastructure 3 DNS server caching forwarder 4 visiting A:111.222.111.222 CERT:key=a;sd98yhq3ra visit.org secure lookup radius server associated with home.org.roam.org 2 5 home establish connection dynamically home.org 6 RADIUS server proxy for other realms RADIUS server 7 authenticate / authorize user@home.org 1 9 8 OK p2p client e.g. 802.11 access point visit.org user account db home.org user account db

7. RADIUS-DNSSEC summary • Use secure DNS for dynamic trust establishment between home and visited domains • DNS guarantees the integrity of the returned records • Leverage the secure DNS infrastructure, by reusing it as a kind-of PKI to securely obtain public keys of peers • Establish a secure connection between the authentication servers of home and visited domains • In principle using arbitrary secure connections (TLS, DTLS, ipsec, …) • In practice we defined our own RADIUS key-establishment protocol on top of TLS (ease of implementation) • Use peer-to-peer RADIUS over a secured connection • Without any changes to the RADIUS protocol

8. Details: dns interaction Connect. Communicate. Collaborate DNS RADIUS server rs1.visit.org realm/domain: visiting.org IP number: 10.0.0.100 1 _radius._udp.home.org.roam.org SRV ? 2 0 0 1812 rs1.home.org.roam.org 1 0 1812 rs2.home.org.roam.org 3 rs1.home.org.roam.org A ? 4 10.10.0.200 5 rs1.home.org.roam.org CERT ? 6 X509: RSA Public Key: 08:A8:F7:… start TLS session TLS session end TLS session established RADIUS traffic shared secret exchange 15 7 14 12 13 RADIUS server rs1.home.org realm/domain: home.org IP number: 10.10.0.200 8 rs1.visit.org.roam.org A ? 9 10.0.0.100 10 rs1.visit.org.roam.org CERT ? 11 X509: RSA Public Key: 65:A4:DB:…

9. DNS structure • A roaming agreement is made tangible in a domain (‘eduroam.org’) • Each country has its own subdomain (‘nl.eduroam.org’, …) • Each participant has its own subdomain (‘telin.nl.eduroam.org’) • Each participant has its own records in that subdoamin • SRV-record(s) for RADIUS service (‘radius2.dmz.telin.nl’) • A-record for each RADIUS server (‘195.169.17.13’) • CERT-record for each RADIUS server • self-signed is OK • ‘Being part of eduroam.org’ means adhering to the EDUROAM roaming agreements (that are not yet very well defined).

10. 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 RKE handler version: 1.0 RADIUS server RADIUS server 1 key: 0ffe92a690b255 ttl: 86400 version: 1.0 ok 3 push key/ttl to shared secret cache 4 push key/ttl to shared secret cache 2 client side server side

11. No 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

12. No 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

13. RKE 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

14. Conclusion • secure DNS can be a good foundation for EDUROAM • Extending EDUROAM with dynamic trust establishment (instead of hardwired links) can be done efficiently • Prototype implementation of RKE available • Prototype Radiator-RKE extension available Next steps • Real-life validation • Comparison with Diameter • Integrated with current Eduroam deployment environment

15. Backup slides (diameter/radius pki)

16. Alternative solutions -- Diameter Connect. Communicate. Collaborate See section 2.8.3 of RFC 3588 “Diameter Base Protocol” infra roam.org All connections between entities secured with IPSEC or TLS (using shared secret, PKI, …) DIAMETER server redirector (broker) static route 2 redirect to diameter.home.org 3 visiting visit.org DIAMETER server relay for other realms home 4 dynamic route; setup secure conn. home.org DIAMETER server 5 authenticate / authorize user@home.org 1 6 OK 7 visit.org user account db client e.g. 802.11 access point static route home.org user account db

17. Alternative 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? • Is there a way to deny incoming AA requests from parties that are not part of the roaming domain? I.e. can the home server check that the incoming request comes from an external server that is part of the routing domain? • Quality of implementations uncertain • Limited deployment experience

18. Alternatives: Radius-PKI Connect. Communicate. Collaborate infra All parties in the roaming domain use certificates issued by the roam.org CA roam.org Certificate Authority verify certificate radius.home.org verify certificate radius.visit.org 2a 2b visiting 2c visit.org 2d RADIUS server proxy for other realms setup IPSEC / TLS connection home 2 home.org RADIUS server 3 authenticate / authorize user@home.org 1 4 OK 5 visit.org user account db client e.g. 802.11 access point p2p home.org user account db

19. Alternative 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