IOTA AP Towards Differentiated Identity Assurance

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