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

Identity ManagementLevels of Assurance

WLCG GDBCERN, 8 Apr 2009

David KelseySTFC/RAL

david.kelsey AT stfc.ac.uk

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 matters8 Apr 2009 2Identity Management - D Kelsey

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 2009 Identity Management - D Kelsey 3

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


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)


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.


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


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


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


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


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…


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.


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)


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


Where are you from? Remote authentication


IdP SP

Example from Switch AAI

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)”


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?


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


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


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?)


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


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

Documents

Transcript of Identity Management Levels of Assurance WLCG GDB CERN, 8 Apr 2009 David Kelsey STFC/RAL david.kelsey...