1 / 15

IOTA AP Towards Differentiated Identity Assurance

IOTA AP Towards Differentiated Identity Assurance. David Groep, Nikhef supported by the Netherlands e-Infrastructure and SURFsara. Outline. Introduction and retro-active rationale Assurance levels IGTF ‘common criteria’ Current APs Towards collaborative differentiated LoA

gyula
Download Presentation

IOTA AP Towards Differentiated Identity Assurance

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. IOTA APTowards Differentiated Identity Assurance David Groep, Nikhefsupported by the Netherlands e-Infrastructure and SURFsara

  2. Towards differentiated collaborative LoA Outline • Introduction and retro-active rationale • Assurance levels • IGTF ‘common criteria’ • Current APs • Towards collaborative differentiated LoA • Distributing elements of trust decision • Use cases for the LiveAP • IOTA AP • Light-weight Identity Vetting Environment: towards LoA 1+ • Limitations of a ‘IOTA AP’ and new LoA levels

  3. Towards differentiated collaborative LoA Redistributing responsibilities • Subject (ID) based • EffectiveLoA is retained • For given actions, resources, and acceptable residual risk, required ID assurance is a given • can shift ‘line’ in identity trust level policy ecosystem commensurate to risk levelof the participants • Action (app) based • More constraint actions can lower need for identity LoA • (J)SPG VO Portal policy did just that: 4 levels of actions • Resource (value) based • e.g. access to wireless network does not pose huge risks, so can live with a lower identity LoA (eduroam)

  4. Towards differentiated collaborative LoA Trust Element Distribution (Classic, MICS) • Technical elements • integrity of the roots of trust • integrity of issuance process • process incident response • revocation capabilities • key management • credential management • incident response • Identity elements • identifier management • re-binding and revocation • binding to entities • traceability of entities • emergency communications • regular communications • ‘rich’ attribute assertions • correlating identifiers • access control IGTF Classic elements RP, Community elements Verifiability & Response, mitigation, recovery

  5. Towards differentiated collaborative LoA Collaborative assurance? I’m hopefully not misrepresenting Jules Wolfrat for PRACE here … • PRACE T1 (“DEISA”) centres • Users run applications across the infrastructure • All originate from a home site inside the infrastructure where they are fully known personally and have gone through a thorough vetting process • Home site distributes this knowledge actively towards the other centres (through a central LDAP) So some of the identity elements of trust already done • XSEDE might be similar? • even wLCG is somewhat similar … through CERN HR redistribution of responsibilities: a new profile?

  6. Light-weight ID vetting environment AP • Cater for those use cases where • the RPs (VOs) already collect identity data • this RP (VO) data is authoritative and provides traceability • the ‘identity’ component of the credential is not used • through an AP where the authority provides only • persistent, non-reused identifiers • traceability only at time of issuance • naming be real or pseudonymous (discussion on going!) • good security for issuance processes and systems • and where the RP will have to take care of • subscribers changing name often (in case traceability at issuing authority is lost) • all ‘named’ identity vetting, naming and contact details

  7. ‘Light-weight Identity Vetting Environment’ • as seen from the IdP/authority side • Must be complemented by the RP to profile full vetting and integrity …3,4 LoA 2: 1, 2-factor vetting, verified traceability, externally audited as matter of course 2 MICS, Classic: identified naming, traceability, longer-term, limited auditing VettingLoAscale SLCS: identified naming, point-in-time traceability, time-limited RP task Live AP: unique identification, no identity , limited traceability LoA 1: verified email address with mail-back 1 * somewhat my personal view … sorry for bias LoA 0: ‘like conventional unsigned email’

  8. From IGTF to RP • IGTF Distribution is not monolithic • Authorities comes in ‘bundles’ for each profile • RPs select one or more ‘profiles’ as sufficientand may add their own authorities as well • e.g: “EGI policy on trusted authorities” accepts Classic, MICS and SLCS And there is no ‘IGTF all’ distribution – on purpose! • With more diverse profiles (and LoAs) RPs will make more diverse choices For your interest: EGI SPG policy on Approval of Certification Authorities, https://documents.egi.eu/document/83

  9. LiveAP and its Caveats • Live AP assurance level is different, and rest must be taken up by somebody else • But e.g. in EGI • many communities rely on names to enrol people • communities do not keep much of auditable records • users are a-priori unknownto the resource owners • RPs support loosely organised communities • RPs thus need independent authoritative real names • Identity elements • identifier management • re-binding and revocation • binding to entities • traceability of entities • emergency communications • regular communications • ‘rich’ attribute assertions • correlating identifiers • access control

  10. Technical trust remains • loosing technical trust would make any authentication infrastructure useless • so integrity of the issuer has to be retained • just like for the AA Operations Guidelines • similar to the classic, mics and slcs profiles • both issuing system and ID management secure • retention of records for incident response When contracting back-end (university) IdPsthe requirements must apply to them as well

  11. The Profile Light-weight Identity Vetting Environment

  12. LIVE AP Identity • 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 • Naming • name elements […] sufficient to uniquely identify individual • sourced from ‘reasonable’ systems • real name or pseudonym with compensatory controls: • only in conjunction w/verified name element allowing contact to subject -- and the pseudonymity should be ‘obvious’ • Re-issuance, renewal and re-keying • authority should keep enough data to re-vet use of name • Tracability requirements • at issuance time the authority should identify user, and that relationship should be documented and verifiable DRAFT

  13. LIVE AP Technical • We expect a secure, on-line CA system • Long-term commitment, security controls and trained personnel • With FIPS140-2 level 3 or equivalent HDM controlling key • 2+ tier system on monitored controlled network • revocation capable • so at least better than ssh ;-) • Documented, transparent, policy and practices • Including provisions for auditing by peers • Some requirements propagate back to upstream IdPs! • Credentials in common recognisable formats • Initially X.509v3 certificates, but profile is mostly generic! DRAFT

  14. http://wiki.eugridpma.org/Main/LiveAPSecuredInfra DRAFTwill change

  15. New Authentication Profile • The AP currently being drafted on • https://wiki.eugridpma.org/Main/LiveAPSecuredInfra • Satisfy RP requirements (PRACE, XSEDE) – and aim to get SARoNGS and CI Logon Basic included • Many things to be decided! • Need for HSM FIPS 140-2 level 3 or 2? • What audit requirements needed? • Real or pseudonymous naming? Robots or not? • Distribution would be through separate ‘bundle’ • Next to ‘classic’, ‘mics’, ‘slcs’, and ‘experimental’ • Note there never was an ‘all’ bundle for this very reason • RPs will have to make an explicit choice to accept this

More Related