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

2. Connect. Communicate. Collaborate Background 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

3. Connect. Communicate. Collaborate Trust - 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

4. Connect. Communicate. Collaborate Overview of this talk Limitations of EDUROAM Our RADIUS-DNSSEC solution –Overall architecture –DNS interaction –Secure connection establishment Alternative Solutions Current status & next steps

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

6. Connect. Communicate. Collaborate Problems 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

7. Connect. Communicate. Collaborate Our 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. –Retrieve A-records & certificates of authentication server from DNS –Set up a trusted association between home&visited server

8. Connect. Communicate. Collaborate Secure DNS scenario Connect. Communicate. Collaborate visiting client e.g. 802.11 access point RADIUS server proxy for other realms visit.org user account db home RADIUS server home.org user account db DNS server authoritative for roam.org p2p 1 authenticate / authorize user@home.org 6 2 3 4 5 OK roam.org visit.org home.org DNS server caching 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.org DNS infrastructure

9. Connect. Communicate. Collaborate Dynamic 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

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

11. Connect. Communicate. Collaborate IETF 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

12. Connect. Communicate. Collaborate Comparison RADIUS (DNSSEC) 1.Trust based on pre-configured set of roaming domains 2.DNS used to locate proper authentication server 3.Multiple roaming agreements? Select proper roaming-domain. 4.Dynamic secure connection setup 5.Insight in membership 6.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 server 3.Multiple roaming agreements? Select proper certificate. 4.Dynamic secure connection setup 5.No insight in membership 6.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

13. Connect. Communicate. Collaborate Conclusions 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

14. Connect. Communicate. Collaborate Backup slides (diameter/radius pki)

15. Connect. Communicate. Collaborate Alternative solutions -- Diameter Connect. Communicate. Collaborate visiting client e.g. 802.11 access point DIAMETER server relay for other realms visit.org user account db home DIAMETER server home.org user account db infra static route 1 authenticate / authorize user@home.org 6 OK roam.org visit.org home.org 7 5 2 DIAMETER server 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, …)

16. Connect. Communicate. Collaborate 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? –Quality of implementations uncertain –Limited deployment experience

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

18. Connect. Communicate. Collaborate 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

19. Connect. Communicate. Collaborate 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

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

21. Connect. Communicate. Collaborate 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

22. Connect. Communicate. Collaborate 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