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 – 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

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 – davidg@eugridpma.org

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 – davidg@eugridpma.org

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 – 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-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 – 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

EUGridPMA Kyiv 2013 meeting – 7David 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

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 – 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 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 – 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

EUGridPMA Kyiv 2013 meeting – 10David 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) IdPsthe requirements must apply to them as well

EUGridPMA Kyiv 2013 meeting – 11David Groep – davidg@eugridpma.org

LIGHT-WEIGHT IDENTITY VETTING ENVIRONMENT

The Profile

EUGridPMA Kyiv 2013 meeting – 12David Groep – davidg@eugridpma.org

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 – davidg@eugridpma.org

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 – davidg@eugridpma.org

http://wiki.eugridpma.org/Main/LiveAPSecuredInfra

DRAFT

will change

EUGridPMA Kyiv 2013 meeting – 15David 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