IOTA AP Towards Differentiated Identity Assurance David Groep, Nikhef supported by the Netherlands...
-
Upload
aileen-norman -
Category
Documents
-
view
215 -
download
0
Transcript of IOTA AP Towards Differentiated Identity Assurance David Groep, Nikhef supported by the Netherlands...
IOTA APTowards Differentiated
Identity Assurance
David Groep, Nikhefsupported by the Netherlands e-Infrastructure and SURFsara
EUGridPMA Kyiv 2013 meeting – 2David Groep – [email protected]
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
2013-04-11Towards differentiated collaborative LoA
EUGridPMA Kyiv 2013 meeting – 3David Groep – [email protected]
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)
policy ecosystem commensurate to risk level
of the participants
EUGridPMA Kyiv 2013 meeting – 4David Groep – [email protected]
Trust Element Distribution (Classic, MICS)
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
EUGridPMA Kyiv 2013 meeting – 5David Groep – [email protected]
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-11Towards differentiated collaborative LoA
I’m hopefully not misrepresenting Jules Wolfrat for PRACE here …
redistribution of responsibilities: a new profile?
EUGridPMA Kyiv 2013 meeting – 6David Groep – [email protected]
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
EUGridPMA Kyiv 2013 meeting – 7David Groep – [email protected]
‘Light-weight Identity Vetting Environment’
as seen from the IdP/authority side Must be complemented by the RP
to profile full vetting and integrity
VettingLoA
scale
LoA 0: ‘like conventional unsigned email’
* somewhat my personal view … sorry for bias
1
2
…3,4
RP task
EUGridPMA Kyiv 2013 meeting – 8David Groep – [email protected]
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 SLCSAnd 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
EUGridPMA Kyiv 2013 meeting – 9David Groep – [email protected]
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
EUGridPMA Kyiv 2013 meeting – 10David Groep – [email protected]
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
EUGridPMA Kyiv 2013 meeting – 11David Groep – [email protected]
LIGHT-WEIGHT IDENTITY VETTING ENVIRONMENT
The Profile
EUGridPMA Kyiv 2013 meeting – 12David Groep – [email protected]
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
EUGridPMA Kyiv 2013 meeting – 13David Groep – [email protected]
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!
EUGridPMA Kyiv 2013 meeting – 14David Groep – [email protected]
http://wiki.eugridpma.org/Main/LiveAPSecuredInfra
DRAFT
will change
EUGridPMA Kyiv 2013 meeting – 15David Groep – [email protected]
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