Iota ap towards differentiated identity assurance
1 / 15

IOTA AP Towards Differentiated Identity Assurance - PowerPoint PPT Presentation

  • Uploaded on

IOTA AP Towards Differentiated Identity Assurance. David Groep, Nikhef supported by the Netherlands e-Infrastructure and SURFsara. Outline. Introduction and retro-active rationale Assurance levels IGTF ‘common criteria’ Current APs Towards collaborative differentiated LoA

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' IOTA AP Towards Differentiated Identity Assurance' - gyula

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Iota ap towards differentiated identity assurance

IOTA APTowards Differentiated Identity Assurance

David Groep, Nikhefsupported by the Netherlands e-Infrastructure and SURFsara


Towards differentiated collaborative LoA


  • 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


    • Light-weight Identity Vetting Environment: towards LoA 1+

    • Limitations of a ‘IOTA AP’ and new LoA levels

Redistributing responsibilities

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)

Trust element distribution classic mics

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

Collaborative assurance

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?

Light weight id vetting environment ap
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

Light weight identity vetting environment
‘Light-weight Identity Vetting Environment’

  • as seen from the IdP/authority side

  • Must be complemented by the RP to profile full vetting and integrity


LoA 2: 1, 2-factor vetting, verified traceability, externally audited as matter of course


MICS, Classic: identified naming, traceability, longer-term, limited auditing


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


* somewhat my personal view … sorry for bias

LoA 0: ‘like conventional unsigned email’

From igtf to rp
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,

Liveap and its caveats
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

Technical trust remains
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

Light weight identity vetting environment1

The Profile

Light-weight Identity Vetting Environment

Live ap identity
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


Live ap technical
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!


New authentication profile
New Authentication Profile

  • The AP currently being drafted on


    • 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