Dear EUGridPMA and IGTF members, dear AARC policy people, The 45th EUGridPMA meeting is now over, and I would like to take this opportunity to thank again Hannah Short and Paolo Tedesco from CERN for arranging the meeting and the excellent support, continued use of Vidyo, and the excellent trust-building opportunities (at CERN and in the lake). I would like to share with you a few of the highlights of the meeting. Send corrections and omissions if you spot them, since these have been taken from my own scribbles and memory at https://eugridpma.org/meetings/2019-01/eugridpma45-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at http://www.eugridpma.org/agenda/45 And these notes you can re-read at https://eugridpma.org/meetings/2019-01/summary-eugridpma-2019-01-geneva.txt Specific thanks goes also to the AARC project and participants, who have contributed their effort and ideas and attendance, and to GN4's EnCo activity. As usual the joint session for Policy Harmonisation formed a great contribution to the IGTF schedule. Subsequent meetings will be: ** 46th EUGridPMA meeting, May 2019 We are currently arranging the location, which will be either in Finland or the Netherlands, and the most likely dates 20-22 May, starting at ~13.00 and finishing Wednesday at ~12.00 at the This meeting again will be in collaboration with the policy harmonisation groups of our major relying parties, supported by GN4 EnCo and EOSC-HUB. and of course our affiliated meetings: * APGridPMA, IGTF All Hands & ISGC 2019, Taipei 31 March - 5 April 2019 * TNC19 and REFEDS, Tallinn, Estonia 16 June - 20 june 2019 See all of you in May, or at any of the upcoming meeting of the IGTF or elsewhere! Best regards, DavidG. Subject discussed and listed below ---------------------------------- * Requirements on a TCS service for r/e-infrastructure use cases * Policy and best practice harmonisation harmonised in and after 2019 * GSI and Grid Community toolkit * SCI and the assessment of Security for Collaboration among Infrastructures * Comparing SCI and formal standards * Guidelines for Secure Operation of Attribute Authorities and other issuers of Authorisation Assertions * Assurance Profiles - a suite of options * On an IdP-SP-proxy and Sirtfi-ing un-Sirtfied IdPs * PMA operational matters, reviews, suspensions and review * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/45 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. Requirements on a TCS service for r/e-infrastructure use cases -------------------------------------------------------------- The proapration for a 4th generation TCS service gives the Infrastructures and RPs the opportunity to review the requirements that are specific to the research use cases. So while the generic requirements will obviously be hanled through the TCS channels, specific new 'eScience' and 'client- authentication' needs can now be considered again for inclusion (either as hard or soft requirements). The existing elements (unique subject namespace for RPDNC is critical, and specifically "/dc=org/dc=terena/dc=tcs/", and consistency of the subjectDN naming for current subscribers would be extremely beneficial). The 'lessons learnt' presentation by Jan Chvojka in the Manchester meeting [https://indico.nikhef.nl/event/912/contribution/20/material/slides/0.pdf] also provides important input. As to new requirements, once you start considering sensor networks and low-power distributed infrastructures (we see those e.g. in seismic networks) - for trust infrastructures in that energy-constraint domain including LoRa and solar-powered devices, the use of ECC is important, and the entire chain needs to be ECC (otherwise you still waste energy and need two crypto stacks). The curves available should actually match the libraries in the end-devices as well, so looking at 25519 is fine, but if the libraries only consider de Suite-B curves it's no use. At least ECC is for now Quantum-resistant. Another important elements, keeping in mind the increasing 'DevOps' style deployment models for infrastructure, is the ability to automatically provision CAs. All of the major ones have an API, but something fully automatable (akin to "certbot" for ACME today) would be good to have. However, verification to OV standards has to be in, so the ACME protocol should be evolved to include that. The spec currently pays lip-service to validation of other elements, but a concrete implementation is lacking. A provider that helps push a standard in this space would be helpful. And an OAuth check during the ACME flow is in principle quite feasible (as long as issuance is fast enough, <30s). To generalise the usefulnes of authentication client certificates ("grid" today) to more domains, it would be useful to have a profile where unique identifiers are part of the name but not embedded in the CN field. We recognise that unstructuredName does not meet the e-Infra requirements, but it would work for e.g. (Open)VPN client auth. A few more profiles (and not labelling them "grid") will be useful. Somewhat unrelated: the number of profiles probably has to increase, since clients like Outlook 2019 apparently need _separate_ certificates for signing and encryption, and having both purposes combined is not allowed. No other software but Outlook is known to do this for now, but that might change. Policy and best practice harmonisation harmonised in and after 2019 ------------------------------------------------------------------- The cross-infrastructure policy and best practice harmonisation that has been sponsored by the AARC/2 projects is highly values, and several infrastructures, organisations, and projects have committed to supporting such cross-domain and cross-infrastructure activities in the future: EOSC-HUB, the GEANT4 (phase 3) project, as well as many national and domain infrastructures. Maarten Kremers presented the overview of the GEANT4-3 project [linked from the agenda page under "GEANT The Project: enabling communities"] and emphasises that the Enabling Communities ("EnCo") task is very open to collaboration and joint workings, and is there to be a support for its people in executing work in the various long-term standing bodies: WISE, IGTF, REFEDS, FIM4R, as well as work supporting AEGIS and any activities in the "T&I" (Trust and Identity) context of the GN4-EOSCHUB collaboration agreement). Instead of having dedicated meetings of GN*-*WP*.*.*, doing this work in conjunction with other meetings (such as now with the EUGridPMA) is highly encouraged by Maarten. There are not that many policy and community experts to go around anyway. DavidG also presented a proposed 'homing' of existing AARC NA3 activities and the work it has supported over the past four years. Linked from the same agenda item it proposes a natural home for anything from Sirtfi, security communications, SCI assessment, assurance, AUP, data protection, risk assessment, and the policy development kit. The work on data protection for research communities has obvious overlaps with generic data protection (like in TF-DPR), but the research community also has specific questions that are either out of scope or too specific, and many communities appreciate the specific 'consultation' that the AARC activity and Uros have given them (like the guidance for the LSAAI on DPCoCo and R&S). GN4 tasks on data protection are not necessarily of much help, since they primarily have to address the internal GDPR compliance needs, although synergies with the GN4 activity in this area by Alf Moens ("WP8") should be explored. For now, it is recommended that research infrastructures and communities keep contacting Uros, through a list that may be a successor to the AARC-NA3 list, and may be 'just' the EnCo list. FIM4R should remain very much driven by the _Research_ communities and not be subsumed by generic e-Infrastructures in their role as providers of services. Of course, their participation in the working of FIM4R, as we have seen with EOSC-HUB and GN4-2, is very fruitful. Also the standing research infrastructures have contributed significantly. New FIM4R whitepapers should probably not be too frequent, since rapid updating could diminished their (polical and governance) impact. The Policy Development Kit evolution fits naturally in the WISE SCI WG. But where do communities turn for help in 'designing their AAI' (even more than just policy)? This needs more than a simple flow-chart and often needs to include 1-on-1 consultancy to be effective. Both the EOSC-HUB and GN4-3 projects have effort available to 'support communities', and there is so much work that none of them could 'do it all', having both practical and neutral consultancy will be a challenge. But if there is no guidance, communities go off on their own and may end up with a sub-optimal product (e.g. mistaking enterprise solutions for a federated proxy implementation and stumbling upon "keycloak" or so). This might actually be a good role for FIM4R (or WISE), or the RDA-FIM4R interest group. That would avoid the (unintentional but hard to avoid) bias for a particular solution. It does however require a more hands-on approach for FIM4R... but one that gets new communities involved in the FIm4R process! Lastly, there was a concern that the overall vision and coherency of policy harmonisation activities could be lost. However, if we all ensure that activities are open, everyone is welcome in also the EnCo activities, and we keep the personal overlap in membership that currently exists, the risk of diversion is minimized. GSI and Grid Community toolkit ------------------------------ We point users of RFC3820 and GSI delegation to the Grid Community Toolkit [GCT] effort, which has taken on long-term support and maintenance of the GSI libraries formerly developed by Globus. The Grid Community Forum [https://gridcf.org/] has an active set of developers and participating organisations, and is responsible for the libraries and services for core grid software in EPEL, Fedora, and Debian distributions as well. Developed on GitHub as fully open source, it ensures longevity of the GSI authentication and delegation infrastructure. It also means that there is no need to stop using such protocols and services. SCI and the assessment of Security for Collaboration among Infrastructures -------------------------------------------------------------------------- The "version 2" SCI policy collaboration document brings the need to also review the assessment matrix and the elements that need to be (self) assessed and (peer) reviewed. The endorsement by many prominent (global, national, and domain-specific) infrastructures has resulted in increased attention for SCI and it becoming a reference point for agreeing on information security capabilities. The assessment spreadsheet was reviewed based on Uros' renewed mapping, and that will in turn inspire more use of the peer-reviewed self-assessment model - contrasted with the 'public standards' based approach that pushes ISO 27k and paid auditors. It also more accurately reflects the federated and autonomous nature of the infrastructures of most of our relying parties. The matrix is available as "_V2" at https://indico.cern.ch/event/760953/contributions/3266272/attachments/1782537/2901309/SCIv2-Assessment-Chart_V2-US.xlsx The weighting of the subscores in the matrix should be considered: this is not a simple average, and in addition there should be an expert assessment on the over-all score at the bottom. Also that score is not an average or median, since some elements - in the rightful view of the peer assessor - may be more important than others. A model based on the IGTF GFD.169 "BCD" scoring system (minor, major, critical) is a better fit here. The SCI model will also be pushed for the EOSC-HUB "ITSM" assessment, where a ISO27k would be inappropriate. All EOSC-HUB partners have endorsed SCIv2, and - more than the FITSM ISM criteria - SCI is much more suited for couples federations since it does not assume central control (which even FITSM still does to a remarkable extent, unfortunately). Based on SCI, also the Policy Development Kit (by AARC) can be extended to address more elements than 'just' Snctfi. Comparing SCI and formal standards ---------------------------------- Experience in the IGTF and elsewhere has shown that peer-reviewed self- assesment are a feasible means of creating trust between federated and independently administred domains in (at least) the R&E community. The comparison between ISO27k and SCIv1 has already been partially done (by WISE SCI in 2016) and the results are on the WISE SCI wiki page [https://wiki.geant.org/display/WISE/SCIV2-WG+documents]. Just like 'federation' was not part of any ITSM standards (prompting FITSM), also SCI works a lot better for (loosely coupled) federations and working between peer infrastructures, where 27k is single-org focussed. The WISE document points at what is not in SCI (but is in 27k), but those elements are indicative of single-org control or are outside the scope of security proper (like IPR). There are however the even more important aspects of _methodology_ to be considered, and DaveK + Uros will be working on a (set of two) documents describing that difference. The assessment will be an AARC/WISE document (and can be published as an AARC Information document AARC-I***) - which can be used to inform also some of the EOSC-HUB ITSM responsibles. Guidelines for Secure Operation of Attribute Authorities and other issuers of Authorisation Assertions ------------------------------------------------------------ The "Guidelines for Secure Operation of Attribute Authorities and other issuers of Authorisation Assertions" (AARC-G048) was reviewed https://docs.google.com/document/d/1k1Xdk456cq6ILiodqkmRJRevBWzfWjwau9tkuRjIAWQ and the language improved. It applies to both AA's (and their operators) as well as to operators of "BPA" proxies. The clarifications are almost complete and will be re-issued shortly as an AARC G048 guideline at: https://aarc-project.eu/guidelines/aarc-g048/ Assurance Profiles - a suite of options --------------------------------------- Between the main bodies that discuss and promulgate assurance profile specifications (IGTF, REFEDS, Kantara, eIDAS, NIST) there are already over 13 distinct profiles that are potentially useful - between all the use cases combined. They include ASPEN, BIRCH, CEDAR, and DOgWOOD from the IGTF, Cappuccino and Espresso from REFEDS RAF (+SFA and MFA), the levels 1,2,3,4 from Kantara and NIST, and the "low", "substantial" and "high" from eIDAS. Of all of these, most are assurance frameworks (meaning you can base your own credential assurance on them), whereas eIDAS at least conceptually also has implementations in some countries. Each of these profiles is distinct, and has (for historical or current reasons) differences with respecto tthe others. However, the over-all result is a 'soup' of assurance profiles in which even experts have difficulties finding their way - despite them being almost full-time assurance experts such as Robin Wilton from Kantara. So the request to AARC NA3 to provide clarification in this space is not unexpected. As inputs, there is now a 'flow-based' review of many of the profiles, as can be seen in AFOverview6 [on the agenda page] that shows in which areas (vetting, authenticator, audit, naming, security) each of the profiles differs from another. The Kantara profiles will be added shortly (before the TIIME meeting). There are both overlaps and differences, but these result from the different use cases and the risk assessment that are driven by the relying parties (in case of the IGTF profiles), or the feasibility of actually providing the assurance level (mostly the case for the REFEDS profiles). There are cross-correlations: e.g. for REFEDS Cappuccino identity vetting according to BIRCH is explicitly listed as sufficient. And for the BIRCH and CEDAR profiles, Kantara LoA 2 identity vetting is sufficient (even if it is 'over the top' and exceeds the basic requirements for these). Mapping and convolution is inherently complex in a 13-dimensional space, and a common vocablary could help, but in itself may also complicate matters (adding the '14-th dimension'). A 'common language' for all would be interesting and useful, but will take too long to complete under AARC2. FOr a proper overview and comparison, we should demonstrate that each profile has a unique niche (and there is obviously no duplication), and that they reflect the specific needs of either identity providers or relying parties. Having a group of relying parties with common risk factors and assurance needs, makes a specific profile useful. The conclusion of the Assurance Profile review paper (an AARC Informational document) could include: - for the 13 profiles: list the specific use cases for each of these (and why these use cases justify a profile for REFEDS RAF, IGTF, and G021/Assam) - the IGTF profiles linked to research infrastructure risk profile, the RAF to feasibility (can enough IdPs do it, somewhat regardless of the need of the R/E-Infra’s that rely on the IGTF profiles) - RAF: feasible for the IdPs, split with authenticationContextClassReference because of limitations in single-valued SAML (so any linkage with SFA/MFA has to be done by policy and discussion) - peer reviewed assessment in IGTF with relying parties that have done their own risk assessment for use of the assurance and bear the burden. External auditors are both too ‘expensive’ and add limited value (cost outweighs the risk) - Kantara level 2 requires access to protected databases, and level 1 is too low for the risk at the RPs - All use cases are global, so global credentials are needed and assurance must have 100% available coverage. Coverage is needed now (and having a notified natl. eID scheme is not even required under eIDAS) - The splitting off of AuthN could allow credential translation for AuthN - through account linking with just the authenticator - still will cover only part of the constituency - In Kantara, eIDAS, NIST the mix of controls and vectors is specific to a set of use cases that have a different risk profile than the R/e-Infra use cases So we define why each profile is spired by a specific and distinct use case - which is better than discussing _why_ they exist. These profiles exist becuase none of the other actually met the concrete risk profile of a suite of relying parties. Additional unconference sessions on assurance in TIIME are foreseen. On an IdP-SP-proxy and Sirtfi-ing un-Sirtfied IdPs -------------------------------------------------- Can a proxy, such as e.g. eduTEAMS, by itself claim Sirtfi towards its connected SPs, even if the upstream IdPs are not (all) Sirtfi compliant themselves? I.e. can a proxy 'bestow' Sirtfi-ness on a set of arbitrary IdPs? Of course the proxy can have user contact information in place, and should probably explicitly _by itself_ check the correctness of contact information if the upstreadm IdP is not Sirtfi compliant, but once such an additional email verification is done, contacting the user itself would work. That meets the traceability Sirtfi requirement regardless of the upstream IdP. However, the other value that Sirtfi has is the ability find the _authenticating entity_ where the compromise of the identity took place, and thereby potentially being able to find other SPs that were involved. That's what the communications model is exercising for example. And while the Proxy can do that for SPs connected to itself, that will only ever get to a subset of the SPs. So getting to the authenticator source is likely as important as the mere traceability aspect. And the spirit for Sirtfi would point to addressing the authenticating entity. (not that for IdPs that have outsourced their operation this is different, since there a contract governs what the IdP can see and do, as discussed on the Sitfi mailing list). Now if the Proxy is never re-inserted in and of itself into eduGAIN, it's only the SPs that need to trust it and the scope is limited. But if one re-inserts the proxy into the general metadata distribution, you are essentially 'laundering' the IdPs without Sirtfi into things that look "Sirtfied'. That kind of 'IdP-laundring' scheme seems in conceptual conflict with the idea of Sirtfi. Now if Sietfi is not being asserted because of technical issues (federation does not support entityAttributes, or not the Sirtfi one), then the Sirtfi+ registry would actually be a good solution - now for the proxy acting as SP - and get Sirtfiness from a good source. And the other option is to verify Sirtfiness out-of-band, just like e.g. RCauth.eu does it for identity sources that are not in eduGAIN or are not Sirtfi+R&S, but where the organsiation explicitly in a 'contract' agrees to comply with all material requirements (and then the proxy has to keep a record of these agreements). That is a 'paper bypass' around the fact that Sirtfi cannot be asserted in meta-data. PMA operational matters, review, and accreditations --------------------------------------------------- - For the pending self audits, ROSA is now completed and accepted, MDGrid, MAGrid, RDIG, UKeScience, and CESNET are still pending. The one from BG.ACAD is virtually complete and done. The AustrianGrid CA will be withdrawn in a future release. Thanks to Cosmin for tracking self-audit progress! - Due to extreme lapses in both self-audit validity as well as attendance to retain accreditation, the status of the BYGCA is being reviewed by the suspension-review committee. Alternative contacts by way of its customers (known to EGI) will be pursued as a last resort. - the secure key distribution mechanism for RCauth.eu was discussed and explained to the PMA, and in accordance with the then-approved procedure two parts of random data "a" and "b" were exchanged between Nikhef and STFC representatives. These HSM-generated one-time pads will be used to exchange the xor-ed aXbXk value over encrypted e-mail (3rd path). Attendance ---------- We would like to thank the following members for the in-person attendance: Paolo, DavidG, Maarten Kremers, Mirvat, DaveK, IanN, Eisaku Sakane, Ingrid, Jan, Scott, and of course Hannah and for their extensive presence in the videoconference: Miroslav Dobrucky, Nuno Dias, Vladimir Dimitrov, Uros Stevanovic, Pawel Wolniewicz, and Jens Jensen; and also Anders Waananen and John Kewley attended part of the meeting remotely Thanks to Derek Simmel for joining from a different time zone and presenting the TAGPMA updates. As usual, the names are entirely random order.