Transcript - Wierenga

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 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
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
2
visiting
3
5
visit.org
RADIUS
p2p
proxy for
other realms
1
roam.org
4
p2p
home
home.org
OK
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
• 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
Connect. Communicate. Collaborate
Our approach: leverage secure DNS
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
RADIUS-DNSSEC summary
Connect. Communicate. Collaborate
1. 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
2. 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)
3. Use peer-to-peer RADIUS over a secured connection
– Without any changes to the RADIUS protocol
Connect. Communicate. Collaborate
Details: dns interaction
RADIUS server
_radius._udp.home.org.roam.org SRV ?
rs1.visit.org
2
0 0 1812 rs1.home.org.roam.org
1 0 1812 rs2.home.org.roam.org
3
rs1.home.org.roam.org A ?
realm/domain:
visiting.org
4
14
12
13
RADIUS server
rs1.home.org
10.10.0.200
6
X509: RSA Public Key: 08:A8:F7:…
DNS
15
rs1.visit.org.roam.org A ?
9
realm/domain:
home.org
8
10.0.0.100
rs1.visit.org.roam.org CERT ?
11
IP number:
10.10.0.200
5
rs1.home.org.roam.org CERT ?
RADIUS
traffic
TLS session
end
shared secret
exchange
TLS session
established
start TLS
session
IP number:
10.0.0.100
7
1
10
X509: RSA Public Key: 65:A4:DB:…
DNS structure
•
•
•
•
Connect. Communicate. Collaborate
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).
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
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
Conclusion
Connect. Communicate. Collaborate
• 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
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 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
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