1. EuroPKI 2008 Manuel Sánchez Óscar Cánovas Gabriel López Antonio F. Gómez Skarmeta University of Murcia Levels of Assurance and Reauthentication in Federated Environments

2. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

3. EuroPKI 2008 Introduction Issue 1: Organizations offer more and more on-line authenticated services Level of Security based on the consequences derived from an authN error and misuse of credentials (Newspaper vs bank accounts) Definition of the authentication strength required to assure that an entity is the claimed entity Level of Assurance (LoA) Issue 2: Emergence of federated approaches to resource sharing Organizations granting users in any of them access to resources with a single identity stated by the organization the user belongs to Federations make use of SSO to avoid re-authentication Service Providers (SP) and Identity Providers (idP). InCommon, HAKA and SWITCH (Shibboleth), eduroam

4. EuroPKI 2008 Introduction But there are situations where the user needs to re-authenticate: Example 1: Alice is browsing the Web at home, using the idP by the ISP, She wants to access site restricted to users belonging to his work organization She needs to authN again against her organization Example 2: Several authN mechanisms with different LoAs are available For example: Login/pwd  access the network or read an e-mail PKC to digitally sign electronic documents

5. EuroPKI 2008 Introduction This work presents an infrastructure for re-authN process in federations SSO is used and authN is required initially to access the network Necessary to manage multiple user’s identities and LoAs Important : this functionality should be added without modifying the existing IdMs, such as Shibboleth, PAPI, etc.. New services should be included at a confederation level Connecting different existing federations Without modifying their internal protocols We make use of the eduGAIN middleware Work developed under the DAMe project Goal: to define a unified authN and authZ system for federated services hosted in the eduroam network

6. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

7. EuroPKI 2008 Level of Assurance Strength of authentication required for a relying party to be assured that an entity is indeed the claimed entity Two factors: Degree of trust to which the credential being presented actually represents the entity named in it  identity proofing Degree of confidence to which the represented entity actually is the entity engaging the electronic transaction  identity binding For IdP  Discrete assurance indicators that quantify the degree of protection the organization provides in the identity management For SP  Measures of the authN trustworthiness required to authorize the access to resources Higher LoAs are required to mitigate higher levels of risk

8. EuroPKI 2008 Level of Assurance US federal government (continuation of a UK gov. framework): minimal assurance of identity moderate assurance of identity substantial assurance of identity high assurance of identity Each LoA is appropriate for a different kind of electronic transaction National Institute of Standards and Technology (NIST) contributed with supplementary guidelines technical authentication requirements for the authentication simple password challenge-response  level 1 password through a secure authN protocol  level 2 soft cryptographic tokens  level 3 hard cryptographic tokens  level 4

9. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

10. EuroPKI 2008 eduGAIN eduGAIN: GÉANT Authorisation INfrastructure for the research and education community Defined by the TERENA GN2 project Objective: to build an interoperable AuthN and AuthZ Infrastructure (AAI) to interconnect different existing federations eduGAIN is responsible for: To find the federation where a roaming user belongs to To translate the messages between the federation internal protocols and eduGAIN and vice versa To establish the trust fabric among the participating institutions

11. EuroPKI 2008 eduGAIN Architecture overview

12. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

13. EuroPKI 2008 Use Case Alice requests a Service 1 (network, web, etc) at a Remote Institution Alice is redirected and authenticated in her Home Institution She obtains an authN token with LoA=1 (login/pwd) Contains data about the authN process (idP, LoA, …) Then she tries to access Service 2 that requires LoA=2 (PKC) She presents her authN token Alice does not have a valid token She is redirected to the appropriate authN service for LoA=2 to be re-authenticated She obtains a new token Alice is redirected and she gains access to Service 2

14. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

15. EuroPKI 2008 Architecture Several organizations acting as idP and SP IdPs are equipped with different authN methods She can try to access the resources using different identities SP must check that Alice makes use of the proper identity An authZ process may be necessary Validation process proposed must be transparent to the SP SP only has to deal with authN and attribute queries to the appropriate BE

