AA aspects in some GN2 activities Maurizio Molina DANTE ( dante )

1. AA aspects in some GN2 activities Maurizio Molina DANTE (www.dante.net) maurizio.molina@dante.org.uk TF-EMC2 Meeting - 17th Feb 2005, Amsterdam

2. DANTE and GN2 www.geant2.net • Dante operates Geant Network, interconnecting European NRENS • Geant2 project (evolution of Geant NW) Started sep. 2004 • 4 Year project (FP6): evolution of Geant Network • Partners: DANTE (main contractor), Terena, NRENs • 3 Activity types: • Procurement • Service (SA) • Research (JRA) AA Needs…

3. SA3, JRA1, JRA3 needs for an AAI infrastructure • SA3: End-to-End Quality of Service • Needs AA to allocate Network resources • E.g. bandwidth allocated trough Premium IP Provisioning System (PIP PS); we’ll use this example throughout the following • JRA1: Network Measurement Infrastructure • Architecture jointly developed with I2 (Eric Boyd, Jeff W. Boote) • Needs AA to protect Measurement Data, Measurement Tools, Network resources from excessive active measurement traffic • JRA3: Bandwidth on Demand service • (problem space similar to SA3 - Not further covered in this presentation)

4. JRA1 – General (no AA) – Example of active Measurement Setup request

5. SA3 – general (no AA) • The user wants some guaranteed bandwidth spanning more than one domain (“Extended QoS Domain”). • In the request, only the end points of the path are specified • The request arrives at PIP PS of the domain where the starting point is • This PIP PS must fulfil the request for its domain and forward the request to the next PIP PS • The process is repeated up to the destination • The request succeeds if all PIP PSs can grant the request Granted/Denied Granted/Denied F Granted/Denied E PIP PS PIP B > D? PIP PS PIP PS D C PIP A > F? B PIP D > F? A

6. JRA1 – AA needs • Access to Measurement data (Meas Archive service) • AuthZ is access/deny based on local policies • Access to measurement resources (Meas Point service) • AuthZ is access/deny based on local policies + check if measurements are feasible • Enough resources within the MPs • Not conflicting within the network

7. JRA1 – AA flow (Meas. Point access) – case1 • Lookup Service is the entry point • It provides MP list, and AuthN Service(s) that can authenticate for them • Client chooses one AuthN service where he has an identity, and authenticates • Handle is returned, client goes to resource (MP) • AuthZ can involve multiple entities (MP, RP level1, RP level 2…) • More attribute can be asked back (as in Shibboleth model)

8. JRA1 – AA flow (Meas. Point access) – case 2 • More complicate flow in case a user hasn’t got an identity among the set of specified possible AuthN Service(s) where you can authenticate for the MP. • Is it really different from the previous one?

9. JRA1: Discussion: (feedback please…) • Lookup Service MUST accept unauthenticated queries (makes sense?) • Support for clients with multiple identities (is it in AA scope?) • Support for resources that have multiple owners (makes sense?) • Hierarchical distributed authZ (MP, RPlev.1, RP lev. 2…) (feasible?) • The AuthN Service for the realm manages the federation relationship on behalf of the other services in the realm (i.e. no SHIRE on MPs, Meas. Archives, etc.) (makes sense?) • Is case 1 different from case 2 (or can 1 collapse in 2?) • User making request may roam and already have network access in RI. Does this modify the AA model? (I guess NO…) • Which interface can JRA5 provide for JRA1’s prototype? (Timeline, Sep. 2005)

10. SA3 – AA needs • In terms of AA, An authN process is triggered ONLY because of the request to the PIP PS of first domain • Requests forwarded by the first PIP PS to other PIP PS will trigger only local AutZ • Let’s detail more the AA aspects… Granted/Denied Granted/Denied F Granted/Denied E PIP PS PIP B > D? PIP PS PIP PS D C PIP A > F? B PIP D > F? A

11. SA3 – AA Phase 1 • Restrictions: • Starting point A MUST be in user’s home domain • Authentication MUST happen within AuthN server of user’s home domain • Note: user may also be not “physically” attached to his home domain as shown in this picture Granted/Denied Granted/Denied Granted/Denied User’s Home Domain F PIP D > F? + ID Credentials + Attributes PIP B > D? + ID Credentials + Attributes PIP PS PIP PS PIP PS PIP A > F? + ID Credentials + Attributes AutZ policies AutZ policies AutZ policies E B C D AuthN server AuthN server AuthN server AuthN A

12. SA3 – AA Phase 2 • No more restrictions: • Starting PIP PS can be in whatever domain • User can start his authentication in remote domains Granted/Denied PIP D > F? + ID Credentials + Attributes User’s Home Domain PIP PS PIP PS PIP PS AutZ policies AutZ policies AutZ policies D AuthN server E AuthN server AuthN server AuthN F C AuthN PIP C > F? + ID Credentials + Attributes

13. SA3: AA Discussion (1/2) Phase 1 • Only 1 AuthN server plays a role • Full user identity and relevant attributes got from initial AuthN are simply passed along to AuthZ engines • Local policies need to be installed in ALL domains (same user may have different rights in different domains) • PIP servers need to trust each other for AuthN the user • How? Is this part of what JRA5 will provide? • How does the initial AuthN happen? i.e. SR3 expects JRA5 to provide a full set of interfaces for this case (e.g. not just refer to Shib, PAPI,..) • Timeline for a working AA solution: 31th May 05 Phase 2 • Two AuthN servers play a role (need of an Identity Federation) • But from second domain on, no AA difference from Phase 1

