1. Towards an Initial LoA Baseline Assurance Profile?
Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases
David Groep
AARC NA3 Activity Lead
Nikhef, Physics Data Processing Group
EUGridPMA 36 Bratislava meeting
19 January 2016
Based on lots of work done by Mikael Linden, CSC!

2. Level of assurance Research community interviews done
Can we get consensus on an assurance ‘profile’ useful to RIs and e-Infrastructures and also feasible for more conventional R&E IdPs than currently profile higher LoA, or on a wider scale?
Specific initial target: ‘low risk’ research use cases, limit requirements on IdPs (this is not TCS!)
Interviews (1-1.5 hours) by Mikael Linden
Reference stakeholders EGI , PRACE, CLARIN, ELIXIR, Umbrella, DARIAH, WLCG
Interview results:
Complementary effort: IdP and Federation assurance capabilities
GN4-1 task by Daniela Pöhn – interviews of representative federations and IdPs

3. Early findings (for the milestone MNA3.1 in 11/2015)
MNA3.1: “Recommendation on minimal assurance level relevant for low-risk research use cases”
Accounts belong to a known individual (i.e. no shared accounts)
Persistent identifiers (i.e. are not re-assigned)
Documented identity vetting (not necessarily F2F)
Password authN (with some good practices)
Departing user’s account closes/ePA changes promptly
Self-assessment (supported with specific guidelines)
Questions to the floor:
Do we want to include incident response stuff (NA3.2) here?
Do we want to include attribute release requirements?
Do we want to include wider information security requirements?

4. Community Consultation
Initially aimed primarily at the R&E Federations and IdPs – we already got RI/e-Infra input
The consultation might not appear interesting to the IGTF
IGTF CAs by construction meet all requirements – logical since IGTF services e-Infras already
A review and self-audit scheme is already in place as well through the PMAs
But
It does give a hint as to why generic backed IGTF CAs are a bit hard (CILogon Silver, TCS)
The feed-back of self-assessment tools gives hints as to scalable policy work
Status
Closed last week
Generated a lot of comments, from a wide variety of viewpoints!

5. On ‘Low Risk’ and positioning of the baseline assurance profile
Define what “low-risk” means in such a way that it matches the assurance profile and in such a way that a service can determine with some degree of confidence if they are “low risk” or not. Suggest maybe OMB0404 impact classification, taking care not to over-value risks
Vagueness on ‘documented’ or ‘password’ but suggestions pushed in the direction of ISO29115 or LoA1 alignment, which was contrary to the idea of having a simple ‘meet-or-exceed’ model as an assurance profile
Suggested policy mapping exercise between baseline, ‘Kantara-levels’, and federation- proprietary assurance profiles The IGTF relying parties have an implicit understanding of policy mapping through the ‘minimal requirements’ background – this is however something we need to talk about!

6. Time periods
Prevailing time periods in the IGTF: 24 hrs, 11 days (1Ms), 1 year (400days) inspired by the common academic student affiliations, but that’s far from obvious!
Universities often know only that a student has left, when (s)he fails to show up for subsequent courses in the next year! So students and employees are different
So ‘prompt’ account updates (ePAffiliation, or account closure) are hard to do
And what does ‘departed’ mean? Is a collaboration with a (resident, employee) of the organisation still in place? Does the local sponsor actually close accounts? Is there a default maximum expiration? Compare it to e.g. the old ‘in academia’ discussion: what does ‘academic research’ mean?
Way out? “the IdP must now knowingly continue to assert” – like IGTF has in the IOTA profile?
And: whye.g. 30-day grace periods? The RIs requested that for account updates, IGFT has it for CRL freshness – what’s so magic about 30 days?

7. Individual accounts
IGTF turned a blind eye to what the end-user does to the private elements – unless we are informed about it
“A Home Organization can not prevent users from sharing their account credentials. It is known that many professors provide their credentials to their administrative staff...“
Accounts are not assigned to multiple users and the Home Organisation must be able to trace each account back to its holder.
instead of Accounts must not be shared and the Home Organisation must be able to trace each account back to its holder.
Traceability must always be defined in terms of some time period
Identity proofing should always be documented (“not necessarily F2F” is rather vague)

8. Passwords and other factors
For the ‘low risk’ use cases, the RIs/eInfras are usually OK with document password policies ‘if it’s good enough for valuable use cases in the home org, it is usually good enough for us’
That’s really hard to quantify! What about brute-force protection, for instance?
There are some NIST requirements, and DigiCert has some nice text for LoA2, but ‘good enough’ continues to be vague.
Identity proofing + passwords also sounds like NIST LoA2, but actually is not quite the same
External audit requirements, specific proofing requirements, …
Some R&E express concerns about ‘change cycle’ (although we still have to ask what was precisely intended here)
And of course there are now many places that do 2FA for everyone!

