1 / 11

IGTF: IOTA Authentication Profile WLCG GDB CERN, 11 December 2013

IGTF: IOTA Authentication Profile WLCG GDB CERN, 11 December 2013. David Kelsey STFC/RAL . Overview. I first mentioned this topic at the GDB in June 2013 The draft profile has matured since then Identifier-Only Trust Assurance with Secured Infrastructure Authentication Profile (IOTA)

minowa
Download Presentation

IGTF: IOTA Authentication Profile WLCG GDB CERN, 11 December 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IGTF: IOTA Authentication ProfileWLCG GDBCERN, 11 December 2013 David Kelsey STFC/RAL

  2. Overview • I first mentioned this topic at the GDB in June 2013 • The draft profile has matured since then • Identifier-Only Trust Assurance with Secured Infrastructure Authentication Profile (IOTA) • Lower assurance on ID vetting by CA • Appropriate in cases where VO does robust ID vetting, e.g. LHC VOs • Full details at • http://wiki.eugridpma.org/Main/IOTASecuredInfraAP • And uploaded to the GDB agenda page IOTA - D Kelsey

  3. IOTA profile (1) Input from CILogonBasic, and UK SARoNGS • Applicable when national identity federation does not perform F2F identity vetting (photo-ID) • And/or when IdPs refuse to release Common Names RP requirements from XSEDE and PRACE New IGTF authentication profile • Identifier-Only Trust Assurance • Persistent unique identifiers • Light-weight identity vetting IOTA - D Kelsey

  4. IOTA (2) Some words extracted from the profile Identity vetting is adequate to ensure unique, non-re-assigned identities Generated by authorities using secured and trusted infrastructure. Authorities are not required to collect more data than are necessary for fulfilling the uniqueness requirements May not provide sufficient information to independently trace individual subscribers Should be used in conjunction with complementary identification and vetting processes IOTA - D Kelsey

  5. 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 service • This subject name may be assigned to a person or automated actor(read “robot”) Naming • The name elements contained in the issued credential must be sufficient to uniquely identify an individual • If a commonName is included • it must contain either an opaque unique identifier • or a name chosen by the requestor and obtained from (a list proposed by) the IdP on which the issuer will enforce uniqueness IOTA - D Kelsey

  6. 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. IOTA - D Kelsey

  7. 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 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 • May 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) IOTA - D Kelsey

  8. Some operational issues For a VO using IOTA user credentials Identity Vetting is now an important requirement • To 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 traceability • Perhaps they will contact the end-user if contact is needed by a site • Security Incident response – more important role for VO IOTA - D Kelsey

  9. IOTA Deployment A possible deployment • Use national identity federation IdPs • Federations/IdPs registered with eduGAIN • IOTA CA also runs a trusted credential repository • Users authenticate against the IOTA CA • Certificates (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 IOTA - D Kelsey

  10. An IOTA Gotcha! Cannotmix 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) IOTA - D Kelsey

  11. Discussion? IOTA - D Kelsey

More Related