1. Image © Viatour Luc (http://www.lucnix.be) Project Moonshot TNC 2010 Vilnius, 1 June 2010 Josh Howlett, JANET(UK)

2. Contents Why Project Moonshot? Technical Architecture & Specifications Deliverables and plans Partners & Contributors Get involved!

3. Background “The Identity Messy-system" (TNC 2008) TERENA TF-EMC2 Beyond Web SSO work item JANET(UK) use-case categories 1.Beyond Web SSO - to extend the scope of federated identity to many more services. 2.Scalable Trust - to manage trust for “many more services”.

4. Goals To deliver – a standardised technical architecture. – production-quality open-source implementation. – packaged and shipped with Debian Linux. – a test-bed for interoperability testing. – high quality documentation. – an active community of users and developers. Enabling – implementation on all commonly used computing platforms. – and use by deployers and users. Highly ambitious but achievable.

5. Non-Web SSO Use-Cases 1)Support federated authentication to out- sourcing providers. 2) High Performance Computing Address HPC community requirements (Business Continuity & HPC-as-a-service) Federated SSH, NFS, CIFS

6. Learning from Web SSO In creating federated authentication for new applications, avoid problems discovered with web SSO today - and fix it for web SSO. Identity Provider discovery User presented with hundreds of possible identity providers; inter-federation (e.g. eduGAIN) will likely increase this to thousands quite soon. Multiple affiliations Sometimes difficult to choose the correct identity for a given service.

7. Proposed benefits Users – Sign-on using one or more identities to desktop applications that support the technology. – Ability to easily select an identity, addressing the "discovery" and "multiple affiliation“ problems.

8. Proposed benefits Institutions – Increases the ROI made in federated identity services, by expanding its use to a greater range of applications. – Mitigates the effort required to support different authentication technologies and credentials for different services.

9. Proposed benefits Service Providers – Introduces the benefits of SAML-based federated identity to new types of services. – Addresses some of the issues associated with the conventional Web SSO profiles, including the "discovery" problem. – The technology, when used with a web browser, could co-exist with conventional Web SSO profiles, enabling a smooth transition.

10. Proposed benefits Federation operators – Permits the use of role descriptors in SAML metadata that do not include keys or credentials of any kind, or references to these. – Permits the use of unsigned SAML metadata while providing a means to demonstrate trustworthiness, including real-time revocation. – Permits the use of any kind of metadata distribution mechanism; this does not need to be trusted.

11. Proposed benefits SAML implementations – A single SAML-based SSO profile for any application supporting GSS or SASL. – SAML entities can use almost any type of credential to authenticate itself; communicating SAML implementations do not need to understand each others credential types. – Credential and key management can be delegated entirely outside of the SAML implementation.

12. Vision Users have a single interface to manage the use of their credentials and identities for both networks and applications. Developers have access to a standard API for consuming federated identity. Standards developers can more easily design protocols that use federated identity, without becoming experts on federated identity.

13. EAP lower layer (e.g. 802.11) EAP peer (Supplicant) EAP authen ticator EAP lower layer (e.g. 802.11) AAA client AAA server EAP server ClientService ProviderIdentity Provider Moonshot architecture GSS-API Application (e.g. SFTP) GSS-API Application (e.g. SFTP) SAML IdP OpenSEA supplicant GSS library Applications GSS library FreeRADIUS Shibboleth IdP By analogy with eduroam

14. Specifications IETF – “A RADIUS attribute for SAML constructs” http://tools.ietf.org/html/draft-howlett-radius-saml-attr – “A GSS-API Mechanism for the Extensible Authentication Protocol” http://tools.ietf.org/html/draft-howlett-eap-gss – “Key Negotiation Protocol” Work in progress

15. Specifications OASIS – “SAML V2.0 AAA Binding” http://www.project-moonshot.org/sites/default/files/sstc- saml-binding-aaa-draft-00.pdf – “SAML V2.0 EAP GSS SSO Profile” http://www.project-moonshot.org/sites/default/files/sstc- saml-eapgss-sso-draft-00.pdf – “Metadata Trust Management Profile” Work in progress

16. “This looks complex” It’s equivalent to eduroam or any Enterprise WiFi implementation. The new SAML binding and SSO profile are at least as simple as the conventional SAML V2.0 bindings and SSO profiles. It looks complex because it’s an unusual composition of technologies.

17. “It requires too many changes” Most of the changes are small. Most of the changes are desirable independent of Moonshot. Most applications that support GSS-API or SASL today can be modified to support Moonshot at little effort.

18. What have we achieved so far? Phases 1-3 (January 2010  April 2010) – Feasibility Analysis – Draft specifications for all core technologies – Bar BOF @ IETF 77 Phase 4 (April  June) – Draft project plan See http://www.project-moonshot.org/plan – IETF Working Group charter

19. What’s next? Phase 5 (June 2010  August 2010) – IETF 78 BoF preparation – Updates to draft specifications. – Complete project plan. Phase 6 (August 2010  July 2011) – Advance specifications through IETF and OASIS. – Perform implementation work. – Implement test-bed demonstrating use-cases.

20. Final deliverables Advanced set of draft specifications documenting the complete architecture. Production quality code. Packaged and shipping in Debian Linux. Test-bed for interoperability testing. High quality documentation.

21. Who’s participating? JANET(UK) (~1.5 FTE) – Project management: Josh Howlett and Henry Hughes – Technical architecture: Josh Howlett and Sam Hartman – Software architecture: Sam Hartman – FreeRADIUS & Shibboleth modifications, and GSS library implementation: Consultants – Testing and documentation: Rhys Smith (Cardiff)

22. Who’s participating? GÉANT (2-3 FTE) – Apache GSS implementation: Daniel Kouril and Michal Prochazka (CESNET/Masaryk University) – Firefox GSS implementation: Daniel Kouril and Michal Prochazka (CESNET/Masaryk University) – GSS consultancy: Simon Wilkinson (JANET/Edinburgh) – RadSec library implementation: Linus Nordberg (NORDUNET) – Test-bed implementation: Miroslav Milinovic (CARNET/SRCE) – Specification review: Stefan Winter (RESTENA)

23. Other important relevant work GSS Naming Extensions: Leif Johannson (NORDUNET) “RadSec”: Stefan Winter (RESTENA)

24. How to participate Before December 2010 – Use-cases, use-cases, use-cases. – Specification review. – Join the mailing list. – Get involved in the proposed IETF Working Group (intended BoF @ IETF 78 in Maastricht, 26-30 July) After December 2011 – Moonshoot commonly used applications. – Packaging for other distributions. – Implement local test-beds.

25. Thank you for your attention! Any questions? http://www.project-moonshot.org https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community josh.howlett@ja.net