14. SA3: AA Discussion (2/2) - Identity and attribute structure • Identity: Hierarchical.. • Uk.kent.physics.prof_x • Users have single identities but can access the PIP PS for more projects. Need of at least another attribute for that • If user is registered for multiple projects he can be prompted to choose one. • PIP PSs will want to know the user’s identity and project anyway • No need of an identity hiding? • However, can identities and attributes be plaintext, for the AA system?

15. Backup slides

16. JRA1 – Main open Points • * support for clients with multiple identities * support for resources that have multiple owners (I can be convinced that this is overkill, but I am curious what you all think about this.) * hierarchical distributed authZ. For network measurements, you often need access to multiple resources, and you may need to contact different authZ servers for each of those different resources. We have discussed a hierarchical model for this so that control of a group of a resources can be collected and managed more easily. (This is the Resource Protector service described in the JRA1 docs.) * Federation trust relationships do not extend all the way to all of the independent services within the realm. The Authentication Service for the realm manages the federation relationship on behalf of the other services in the realm. • - I'm not sure if the first one is in scope (i.e. it's a simple replication of authentication, each time with different identities) - The second one seems to add some complications (although Diego says it's feasible). How "strong" are you about it? - On the third one, you explained during the last phone conference I attended why you want the RP (potentially hierarchical RPs) into the loop. I think I have understood your point and will try to make it to them. - on the fourth one, I think you mean that we require authentication  before accessing Service's resources (other than the LS). Or, putting it in "old" Shibboleth language, no resource has a SHIRE, but they only have a SHAR. Can you confirm it? Beyond that, I'll try to discuss the following: 1) what really differentiate the Single domain case from the multiple one? (Diego seems to suggest that in a federated environment there are in reality no differences) 2) Network access is different from Measurement resource access. So, even if we have accessed a remote network we still have to authenticate to use the Meas infrastructure 3) which type of interface is JRA5 providing us?

17. JRA1 – proposed AA flow (Meas. Point access) • Client queries Lookup service (LS) for MPs that match a given criteria. • LS returns a list of candidate MPs including an indication of the authentication realms that manage authentication for each one. (Each MP could actually be managed by more than one realm.) LS also returns the address of an AA service that can authenticate for each of the returned authentication realms. • Client contacts the AA service that manages authentication for the resource realm (R-AA-Service) and requests an authentication token blessed for use in the resource realm (R-AuthRealm). • R-AA-Service returns a list of known (federated) authentication realms and asks the client to choose one for authenticating. • Client specifies @R-AuthRealm • R-AA-Service manages identities for R-AuthRealm, so R-AA-Service asks client for identity credentials. • Client presents credentials. • If credentials are valid, R-AA-Service creates a handle that can be used to request additional attributes about the identity subject to attribute release policies in R-AuthRealm. This handle is returned to the client encoded as an AuthToken blessed by R-AuthRealm (R-AuthToken). • Client requests a measurement from MP. Request includes the R-AuthToken. • MP requests resources from the Resource Protector service (RP). The R-AuthToken is passed along in the request. • RP needs more information about the identity requesting the resources and makes an attribute query to R-AA-Service using the R-AuthToken handle. • R-AA-Service releases only as much information about the client identity as is allowed. • RP returns resource availability. (allowed/disallowed) This portion will include scheduling. • MP returns response to measurement request.

18. JRA1 – more in detail • Client queries Lookup service (LS) for MPs that match a given criteria. • LS returns a list of candidate MPs including an indication of the authentication realms that manage authentication for each one. LS also returns the address of an AA service that can authenticate for each of the returned authentication realms. • Client contacts the AA service that manages authentication for the resource realm (R-AA-Service) and requests an authentication token blessed for use in the resource realm (R-AuthRealm). • R-AA-Service returns a list of known (federated) authentication realms and asks the client to choose one for authenticating. • Client specifies desire to authenticate at F-AuthRealm. (JRA5 Terminology: Client specifies @F-AuthRealm.) • R-AA-Service does not manage F-AuthRealm so it redirects the client to F-AA-System. • Client contacts the AA service that manages authentication for the client-selected realm (F-AA-Service) and requests an F-AuthToken authentication token for use in R-AuthRealm (as in step 3.) • F-AA-Service returns a list of known (federated) authentication realms and asks the client to choose one for authenticating (as in step 4.) • Client specifies desire to authenticate at F-AuthRealm (as in step 5.) • F-AA-Service manages identities for F-AuthRealm, so F-AA-Service asks client for identity credentials (where credentials could be passwd, one-time token, finger print scan, etc.) (as in step 6, non-federated case.) • Client presents credentials (as in step 7.) • If credentials are valid, F-AA-Service creates a handle that can be used to request additional attributes about the identity subject to the attribute release policies in F-AuthRealm. This handle is returned to the client encoded as an AuthToken blessed by F-AuthRealm (F-AuthToken) (as in step 8.) • Client presents credentials to R-AA-Service. In the federated case, the credentials can be the authentication token from a federated authentication realm, in this case F-AuthToken. • R-AA-Service needs more information about the federated identity requesting access to R-AuthRealm protected resources and makes an attribute query to F-AA-Service using the F-AuthToken handle. • F-AA-Service releases only as much information about the client identity as is allowed. • If credentials are valid, R-AA-Service blesses the F-AuthToken for use with R-AuthRealm resources. This effectively creates an R-AuthToken but keeps the handle pointing back to the F-AA-Service for attribute queries. • Client requests a measurement from MP. Request includes the R-AuthToken. • MP requests resources from the Resource Protector service (RP). The R-AuthToken is passed along in the request. • RP needs more information about the identity requesting the resources and makes an attribute query. The query goes to the F-AA-Service. • F-AA-Service releases only as much information about the client identity as is allowed. • RP returns resource availability (allowed/disallowed.) This portion includes scheduling. • MP returns response to measurement request.