9. Where the IGTF does work 
The ‘persistent non-re-assigned identifier’ – needed by the research communities and infrastructures – was actually the cornerstone of the IGTF, so we do well there
This is far from common in the conventional R&E Federations
SAML NameID (eduPersonTargetedID) is useless since it is different for each SP
ePPN did not have a non-assignment requirement – so it ‘usually’ works (~75%), but not always
ePUniqueID is a ‘new’ (2013) attribute, so is hardly implemented
which is also why IOTA CAs backed by eduGAIN/InCommon must be able to add a unique ID

10. And naming is important
Assurance ‘levels’ reminds everyone of NIST, Kantara, &c
Whereas it might just be ‘surfaces’ along a number of different aspects (like the VoT work)
“Assurance Profiles” seems like the best regarded name … which happens to be what the IGTF called out “Authentication Profiles”. To begin with, at least the acronyms are the same…

11. An Automated Tool to support Self Assessments on LoA?
Self-assessment as a sufficient mechanism
Disclosing assessments
Incorporating assessments in RP authorization workflows
Re-use for IGTF self-audit and operational reviews?

12. Idea: How to assist IdPs to do the LoA self-assessment
We (who is we?) could develop and pilot a tool which
Is an eduGAIN SP to which any eduGAIN IdP admin can log in
Presents structured self-assessment questions to the IdP/IdM admin
Quantitive: (”do accounts belong to an individual”)
Qualitative: (”explain how you ensure accounts belong to an individual”)
Publishes the results for anyone to read
Evaluates if the LoA minimum is fulfilled
Spits an Entity Category tag to eduGAIN metadata for the IdP
Can we do that centrally?
Asks the IdP admin to re-evaluate every year
Can assist in the LoA peer-review
If peer review becomes a requirement e.g. for a higher LoA level

13. c.f. Surfnet’s IdM maturity scan for Dutch Home Organisations

14. Commentary
The idea that this tool would add an EC directly to the eduGAIN metadata (MDS) appears to be problematical. IMHO, a decentralized or mixed approach would be more convenient.
Technical Some federations still follow the opt-in approach for entities joining the eduGAIN upstream metadata - and therefore provide the downstream metadata as a separate stream - to be consumed only by the entities really needing it. In order to prevent any duplicates (and any strange side-effects), we (DFN-AAI) automatically remove all entities from the eduGAIN downstream metadata which are already registered with the DFN-AAI - as far as I know, the same holds true for SWITCHaai. As for German IdPs, this EC would never appear in our own federation - unless we reassign it, which would require additional technical efforts extending our metadata registry.
Trust According to the draft, "identification/authorisation of the IdP admins could be done by picking the contact information from the IdP metadata and sending a log-in link to that address". The problem here is that especially larger institutions don't use personal but role/list addresses (which is encouraged by the eduGAIN metadata profile, btw). Insofar, the level of assurance applied to the process of identification and authorization of an IdP/IdM admin is far weaker than the one required for the so- called "Minimal Assurance Profile" which this admin is meant to assert. In that case, some kind of re- confirmation by the federation operator would be necessary.
Easy LoA-EC mapping In cases where the requirements of some federation-internal LoA meet those of the Minimal Assurance Profile (SWAMID perhaps, DFN-AAI Advanced with some limitations), the EC could be easily assigned by the metadata registry and exported with the upstream metadata - without the overhead of using yet another online form/tool

15. Using the S/A tool output at the RP side
Use the tagging as a filter which limits – at the RP side – which IdPs to trust
Empowering the RP is also what the IGTF has done for the e-Infrastructures
with RPDNC tagging
with composable trust anchor distributions
with APs
We focussed on assurance level, not audits and assessments, but it is not so dissimilar

16. Dependencies in policy installation
‘lcg-CA’ or explicit configuration
For EGI-only sites: nothing changes!
For EGI sites also under wLCG policy and installed post-EGEE: just install both policy packages “egi-core” and “lcg”
ca-policy-egi-core
IGTF Classic
ca-AEGIS …
IGTF MICS
ca-TCS
IGTF SLCS
ca-DFN-AAI
ca-policy-lcg
IGTF Classic
ca-AEGIS …
IGTF MICS
ca-TCS
IGTF SLCS
ca-DFN-AAI
ca-CERN-LCG-IOTA
Evolving the EGI Trust Fabric - Bari 2015

17. Can the IGTF also benefit from an S/A tool?
Today
back-end might be usable for operational reviews and self-audit follow-up
Gives transparency to the self-audit process (esp. for TAG and AP)
Tomorrow?
Maybe some IGTF CAs want to join a (national) federation as an IdP-of-last-resort?
An federation-backed IOTA/SLCS CA can filter on the self-audit status
Extend to SirTFi compliance besides just the baseline assurance profile statements?

18. Thanks to all AARC folk whose slides and work I used in here – esp
Thanks to all AARC folk whose slides and work I used in here – esp. Mikael Linden and Daniela Pöhn