WLCG GDB CERN 11 December 2013 David Kelsey STFCRAL Overview I first mentioned this topic at the GDB in June 2013 The draft profile has matured since then IdentifierOnly Trust Assurance with Secured Infrastructure Authentication Profile IOTA ID: 322690
Download Presentation The PPT/PDF document "IGTF: IOTA Authentication Profile" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
IGTF: IOTA Authentication ProfileWLCG GDBCERN, 11 December 2013
David KelseySTFC/RAL Slide2
OverviewI first mentioned this topic at the GDB in June 2013
The draft profile has matured since thenIdentifier-Only Trust Assurance with Secured Infrastructure Authentication Profile (IOTA)Lower assurance on ID vetting by CAAppropriate
in cases where VO does robust ID vetting, e.g. LHC VOsFull details athttp://wiki.eugridpma.org/Main/IOTASecuredInfraAP
And uploaded to the GDB agenda page
11 Dec 2013
2
IOTA - D KelseySlide3
IOTA profile (1)Input from
CILogon Basic, and UK SARoNGSApplicable when national identity federation does not perform F2F identity vetting (photo-ID)
And/or when IdPs refuse to release Common NamesRP requirements from XSEDE and PRACE
New
IGTF authentication
profileIdentifier-Only Trust Assurance
Persistent unique identifiersLight-weight identity vetting
11 Dec 2013
IOTA - D Kelsey
3Slide4
IOTA (2)Some
words extracted from the profileIdentity vetting is adequate to ensure unique, non-re-assigned
identitiesGenerated by authorities using secured and trusted infrastructure. Authorities
are not required to collect more data than are necessary for fulfilling the uniqueness
requirements
M
ay not provide sufficient information to independently trace individual subscribers S
hould be used in conjunction with complementary identification and vetting processes
11 Dec 2013
IOTA - D Kelsey
4Slide5
IOTA (3)Persistency of name binding
Any single subject name in a credential must be linked with one and only one entity for the whole lifetime of the serviceThis subject name may be assigned to a person or automated
actor (read “robot”)NamingThe name elements contained in the issued credential must be sufficient to uniquely identify an individual
If
a
commonName
is includedit
must contain either an opaque unique identifieror a name chosen by the requestor and obtained from (a list proposed by) the IdP on which the issuer will enforce uniqueness
11 Dec 2013
IOTA - D Kelsey
5Slide6
IOTA (4)Naming – continued
The set of subject name elements included must: identify the identity management system via which the identity of this person was vetted, unless the vetting is done directly and solely by the issuing authority;
contain sufficient information such that an enquiry via the issuer to the identity management system or issuing authority providing only this data allows unique identification of the vetted entity in this identity management system; No anonymous credentials may be issued under this profile.
11 Dec 2013
IOTA - D Kelsey
6Slide7
IOTA (5)Renewal or re-keying of a credential with a given subject name may only and exclusively proceed if there is conclusive evidence that the entity requesting this renewal or re-keying is the same entity as the one to whom the original credential was issued
Traceability RequirementsAt credential issuing time, the authority must reasonably demonstrate how it can verify identity information
And trace this information back to a physical person
M
ay
rely in good faith on any identity management system by a third party with which it has entered into an agreement
Ability to demonstrate persistent long-term authentication is required if the authority supports renewal or re- keying
Many other details not shown here (see full document)
11 Dec 2013
IOTA - D Kelsey
7Slide8
Some operational issuesFor a VO using IOTA user credentials
Identity Vetting is now an important requirementTo be done by the VO (CERN HR for LHC)Are sites willing to lose Common Names in certificate DNs?
The name should be available from the VO (or in a VOMS attribute certificate)The VO needs to provide traceabilityPerhaps they will contact the end-user if contact is needed by a site
Security Incident response – more important role for VO
11 Dec 2013
IOTA - D Kelsey
8Slide9
IOTA DeploymentA possible deployment
Use national identity federation IdPsFederations/IdPs registered with
eduGAINIOTA CA also runs a trusted credential repositoryUsers authenticate against the IOTA CACertificates (long–term or short-term) are issued
Stored in repository for later use
VO uses robust identity-vetting as part of user registration with VOMS
VOMS could add Name attributes if
needed and they are not
available from the IOTA certificate
11 Dec 2013
IOTA - D Kelsey
9Slide10
An IOTA Gotcha!Cannot
mix VOs requiring different levels of assurance on one relying party end-system.If a site decides to trust IOTA CAs, then it will trust them for ALL Vos
Will cause problems where a site supports LHC VOs and also supports other (non-LHC) Vos (who are not setup to use IOTA)
11 Dec 2013
IOTA - D Kelsey
10Slide11
Discussion?
11 Dec 2013
IOTA - D Kelsey
11