1. LiveAP Towards Differentiated Identity Assurance David Groep, Nikhef supported by the Netherlands e-Infrastructure SURFsara, and EGI.eu O-E-15 and EGI-InSPIRE NA2.3

2. APGridPMA Taipei 2013 meeting – 2 David Groep – davidg@eugridpma.org 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  LiveAP  Light-weight Identity Vetting Environment: towards LoA 1+  Limitations of a ‘LIVE AP’ and new LoA levels 2013-04-11 Towards differentiated collaborative LoA

3. APGridPMA Taipei 2013 meeting – 3 David Groep – davidg@eugridpma.org Requirements to fulfil – mainly for RPs! 2013-04-11 Towards differentiated collaborative LoA Incident Response long-term* traceable independent from short-lived community must be revocable correlate with other information sources banning and containment handle Privacy and data protection important ‘unalienable right’ for research correlation of PII among service providers could allow profiling exchange of PII often fraught with issues Measurement and Accounting publication metrics usage metering, billing auditing and compliance monitoring identity lives in a policy ecosystem to protect all participants commensurate to their risk level Access Control Attribute handle unique binding never re-assigned Regulatory compliance need to know who you let in beforehand

4. APGridPMA Taipei 2013 meeting – 4 David Groep – davidg@eugridpma.org Redistributing responsibilities 2013-04-11 Towards differentiated collaborative LoA Subject (ID) based Effective LoA is retained For given actions, resources, and acceptable residual risk, required ID assurance is a given can shift ‘line’ in identity trust level 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)

5. APGridPMA Taipei 2013 meeting – 5 David Groep – davidg@eugridpma.org Trust Element Distribution (Classic, MICS) 2013-04-11 Towards differentiated collaborative LoA 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 Verifiability & Response, mitigation, recovery IGTF Classic elements RP, Community elements

6. APGridPMA Taipei 2013 meeting – 6 David Groep – davidg@eugridpma.org Collaborative assurance?  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 2013-04-11 Towards differentiated collaborative LoA I’m hopefully not misrepresenting Jules Wolfrat for PRACE here … redistribution of responsibilities: a new profile?

7. APGridPMA Taipei 2013 meeting – 7 David Groep – davidg@eugridpma.org 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

8. APGridPMA Taipei 2013 meeting – 8 David Groep – davidg@eugridpma.org ‘Light-weight Identity Vetting Environment’  as seen from the IdP/authority side  Must be complemented by the RP to profile full vetting and integrity Vetting LoA scale LoA 0: ‘like conventional unsigned email’ * somewhat my personal view … sorry for bias 1 2 …3,4 RP task

9. APGridPMA Taipei 2013 meeting – 9 David Groep – davidg@eugridpma.org From IGTF to RP  IGTF Distribution is not monolithic  Authorities comes in ‘bundles’ for each profile  RPs select one or more ‘profiles’ as sufficient and 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

10. APGridPMA Taipei 2013 meeting – 10 David Groep – davidg@eugridpma.org 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 unknown to 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

11. APGridPMA Taipei 2013 meeting – 11 David Groep – davidg@eugridpma.org 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) IdPs the requirements must apply to them as well

12. APGridPMA Taipei 2013 meeting – 12 David Groep – davidg@eugridpma.org LIGHT-WEIGHT IDENTITY VETTING ENVIRONMENT The Profile

13. APGridPMA Taipei 2013 meeting – 13 David Groep – davidg@eugridpma.org DRAFT 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

14. APGridPMA Taipei 2013 meeting – 14 David Groep – davidg@eugridpma.org DRAFT 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!

15. APGridPMA Taipei 2013 meeting – 15 David Groep – davidg@eugridpma.org http://wiki.eugridpma.org/Main/LiveAPSecuredInfra DRAFT will change

16. APGridPMA Taipei 2013 meeting – 16 David Groep – davidg@eugridpma.org 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