David Groep EUGridPMA 36 Bratislava meeting
Description: David Groep EUGridPMA 36 Bratislava meeting Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases Towards an Initial LoA Baseline Assurance Profile? 19 January 2016 AARC NA3 Activity Lead Nikhef, Physics Data
Related Topics
Download Presentation
"David Groep EUGridPMA 36 Bratislava meeting" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. David Groep EUGridPMA 36 Bratislava meeting Recommendations on Minimal Assurance Level Relevant for Low-risk Research Use Cases Towards an Initial LoA Baseline Assurance Profile? 19 January 2016 AARC NA3 Activity Lead Nikhef, Physics Data Processing Group Based on lots of work done by Mikael Linden, CSC!<br>
slide2. 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: https://wiki.geant.org/x/nQHbAg
Complementary effort: IdP and Federation assurance capabilities
GN4-1 task by Daniela Pöhn – interviews of representative federations and IdPs
https://wiki.geant.org/display/gn41sa5/1.4+Service+Aspects+of+Assurance 2 Level of assurance Research community interviews done<br>
slide3. 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? 3 Early findings (for the milestone MNA3.1 in 11/2015)<br>
slide4. 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>
slide5. 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! 5 On ‘Low Risk’ and positioning of the baseline assurance profile<br>
slide6. 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>
slide7. 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>
slide8. 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>
slide9. 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>
slide10. 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>
slide11. 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>
slide12. 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>
slide13. 13 c.f. Surfnet’s IdM maturity scan for Dutch Home Organisations<br>
slide14. 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>
slide15. 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>
slide16. 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>
slide17. 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>
slide18. davidg@nikhef.nl Thanks to all AARC folk whose slides and work I used in here – esp. Mikael Linden and Daniela Pöhn<br>
slide2. 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: https://wiki.geant.org/x/nQHbAg
Complementary effort: IdP and Federation assurance capabilities
GN4-1 task by Daniela Pöhn – interviews of representative federations and IdPs
https://wiki.geant.org/display/gn41sa5/1.4+Service+Aspects+of+Assurance 2 Level of assurance Research community interviews done<br>
slide3. 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? 3 Early findings (for the milestone MNA3.1 in 11/2015)<br>
slide4. 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>
slide5. 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! 5 On ‘Low Risk’ and positioning of the baseline assurance profile<br>
slide6. 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>
slide7. 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>
slide8. 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>
slide9. 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>
slide10. 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>
slide11. 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>
slide12. 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>
slide13. 13 c.f. Surfnet’s IdM maturity scan for Dutch Home Organisations<br>
slide14. 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>
slide15. 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>
slide16. 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>
slide17. 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>
slide18. davidg@nikhef.nl Thanks to all AARC folk whose slides and work I used in here – esp. Mikael Linden and Daniela Pöhn<br>