View
222
Download
0
Category
Preview:
Citation preview
www.egi.euEGI-InSPIRE RI-261323
EGI (IGTF Liaison Function)
www.egi.euEGI-InSPIRE RI-261323
Towards Differentiated Identity Assurance
as a collaborative effort
David Groep, Nikhef and NL-NGI for EGI global task O-E-15This work is supported by EGI-InSPIRE under NA2
davidg@nikhef.nl, orcid.org/0000-0003-1026-6606 http://dx.doi.org/10.6084/m9.figshare.678640
www.egi.euEGI-InSPIRE RI-261323
Outline
• Aims of a global trust fabric– Elements of trust: technical, vetting, auditing– Participants in the trust fabric
• Assurance levels– IGTF ‘common criteria’– Current APs
• Towards collaborative differentiated LoA– Distributing elements of trust decision– Light-weight Identity Vetting Environment: towards LoA 1+– Limitations of a ‘LIVE AP’ and new LoA levels
• Federated MICS and SLCS authorities today
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
Overlapping Communities – Common Trust
2013-04-11Towards differentiated collaborative
LoA
Goals•allow multiple sources of authority: User, Institute, Community•acknowledge both long- and short-term community structures•enable access to services and resources•and at the same time enable security incident response &cto
provide basis for access control decisions by resources providers (both generic and community based)
Reduce over-all policy burden by adhering to common criteria
www.egi.euEGI-InSPIRE RI-261323
Participants
2013-04-11Towards differentiated collaborative
LoA
Many participants contribute to access control with trustworthy identity and attributes
decision rests with the resource… service, site, &c …
www.egi.euEGI-InSPIRE RI-261323
Requirements to fulfil
2013-04-11Towards 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 amongservice providers could allow profiling•exchange of PII often fraught with issues
Measurement andAccounting
•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
www.egi.euEGI-InSPIRE RI-261323
Redistributing responsibilities
2013-04-11Towards 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)
www.egi.euEGI-InSPIRE RI-261323
Trust Element Distribution
2013-04-11Towards 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
IGT
F C
lass
ic
ele
me
nts
RP
, C
om
mu
nity
ele
me
nts
www.egi.euEGI-InSPIRE RI-261323
IGTF Assurance Process
2013-04-11Towards differentiated collaborative
LoA
Type and sensitivity of e-Infrastructure services drives the level of assurance required
•Security and assurance level set to be commensurate– not overly high for ‘commodity’ resources
– not too low, as resource owners/providers otherwise start implementing additional controls on top of and over the common criteria
– defined in collaboration with resource providers
– using transparency and a peer review processes
– leveraging our own community organisation mechanisms
www.egi.euEGI-InSPIRE RI-261323
Assurance levels
Trust in the assertions by resource and service providers is key
• Until now, our e-Infrastructure used a single ‘level’– there are also well-known ‘government’ standards for LoA
(US: OMB M-04-04 & NIST SP800-63, Kantara)
– but 95/46/EC and 1999/93/EC are not of much use to us and the Nice treaty states that identity is a national matter …
– there is rough but not 1:1 correspondence between balanced needs of the providers and users and the Kantara LoA levels
2013-04-11Towards differentiated collaborative
LoA
For your interest: Kantara Assurance Levelshttp://kantarainitiative.org/confluence/download/attachments/38371432/Kantara+IAF-1400-Service+Assessment+Criteria.pdf
www.egi.euEGI-InSPIRE RI-261323
IGTF Trust Structure
2013-04-11Towards differentiated collaborative
LoA
• Common criteria and model– globally unique and persistent identifier provisioning– not fully normative, but based on minimum requirements
• Trust is technology agnostic– technology and assurance ‘profiles’ in the same trust fabric– ‘classic’ traditional public key infrastructure with
near-realtime identity betting– ‘MICS’ dynamic ID provisioning leveraging federations– ‘SLCS’ on-demand short-lived token generation
a basis for ‘arbitrary token’ services– + experimental,
or even new profiles … if there is interest inside IGTF scope!
For your interest: IGTF Authentication Profiles http://www.eugridpma.org/guidelines/
www.egi.euEGI-InSPIRE RI-261323
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
2013-04-11Towards differentiated collaborative
LoA
For your interest: EGI SPG policy on Approval of Certification Authorities, https://documents.egi.eu/document/83
www.egi.euEGI-InSPIRE RI-261323
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 is likely be similar• even wLCG is somewhat similar … through CERN HR
2013-04-11Towards differentiated collaborative
LoA
I’m hopefully not misrepresenting Jules Wolfrat for PRACE here …
redistribution of responsibilities: a new profile
www.egi.euEGI-InSPIRE RI-261323
An IGTF Profile to match
‘Light-weight Identity Vetting Environment’
•as seen from the IdP/authority side•complemented by the RP to profile full vetting
2013-04-11Towards differentiated collaborative
LoA
VettingLoA
scale
LoA 0: ‘like conventional unsigned email’
* somewhat my personal view … sorry for bias
1
2
…3,4
www.egi.euEGI-InSPIRE RI-261323
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
2013-04-11Towards differentiated collaborative
LoA
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
www.egi.euEGI-InSPIRE RI-261323
EGI (IGTF Liaison Function)
www.egi.euEGI-InSPIRE RI-261323
Light-weight Identity Vetting Environment
The Profile
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
Disclaimer
• LIVE AP is not ready, and IGTF will make significant changes
• Needs global consensus
• Target date: ~ Q1 2014• Input, specifically from RPs, very welcome!
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
DRAFTLIVE 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
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
DRAFTLIVE 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!
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
What Happens Next
• together with the cross-national RPs and national members (proxying national RPs) ‘LIVE AP’ will be developed to full AP guideline– this will introduce a truly new LoA for the first time– LoA higher than Kantara LoA 1, but much lower than 2
(and also lower than classic and MICS, and even <SLCS)– contributions welcome through your RP or national authority
membr
• once reasonable consensus is achieved …– RPs may decide to accept authorities under this profile for (some)
of their services. Or not.– don‘t automatically expect all RPs to treat it as equivalent to MICS
… unless the RP does its own vetting already
2013-04-11Towards differentiated collaborative
LoA
www.egi.euEGI-InSPIRE RI-261323
Today’s Federated e-Science ID Promo…
Towards differentiated collaborative LoA
Map colour codingGreen: classic accredited authorityBlue: federated (+classic) authority Yellow: pending classic accreditation
Also in USA: CILogon based on InCommonin Japan: new SLCS by NII
Federated ‘translating’ authorities: integrity requirements propagate to all data sourcese.g. TERENA Certificate Service eScience MICS, the DFN-AAI SLCS, SWITCHaai SLCS
2013-04-11
Recommended