16. EuroPKI 2008 Architecture BE are responsible for: recovering token validating redirecting Alice to the appropriate authN service Decisions can be delegated to a PDP (policies required) Confederation Metadata Service (MDS) to locate authN services Validation of the token and the re-authentication processes are carried out at the (con)federation level  they depend on global agreements among all the organizations.

17. EuroPKI 2008 Communication profile Initial network authentication and token delivery (eduroam-based) 1. AuthN request 2. Forwarded to the home institution (AAA) 3. User is authN 4. AuthN token generated by BE (transparent to service) 5. Token (LoA) is sent back to the user

18. EuroPKI 2008 Communication profile Token SAML-based Extension defined for LoAs Included in SAML 2.0 AuthnStatement

19. EuroPKI 2008 Communication profile LoA message profile (Access and Validation) 1. User acceses protected service (LoA=2) 2. Service (through BE) requests available user’s authN token 3. Token is validated by PDP (XACML)

20. EuroPKI 2008 Communication profile LoA message profile (redirection and re-authentication) 1. SP looks for a valid user’s idP for LoA=2 2. User redirection to idP 3. User is authN by idP and a new token (LoA=2) is generated and sent back

21. EuroPKI 2008 Communication profile LoA message profile (Validation and optional Local AuthZ) 1. User acceses protected service with new token (LoA=2) 2. Optional local AuthZ based on user attributes from his home instit.

22. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

23. EuroPKI 2008 Metadata management Defined by eduGAIN (based on SAML 2.0) Each Auth Service (idP) is described by means of a EntityDescriptor

24. EuroPKI 2008 LoA related policies Defined via XACML LoA hierarchical definition: LoA(x) inherit permissions of LoA (x-1) Two kind of policies: LoA Definition Policy (global) LoA Validation Policy (local)

25. EuroPKI 2008 LoA related policies LoA Definition Policy example

26. EuroPKI 2008 LoA related policies LoA Validation Policy example

27. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

28. EuroPKI 2008 Related Work: FAME (Flexible Access Middleware Extension) Shibboleth extension  provides multi-level user authN (LoAs) Based on the cryptographic strength of the authN protocol LoA value is added to the set of user’s attributes in the idP Passed to authZ decision engine together with user’s attributes Issue 1: it is oriented to web-based resources it does not link the initial authN to access the network with the authN in the Shibboleth IdP Issue 2: SP obtains LoA value after querying the idP for attributes if only authN and not authZ is required, there is no need for this additional exchange of messages Issue 3: How to locate idPs based on LoAs

29. EuroPKI 2008 Related Work: Cardspace and Higgins When the user tries to access some service, information card (IC) client recovers the SP policy to determine service reqs (authN) IC app. displays to the user his ICs satisfying those reqs IC app. contacts IdP that issued that card  gets signed token Finally, token is sent to the SP to get access to the service From the LoA point of view the use a SP policy provides the same functionality that the infrastructure that is described in this work But: They are user-centric solutions  open user communities This work is based on the existence of previously established organizations with their own users Organization must control the process to guarantee the existence and value of certain attributes and must maintain the control of the identification process

30. EuroPKI 2008 Agenda Introduction Level of Assurance eduGAIN Use Case Infrastructure for re-authentication Support for different Levels of Assurance Related work Conclusions

31. EuroPKI 2008 Conclusions Existence of different situations in an SSO federated environment where it is necessary for a user to reauthenticate related LoA is not secure enough to access the service Proposal for improving SSO by means of an infrastructure for validation and re-generation of SSO credentials Extending eduGAIN, a middleware for confederations, with the necessary services, protocols and policies for managing the validation of the user’s identity and the redirection process Based on SAML and XACML standards Covering from network service to application services Different kinds of federations such as Shibboleth and PAPI can interact Specific profile to base the identity validation in the LoA is described

32. EuroPKI 2008 Questions? gabilm@um.es Levels of Assurance and Reauthentication in Federated Environments

33. EuroPKI 2008 eduroam

34. EuroPKI 2008 DAMe Network authZ profile

35. EuroPKI 2008 DAMe Token-Based Web AuthN profile