iota ap towards differentiated identity assurance
Skip this Video
Download Presentation
IOTA AP Towards Differentiated Identity Assurance

Loading in 2 Seconds...

play fullscreen
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 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
    • 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

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