Federated peering the NREN way: eduGAIN and eduroam

1. Federated peering the NREN way:eduGAIN and eduroam Diego R. Lopez (RedIRIS) Klaas Wierenga (SURFnet)

2. Contents • The drivers for (con-)federations (Diego) • The eduroam case (Klaas) • The eduGAIN case (Diego) • Universal single signon aka DAMe (Klaas)

3. The drivers for con-federations Giving federations a taste of their own medicine

4. As Federations Grow • The risk of dying of success • Do we really need to go on selling the federated idea? • Different communities, different needs • Not even talking about international collaboration • Different (but mostly alike) solutions • Grids and libraries as current examples • And many to come: Governments, professional associations, commercial operators,… • Don’t hold your breath waiting for the Real And Only Global Federation

5. ConfederationsFederate Federations • Same federating principles applied to federations themselves • Own policies and technologies are locally applied • Independent management • Identity and authentication-authorization must be properly handled by the participating federations • Commonly agreed policy • Linking individual federation policies • Coarser than them • Trust fabric entangling participants • Through each federation’s fabric • P2P trust must be dynamically built

6. First Steps • Simplifying user collaboration across whatever border is an excellent selling argument • Making the whole promise of the VO idea • eduroam fast worldwide success is a clear example • Following a middle-both-ways approach • Top-down: projects like GEANT2 • Bottom-up: initiatives like ShibEnableºº

7. Technologies • Lingua franca • Syntax: SAML (converging to 2.0) Shibboleth and eduGAIN profiles • Semantics: eduPerson, SCHAC • Trust fabric • Public key technologies (if not infrastructures) • Component identifiers and registries • Metadata repositories

8. Policy and Legal Matters • The PMA model has proven extremely useful • Consensual set of guidelines • Peer-reviewed accreditation • Legal matters: Hic sunt leones • For techies like us • Privacy • Liability • More or less manageable in the case of (national) federations

9. The eduroam case Confederation avant-la-lettre

10. The goal of eduroam • “open your laptop and be online” • To build an interoperable, scalable and secure authentication infrastructure that will be used all over the world enabling seamless sharing of network resources

11. eduroam concepts • Based on reciprocal (free) access • NREN community • Authentication at home • Authorisation at visited institution

12. Connect. Communicate. Collaborate eduroam: Ubiquitous Network Access Supplicant Authenticator (AP or switch) RADIUS server University A RADIUS server University B User DB User DB Gast piet@university_b.nl SURFnet Commercial VLAN Employee VLAN Central RADIUS Proxy server Student VLAN • Trust based on RADIUS plus policy documents • 802.1X • (VLAN assignment) signalling data

