David Groep EUGridPMA 36 Bratislava meeting

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! 4 Community Consultation<br>

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 profilesThe IGTF relying parties have an implicit understanding of policy mapping through the ‘minimal requirements’ background – this is however something we need to talk about! 5 On ‘Low Risk’ and positioning of the baseline assurance profile<br>

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? 6 Time periods<br>

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) 7 Individual accounts<br>

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! 8 Passwords and other factors<br>

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 9 Where the IGTF does work <br>

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… 10 And naming is important<br>

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?<br>

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 12 Idea: How to assist IdPs to do the LoA self-assessment<br>

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

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 email address". The problem here is that especially larger institutions don't use personal but role/list email 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 14 Commentary<br>

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 15 Using the S/A tool output at the RP side<br>

Dependencies in policy installation Evolving the EGI Trust Fabric - Bari 2015 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”<br>

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? 17 Can the IGTF also benefit from an S/A tool?<br>

davidg@nikhef.nl Thanks to all AARC folk whose slides and work I used in here – esp. Mikael Linden and Daniela Pöhn<br>