Transcript - TERENA

Connect. Communicate. Collaborate
Combining RADIUS with Secure
DNS for Dynamic Trust
Establishment between Domains
Henk Eertink†, Arjan Peddemors†, Roy
Arends†, Klaas Wierenga‡, Remco
Poortinga†
‡
†
Background
Connect. Communicate. Collaborate
• 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
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
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
Connect. Communicate. Collaborate
Connect. Communicate. Collaborate
EDUROAM Architecture
EDUROAM infra
Shared keys
2
visiting
3
5
visit.org
roam.org
RADIUS
Shared key
proxy for
other realms
1
4
home
home.org
OK
Shared key
RADIUS
server
6
client
e.g. 802.11
access point
p2p
visit.org
user
account db
home.org
user
account db
Problems of RADIUS-proxy chaining
Connect. Communicate. Collaborate
• 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
Our approach: Trust via secure DNS
Connect. Communicate. Collaborate
• 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. Collaborate
Secure DNS scenario
roam.org
secure lookup radius
server associated with
home.org.roam.org
DNS server
authoritative
for roam.org
3
visiting
visit.org
4
DNS server
A:111.222.111.222
CERT:key=a;sd98yhq3ra
caching
forwarder
secure lookup radius 2
server associated with
home.org.roam.org
5
establish connection
dynamically 6
RADIUS
server
authenticate / authorize 1
[email protected]
client
e.g. 802.11
access point
proxy for
other realms
9
DNS
infrastructure
7
8
home
home.org
RADIUS
server
OK
p2p
visit.org user
account db
home.org
user
account db
Dynamic setup of secure connection
Connect. Communicate. Collaborate
• This is not supported by RADIUS
• For our prototype we defined our own RADIUS keyestablishment 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
RADIUS Key Exchange Protocol
(RKE)
•
Connect. Communicate. Collaborate
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
version: 1.0
key: 0ffe92a690b255
ttl: 86400
1
RKE handler
version: 1.0
ok
3
4
push key/ttl
to shared
secret cache
2
push key/ttl
to shared
secret cache
RADIUS server
RADIUS server
client side
server side
IETF alternative: DIAMETER
Connect. Communicate. Collaborate
• 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
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 keyestablishment protocol, or support for
TLS/ipsec in RADIUS itself
9. DNSSEC has not seen a lot of
deployment
Connect. Communicate. Collaborate
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
Conclusions
Connect. Communicate. Collaborate
• 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. Collaborate
Alternative solutions -- Diameter
See section 2.8.3 of RFC 3588
“Diameter Base Protocol”
infra
roam.org
DIAMETER
server
All connections between entities
secured with IPSEC or TLS
(using shared secret, PKI, …)
2
visiting
visit.org
redirector
(broker)
static
route
redirect to
3
diameter.home.org
DIAMETER
server
authenticate /
authorize
1
[email protected]
client
e.g. 802.11
access point
relay for
other realms
4 dynamic route;
setup secure conn.
5
6
7
static
route
home
home.org
DIAMETER
server
OK
visit.org user
account db
home.org
user
account db
Alternative Solutions - DIAMETER
Connect. Communicate. Collaborate
• 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 RADIUSDNSSEC?
– Quality of implementations uncertain
– Limited deployment experience
Connect. Communicate. Collaborate
Alternatives: Radius-PKI
infra
All parties in the roaming
domain use certificates issued
by the roam.org CA
roam.org
Certificate
Authority
verify certificate
radius.home.org
2a
visiting
2b
2c
visit.org
RADIUS
server
authenticate /
authorize
1
[email protected]
client
e.g. 802.11
access point
2 setup IPSEC /
TLS connection
proxy for
other realms
3
4
5
p2p
verify certificate
radius.visit.org
2d
home
home.org
RADIUS
server
OK
visit.org user
account db
home.org
user
account db
Alternative Solutions – RADIUS / PKI
•
•
Connect. Communicate. Collaborate
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
No RKE? Alternative1: RADIUS/TLS
Connect. Communicate. Collaborate
• 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
No RKE? Alternative2: RADIUS/DTLS
Connect. Communicate. Collaborate
• 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
RKE Alternatives: IPSEC
Connect. Communicate. Collaborate
• 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