13. Connect. Communicate. Collaborate A General model for eduroam interactions Tue Oct 10 00:05:15 2006: DEBUG: Packet dump: *** Received from 145.99.133.194 port 1025 .... Code: Access-Request Identifier: 1 Authentic: k<145><206><152><185><0><0><0><249><26><0><0><208>D<1><16> Attributes: User-Name = "Klaas.Wierenga@guest.showcase.surfnet.nl" NAS-IP-Address = 145.99.133.194 Called-Station-Id = "001217d45bc7" Calling-Station-Id = "0012f0906ccb" NAS-Identifier = "001217d45bc7" NAS-Port = 55 Framed-MTU = 1400 NAS-Port-Type = Wireless-IEEE-802-11 EAP-Message = <2><0><0>-<1>Klaas.Wierenga@guest.showcase.surfnet.nl Message-Authenticator = <27>`-y<208><232><252><177>.<160><230><177>I<218 ><243>\ Tue Oct 10 00:17:32 2006: DEBUG: Handling request with Handler 'TunnelledByTTLS= 1, Realm=/guest.showcase.surfnet.nl/i' Tue Oct 10 00:17:32 2006: DEBUG: Deleting session for Klaas.Wierenga@guest.show case.surfnet.nl, 145.99.133.194, Tue Oct 10 00:17:32 2006: DEBUG: Handling with Radius::AuthFILE: SC-GUEST-ID Tue Oct 10 00:17:32 2006: DEBUG: Reading users file /etc/radiator/db/showcase-gu est-users Tue Oct 10 00:17:32 2006: DEBUG: Radius::AuthFILE looks for match with Klaas.Wie renga@guest.showcase.surfnet.nl [Klaas.Wierenga@guest.showcase.surfnet.nl] Tue Oct 10 00:17:32 2006: DEBUG: Radius::AuthFILE ACCEPT: : Klaas.Wierenga@guest .showcase.surfnet.nl [Klaas.Wierenga@guest.showcase.surfnet.nl] Tue Oct 10 00:17:32 2006: DEBUG: AuthBy FILE result: ACCEPT, Tue Oct 10 00:17:32 2006: DEBUG: Access accepted for Klaas.Wierenga@guest.showca se.surfnet.nl Tue Oct 10 00:17:32 2006: DEBUG: Returned TTLS tunnelled Diameter Packet dump: Code: Access-Accept RADIUS + TLS Channel(s) RADIUS@visited RADIUS@home Resource (AP) Id Repository

14. Connect. Communicate. Collaborate (virtual) eduroam root . . . . European root APAN root (America’s root) .nl .au .edu . . . .ac.uk . . . . . . .cn .us .dk .hr . . . .es eduroam Hierarchy

15. eduroam Confederations • Regions have their own stage of development and pace • Regions have their own regional policies (with delegation to national federations) • Policies will be aligned as much as possible

16. The European eduroam Policy • Mutual access • Home institutions are/remain responsible for their users abroad • Members are European NRENs • Members guarantee required security levels by their participants • Members promote eduroam in their countries • European eduroam may peer with other regions

17. National Policies • Mutual access • Members are connected institutions • Home institution is/remains responsible for its users behaviour. • Home institution is responsible for proper user management • Home and visited institution must keep sufficient logdata • Appropriate security levels

18. Limitations • Authentication = authorisation • Hierarchical trust establishment AND hierarchical routing of access requests • Transitive trust • No dynamic trust establishment • Use of UDP • Use of shared secrets

19. eduroam-ng • After evaluating Diameter, RadSec and DNSROAM: • Introduction of RadSec (if possible) • TCP instead of UDP • TLS between RADIUS-servers instead of shared secrets • Possibly at later stage introduction of DNSROAM • Support for direct peer interaction • How about firewalls / access lists? • Eventually Diameter?

20. The eduGAIN case Exercising the confederation concepts

21. The AAI Goal in GÉANT2 • To build an interoperable authentication and authorisation infrastructure that will be used all over Europe enabling seamless sharing of e-science resources • We started from • Scattered AAI (pilot) implementations in the EU and abroad • The basic idea of federating them, preserving hard-won achievements

22. Applying Confederation Concepts • An eduGAIN confederation is a loosely-coupled set of cooperating identity federations • That handle identity management, authentication and authorization using their own policies • Trust between any two participants in different federations is dynamically established • Members of a participant federation do not know in advance about members in the other federations • Syntax and semantics are adapted to a common language • Through an abstract service definition

23. The eduGAIN Components • Bridging Elements (BE) • Interconnection points • Federation-wide (LFA) or distributed (LA) • Federation Peering Point (FPP) • Able to announce BE metadata • The Metadata Service (MDS) • Publishing interface (to FPPs) • Querying interface (to BEs)

24. Connect. Communicate. Collaborate The eduGAIN Model Metadata Query MDS Metadata Publish Metadata Publish R-FPP H-FPP R-BE H-BE AA Interaction AA Interaction AA Interaction Resource(s) Id Repository(ies)

25. Component Identifiers • eduGAIN operations strongly depend on having unique, structured and well-defined component identifiers • Based on URNs delegated by the eduGAIN registry to the participating federation • Identifiers establish the kind of component they apply to by means of normalized prefixes • Identifiers follow the hierarchy of the trust establishing process

26. The (X.509) Trust Fabric • Validation procedures include • Normal certificate validation • Trust path evaluation, signatures, revocation,… • Peer identification • Certificates hold the component identifier • It must match the appropriate metadata • Applicable to • TLS connections between components • Two-way validation is mandatory • Verification of signed XML assertions

27. Connect. Communicate. Collaborate urn:geant2:...:requester urn:geant2:...:responder A general model for eduGAIN interactions https://mds.geant.net/ ?cid=someURN <samlp:Request . . . RequestID=”e70c3e9e6…” IssueInstant=“2006-06…”> . . . </samlp:Request> <samlp:Response . . . ResponseID=”092e50a08…” InResponseTo=“e70c3e9e…”> . . . </samlp:Response> MDS TLS Channel <EntityDescriptor . . . entityID= ”urn:geant2:..:responder"> . . . <SingleSignOnService . . . Location= “https://responder.dom/” /> . . . TLS Channel(s) Requester Responder Resource Id Repository

28. Operation Mapping • Maps the abstract service definition into actual protocols • Current version is based on SAML 1.1 • Profiling the standard to fit abstract parameters • A SAML 2.0 implementation will be available along the lifetime of the project • The abstract service specification protects components and applications from these changes • Authentication assertions and attribute exchange mechanisms are designed to be Shibboleth 1.3 compatible • And Shibboleth 2 in the future

29. Metadata Service • Based on REST interfaces transporting SAML 2.0 metadata • Metadata are published through POST operations • Metadata are retrieved through GET operations • URLs are built as MDSBaseURL/FederationID/entityID?queryString • Using component names • The query string transports data intended to locate the appropriate home BE (Home Locators) • Hints provided by the user • Contents of certificate extensions (SubjectInformationAccess)

30. eduGAIN Profiles • Three profiles defined so far • Web SSO (Shibboleth compatible) • Automated client (no human interaction) • Non-web client (use of SASL-CA) • Others envisaged • Extended Web SSO (allowing the send of POST data) • eduGAIN usage from roaming clients (DAMe) • Based on SAML 1.1 • Mapping to SAML 2.0 profiles along the transition period

31. Connect. Communicate. Collaborate A Sample Profile

32. DAMe aka “The holy grail”

33. Deploying Authorization Mechanisms for Federated Services in eduroam (DAMe) • DAME is a project that builds upon: • eduroam, which defines an inter-NREN roaming architecture based on AAA servers (RADIUS) and the 802.1X standard, • Shibboleth and eduGAIN • NAS-SAML, a network access control approach for AAA environments, developed by the University of Murcia (Spain), based on the SAML (Security Assertion Markup Language) and the XACML (eXtensible Access Control Markup Language) standards.

34. Connect. Communicate. Collaborate Supplicant Authenticator (AP or switch) RADIUS server University A RADIUS server University B User DB User DB SURFnet Central RADIUS Proxy server First Goal: Extension of eduroam Using NAS-SAML First Goal: extNA Policy Decision Point Source Attribute Authority XACML Gast piet@university_b.nl • User mobility controlled by assertions and policies expressed in SAML and XACML Signaling data SAML

35. Connect. Communicate. Collaborate First Goal: extNA Second Goal: eduGAIN as AuthN and AuthR Backend • Link between the AAA servers (now acting as Service Providers) and eduGAIN

36. Connect. Communicate. Collaborate First Goal: extNA Third Goal: Universal Single Sign On • Users will be authenticated once, during the network access control phase • The eduGAIN authentication would be bootstrapped from the NAS-SAML • New method for delivering authentication credentials and new security middleware

37. Summary and conclusions

38. Summary • Educational federations are happening • And suffering their first growing pains • Convergence to (small number of) standards • In the SAML orbit • International confederations are emerging • eduroam • Géant2 AAI (eduGAIN) • The twain will ever meet • Using the same principles and standards