1. Identity Management Levels of Assurance WLCG GDB CERN, 8 Apr 2009 David Kelsey STFC/RAL david.kelsey AT stfc.ac.uk

2. Introduction I represent WLCG on the PMAs of the International Grid Trust Federation (IGTF) –A “relying party” member –Our needs should be taken into account For years the various identity vetting and naming rules have been stable Now new large-scale academic federations are being deployed –And there are new IGTF Authentication profiles We need to confirm or redefine the WLCG position on these matters 8 Apr 20092Identity Management - D Kelsey

3. History EU DataGrid CA Coordination Group –Started back in Dec 2000 No clear statement of identity assurance requirements (what quality was required) –We knew we had to meet the needs of many VOs and Sites (some with serious security needs) –Deliberately raised the “bar” fairly high Min Requirements (V1 – March 2001) – was vague! –An acceptable procedure for confirming the identity of the requestor and the right to ask for a certificate e.g. by personal contact or some other rigorous method 8 Apr 2009Identity Management - D Kelsey3

4. History (2) “acceptable procedure” was gradually refined to be –Face-to-face identity vetting with valid government or official photo-ID (requestor to RA) –Some CAs (e.g. DOEGrids) had “trusted third parties” to do the vetting At that time, not properly described in text CA Coordination Group agreed it was acceptable 8 Apr 2009Identity Management - D Kelsey4

5. Classic CA – current profile (V4.2) Traditional X.509 PKI Certification Authority –Issues long-lived (12 months) certificates Identity rules –Uniqueness and Persistence –Any single subject distinguished name must be linked to one and only one entity –Over the entire lifetime of the CA it must not be linked to any other entity a single entity may have more than one associated subject name, e.g., for different key usages –IGTF ensures that the namespaces of the accredited CAs do not overlap (do not need to use the issuer name) 8 Apr 2009Identity Management - D Kelsey5

6. Classic CA (2) Registration Authority (RA) –Responsible for identity vetting of all end-entities the subject should contact the RA face-to-face and present photo-id and/or valid official documents showing that the subject is an acceptable end entity as defined in the CP/CPS document of the CA The CA or RA should have documented evidence on retaining the same identity over time. The CA is responsible for maintaining an archive of these records in an auditable form. 8 Apr 2009Identity Management - D Kelsey6

7. Classic CA (3) Naming rule –If a commonName component is used as part of the subject DN, it should contain an appropriate presentation of the actual name of the end- entity This gives a so-called “warm and fuzzy” feeling to VO managers during user registration. A chance the person is who they claim to be. Renewal –The CA or RA should have documented evidence on retaining the same identity over time Usually means keeping a copy of the photo-ID –Name persistence is very important 8 Apr 2009Identity Management - D Kelsey7

8. MICS CA Member Integrated Credential Services (profile v1.0) An automated CA that issues X.509 credentials to end entities based on an external primary source of identity –A federation or large organisation –With a well established Identity Management System (e.g. Kerberos, Active Directory) Credentials may be long-lived (1 year) The end-entities possess and control their key pair and their activation data. Certificates are aimed to be fully compatible with Classic certificates –Requirements on identity vetting and naming are the same as the Classic profile The CERN CA is a good example 8 Apr 2009Identity Management - D Kelsey8

9. SLCS CA Short Lived Credential Service (profile V2.1) An automated service The SLCS CA translates credentials (usually authentication tokens) issued from a large site or federation into the X.509 format suitable for use on Grids intended for situations where identity tokens are available from an existing identity service that may not be suitable as the foundation for the creation of long-lived certificates legacy authentication and identity services may have uncertainties about revocation, or other management issues, that preclude translating them into long-term credentials SLCS credentials have lifetime less than 1Msec 8 Apr 2009Identity Management - D Kelsey9

10. SLCS CA (2) The profile currently requires uniqueness and persistence –Any single subject distinguished name (DN) in a certificate must be linked with one and only one entity for the whole lifetime of the service –Validation of the certificate request establishes the permanent binding between the end-entity, the registered owner, and the subject DN name –This is to ensure that the name, when subsequently reissued, refers to the same end- entity 8 Apr 2009Identity Management - D Kelsey10

11. SLCS CA (3) Sufficient information must be recorded and archived such that the association of the entity and the subject DN can be confirmed at a later date Qualifying IdMs must suspend or revoke authorization to use the service if the traceability to the person is lost. Suspension or revocation must last until identity is updated and confirmed according to IdM policies No face to face identity vetting required –But… 8 Apr 2009Identity Management - D Kelsey11

