1. PRACE user authentication and vetting Vincent RIBAILLIER, 29 th EUGridPMA meeting, Bucharest, September 9 th, 2013

2. PRACE user authentication and vetting I.Overview of the current PRACE user registration process II.Use case for the IOTA profile in PRACE III.PRACE review of the IOTA profile

3. The PRACE security model Authentication X.509 certificates (EUGridPMA, IGTF) Services using X.509 authentication : GSI-SSH, UNICORE, GridFTP, GRAM, web services SSO (MyProxy server) Authorization LDAP used as an authorization database Fine grained management Attributes associated to projects (groups of persons) Attributes associated to accounts Accounting Distributed database (DART for access) Accounting records compliant to OGF Usage Record format

4. b) Federated User Administration c) Authorized Access to Resources a) PRACE Project Administration site B site C site A LDAP user DB allowed User authz Review DB Project attributes user DB user DB User registration in PRACE (1/2)

5. User registration is done by each partner for users from their country or by assignment. User is only registered once for all sites. Rules are not very explicit for Tier-1 sites. It is assumed that sites have a contract with the user that they register and that they have a clear evidence on how to trace the user. User registration in PRACE (2/2)

6. Information collected by sites and published in LDAP -First name, last name -Email -Telephone number -Certificate subject DN -Nationality -Login details, group memberships, organization (« Home site ») …

7. Why do we need this information ? -Site local policies require a clear traceability (no anonymous access on the execution sites). -Some sites need this information to initiate a local authorization procedure which can lead in the worse cases to access refusal.

8. PRACE user authentication and vetting I.Overview of the current PRACE user registration process II.Use case for the IOTA profile in PRACE III.PRACE review of the IOTA profile

9. What could be the use case for the IOTA profile ? A CA compliant to the IOTA profile could be used by : -An organization which would like to collaborate with PRACE. -More generally, any new partner that would wish to join PRACE.

10. So, is the IOTA profile acceptable for PRACE ? Yes, as long as PRACE and the joining organization can organize themselves to meet the traceability requirement : User should never access the PRACE environment anonymously. An execution site (site providing computing resources to PRACE users) should have an immediate access to the user details. This can be achieved with a distributed database like the PRACE LDAP. A prerequisite would be that all partners have solid procedures to register users. An internal meeting will be organized to define more clearly the criteria of these procedures.

11. This profile may be accepted by PRACE if we are convinced that for every internal registered user we have enough information to trace that user. (the next two slides quote parts form the profile which make clear why we need the above requirement) Users from other infrastructures can only be accepted if that infrastructure has the same requirement for traceability of the user and can provide us with this information if asked for (in agreed situations).

12. General architecture Authorities are not required to collect more data than are necessary for fulfilling the uniqueness requirements. Credentials issued by authorities under this profile may not provide sufficient information to independently trace individual subscribers, and should be used in conjunction with complementary identification and vetting processes. Traceability of the credential is provided only in a cooperative way jointly with other parties that provide other elements of identity-related data. Credentials issued by authorities operating under this Authentication Profile should be used primarily in conjunction with vetting and authentication data collected by the relying parties, such that there is less need for collecting data that would otherwise duplicate efforts already performed by such relying parties. 12

13. Traceability Requirements At credential issuing time, the authority must reasonably demonstrate how it can verify identity information and trace this information back to a physical person (or for non-human credentials to a named group). At the time of issuance, the authority may rely in good faith on any identity management system by a third party with which it has entered into an agreement and that meets the requirements on third parties set forth in the General Architecture. 13

14. PRACE user authentication and vetting I.Overview of the current PRACE user registration process II.Use case for the IOTA profile in PRACE III.PRACE review of the IOTA profile

15. PRACE review of the IOTA profile Reference http://wiki.eugridpma.org/Main/IOTASecuredInfraAP Only a few comments 15

16. Naming No anonymous credentials may be issued under this profile. what is an anonymous credential? Renewal and re-keying that the entity requesting this renewal or re-keying is the same entity as the one to whom the original credential was issued Under persistency: In case the subject name is assigned to a non- human entity, the owner, being a human person or organisational group, should initiate the identification process. So if the owner left or group doesn’t exist anymore, no renewal is possible? 16 PRACE review of the IOTA profile

17. Certificate profile Reference to GFD.125 (OGF document) should be provided Security requirements “current IT industry best practices for security sensitive systems.” is vague. Audits The auditing does not necessarily extend to identity vetting systems operated by third parties and used for credential issuance. Why not? 17 PRACE review of the IOTA profile

18. Privacy and confidentiality “ The authority is not required to release such information. “ Propose to replace “such” by “private information” 18 PRACE review of the IOTA profile

19. Conclusion IOTA profile is in principle acceptable for PRACE as long as organizations using this profile can satisfy the PRACE registration and traceability requirements. Traceability is already well managed in PRACE. Registration requirements will have to be more formally defined.