1 / 13

TF-Mobility, Zagreb, 2 February 2006

eduroam-ng architecture Test results and way forward. Klaas.Wierenga@surfnet.nl. TF-Mobility, Zagreb, 2 February 2006. Current architecture. Main (technical) issues: No (real) authorisation  DAMe Static routing based on realm parsing Credentials pass through intermediate systems

jguffey
Télécharger la présentation

TF-Mobility, Zagreb, 2 February 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eduroam-ng architecture Test results and way forward Klaas.Wierenga@surfnet.nl TF-Mobility, Zagreb, 2 February 2006

  2. Current architecture • Main (technical) issues: • No (real) authorisation  DAMe • Static routing based on realm parsing • Credentials pass through intermediate systems • Transitive trust based on shared secrets • Dead peers hard to detect

  3. Evaluation of a number of approaches • Diameter: nearly shipping (for many years now ;-) • DNSsec: hardly deployed, new • RadSec: new, single vendor (Radiator), but not much more than a combination of existing technologies • DNSroam: see above

  4. Radius packet format Transport: TCP (or SCTP) Encryption: TLS (optional) TLS => PKI DNSROAM combines RadSec with DNS for dynamically locating the peer RadSec/DNSROAM

  5. Test setup • Participants: CESNET, ISTF, TELIN (NL), ARNES, ACAD (BG), UNINETT, RESTENA, Radiator (AU), SURFnet.

  6. Test set • Authentication related tests • Known user • Unknown user • Wrong credentials • PKI related tests • Certificate signed by unknown CA • Multiple CAs • Revoked certificate • Mismatch between peer name and CN • Wrong subjectAltName or CN in the certificate • DNS related tests • NAPTR lookup failure • SRV lookup failure • A lookup failure • Default handling after lookup failure • Fallback/defaulting to RADIUS • Fallback/defaulting to static RadSec • Configuration related tests • CA certificate not installed • Loop prevention (purposely introduce a loop and see if it can be stopped by introducing different config) • Connectivity related tests • Peer unreachable • Performance related measurements • Overhead of multiple DNS queries

  7. Fully hierarchical • One PKI, split PKI?

  8. Meshed toplevel • Central DNS zone?

  9. Fully meshed (DNSROAM) • Big trust issues: multiple PKI’s, bucket of certificates, revocation lists • Multiple federation membership? • Issues with sites having to open up their servers for ‘the world’ • How about a secure peer lookup service instead of DNS (eduGAIN?)

  10. Legacy model

  11. Measurements

  12. Results • All scenario’s can be made to work, but… • DNSROAM is not yet production grade • Static RADSEC is (thanks to us) stable enough to warrant using it when possible because of its advantages over plain RADIUS: • Failure detection • TCP • Peer authentication • Trust (PKI) issues are key factor in making this work

  13. What now? ? DNSROAM RadSec

More Related