12. SLCS CA (4) The CP/CPS must describe: How the identity (DN) assigned in the certificate is unique within the namespace of the issuer How it attests to the validity of the identity How the identity (DN) assigned in the certificate will never be re- issued to another end-entity during the entire lifetime of the CA How it provides DN accountability, showing how they can verify enough identity information to trace back to the physical person for at least one year from the date of certification, and in keeping with audit retention requirements. In the event that documented traceability is lost, the DN must never be reissued Warm and Fuzzy feeling still required! commonName component should contain an appropriate presentation of the actual name of the end-entity. 8 Apr 2009Identity Management - D Kelsey12

13. IGTF SLCS CAs WLCG/EGEE today trusts all IGTF accredited CAs –Classic, MICS and SLCS There are a number of IGTF accredited SLCS CA –FNAL KCA (awaiting operational review) –Switch CA (Shibboleth) –NERSC, NCSA, … More on the way – large-scale federations –DFN, Nether-Nordic, … Some are also out there but not accredited –UK Shibboleth CA (no warm and fuzzy name) 8 Apr 2009Identity Management - D Kelsey13

14. Academic AAI federations Many (most?) NRENs are implementing a national Authentication and Authorisation Infrastructure (AAI) –A federated access service –Identity managed by home institutes (IdP) –Gives access to Service Providers anywhere in the federation (SP) Some are based on Shibboleth (Internet2) –But there are other implementations International interoperation is being coordinated by Geant, TERENA, etc – access to services anywhere “Eduroam” (wireless roaming): an early success story 8 Apr 2009Identity Management - D Kelsey14

15. Where are you from? Remote authentication 8 Apr 2009Identity Management - D Kelsey15 IdP SP Example from Switch AAI

16. Identity Schema eduPerson (USA) and SCHAC (EU) Attributes of interest to IGTF world … –eduPersonPrincipalName (ePPN) "user@scope“ But private information – IDPs usually refuse to release IdP does not guarantee long-term persistence – eduPersonTargetedID (ePTID) (Commonly used) A persistent, non-reassigned, privacy-preserving identifier for a principal shared between a pair of coordinating entities –auEduPersonSharedToken (Australian Schema) An identifier enabling federation spanning services such as Grid and Repositories Unique, opaque and persistent (displayName may be added) E.g. “John Citizen ZsiAvfxa0BXULgcz7QXknbGtfxk)” 8 Apr 2009Identity Management - D Kelsey16

17. Problems with Academic Federations and SLCS Several AAI federations now want to implement an IGTF accredited SLCS CA (DFN, Nether-Nordic) –The CA is an AAI Service Provider –User authenticates in the normal AAI way Gets a short lived certificate IdP will not release ePPN Could use ePTID (lots of federations would like this) –But opaque (and not long-term persistent) There may be pressure on IGTF to relax the current rules on naming in the SLCS profile –How should WLCG respond to this? 8 Apr 2009Identity Management - D Kelsey17

18. Advantages of federated SLCS There are many advantages to institutes managing the user’s identity –A natural place to manage identity (just once) –User authenticates to SLCS CA in the same way as for other services –No additional RA checks –For large-scale Grid use a good way of solving scaling problems of the current classic CAs The academic federations are keen to support use of Grids 8 Apr 2009Identity Management - D Kelsey18

19. WLCG-IGTF requirements What do WLCG VOs and Sites require? My personal proposal – for discussion Face to face identity vetting (or trusted third party) –This is still important for Classic and MICS –We still need it (is this true?) User has potential access to very large resources –SLCS has already relaxed this But there are other controls in the primary IdM system 8 Apr 2009Identity Management - D Kelsey19

20. WLCG requirements (2) Persistence of subject DN –Essential that DN is not reissued to another person This is the anchor for VO membership –Medium-term persistence is therefore essential A few years –What about long-term? (e.g. re-use after 2 years of non-use of name) –my proposal is that we should still push for long- term persistence (lifetime of the CA service) (do you agree?) 8 Apr 2009Identity Management - D Kelsey20

21. WLCG requirements (3) Appropriate presentation of real name in DN –I asked GDB before about this (few years ago) Very strong feedback that this *is* needed Sites need real names in log files etc VOs need real name during user registration –This is of course what brings us all the data privacy problems with accounting data! And EGI may wish to follow the Academic federations direction and use an opaque ID (ePTID) Personally, I like the Australian shared token together with displayName “John Citizen ZsiAvfxa0BXULgcz7QXknbGtfxk)” –Do I have a mandate to push for this? –We could try to get this into SCHAC –And resist pressure to change the SLCS profile 8 Apr 2009Identity Management - D Kelsey21