Dear EUGridPMA and IGTF members, dear AARC policy people, The 46th EUGridPMA meeting is now over, and I would like to take this opportunity to thank again Maarten Kremers and SURFnet for hosting us in Utrecht and providing some excellent trust building opportunities not only during daytime but also in the evenings. 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-05/eugridpma46-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at http://www.eugridpma.org/agenda/46 And these notes you can re-read at https://eugridpma.org/meetings/2019-05/summary-eugridpma-2019-05-utrecht.txt Specific thanks goes also to the GN4-3 and EOSChub project and participants, who have contributed their effort and ideas and attendance, and to the broader AARC Community. As usual, the joint sessions for Policy Harmonisation formed a great contribution to the IGTF schedule. Subsequent meetings will be: ** 47th EUGridPMA meeting, September 23-25 2019 at the Karlsruhe Institute of Technology KIT, Karlsruhe, Germany 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: * TNC19 and REFEDS, Tallinn, Estonia 16 June - 20 june 2019 * APGridPMA at APAN48, Putrajaya, MY 22-26 July 2019 * APGridPMA, in conjunction with ISGC2020, the Security Workshop, and HEPiX: ISGC 2019, Taipei 9 March 2020 * TAGPMA28 at I2 TechEx 2019, New Orleans, LA, USA 9-12 December 2019 See all of you in September, or at any of the upcoming meeting of the IGTF or elsewhere! Best regards, DavidG. Subject discussed and listed below ---------------------------------- * Combined Assurance Model and the Registration Practice Statements RPS -- The short term process to be applied to the LIGO request -- * Peer review and assessment of SCI version 2 * Assurance Framework comparisons * Privacy Notices and Transparency for GDPR * Security Communications Challenge Coordination Joint WG * Jens' Soapbox * Beyond AARC: aarc-community.org * GEANT: Enabling Communties * PMA operational matters: reviews and retirements DigitalTrust (and retail portal for public trust IGTF compliant certs) RCauth.eu distributed operations model and CP/CPS review next SPG policy meeting EOSCH/WLCG/EnCo/EGI/NA3 * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/46 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. The scribbles also contain more information: https://eugridpma.org/meetings/2019-05/eugridpma46-notes-davidg.pdf Combined Assurance Model and the Registration Practice Statements RPS --------------------------------------------------------------------- In the combined assurance model (CAM) as introduced in e.g. the EGI Acceptable Assurance policy and for the WLCG IOTA CA (and now available in the policy development kit), part of the authentication load can be performed by the community instead of being done at credential issuance time. The combined result, however, will satisfy the assurance requirements of the relying party (service provider), and in ultimo the authentication of the user to the service is assurance to the same level of identity vetting. As seen for example in the combination graphic of https://indico.nikhef.nl/event/1795/contribution/4/material/slides/0.pptx the vetting data supporting issuance of BIRCH (Cappucino) credentials can be performed by the same registration body (community) that would also support the binding of identifier-only credentials (DOGWOOD) post-hoc to vetted community attribute assertions bound to that user. The equivalence is demonstrated by the LIGO LSC vetting process, where the same set of documented processes by the community would enable both the EGI CAM model as well as support the (proxy) IdP to meet the REFEDS RAF Cappucino assurance level and be eligible for CILogon Silver (BIRCH) end-user credentials. [the LIGO "in and out" policy will be distributed to the IGTF,AARC-policy, and EGI SPG groups shortly] The CAM model focusses primarily on identity vetting: https://wiki.egi.eu/wiki/SPG:Drafts:Assessment_Community_IDvetting_adequacy and in that respect actually addresses the same elements as the vetting sections (3.x) of the Registration Practice Statement v1 https://wiki.eugridpma.org/Main/RPS The evaluation matrix suggested for the CAM model is the one provided by the IGTF under but the operational security aspects are reflected only in abstract terms ("a statement of their compliance with the Community Operations Security Policy") under the assumption that the operator of the attribute authority is already compliant to relevant guidelines. Such guidance is actually available in the form of the AAOperations Guidelines (AAOPS, AARC-G048), which goes into much more details and provides guidance for some other sections (in particular sections 5 and 6 of RFC3647): https://www.eugridpma.org/guidelines/aaops/ https://aarc-community.org/guidelines/aarc-g048/ The guidelines were adopted by the IGTF at the Geneva meeting, and they have been given to e.g. eduTEAMS in the form of a checklist https://www.eugridpma.org/guidelines/aaops/G048-Assessment-Sheet.pdf https://www.eugridpma.org/guidelines/aaops/G048-Assessment-Sheet.ods and they should be added to the Policy Development Kit https://aarc-community.org/policies/policy-development-kit/ in due time. The concept behind Registration Pratice Statement (RPS) model is that communities in an RA domain could both move between credential issuers, as well as be served by multiple issuers at the same time using a common RPS statement. As long as compliance with the assurance profile (in this case BIRCH) is fine, _and_ compliance with the policy and practice statements (CP/CPS or otherwise) of all credential issuers is maintained, this is perfectly fine. Having the RPS, and its completeness and structure in RFC3647 format (which also underpins the AssuranceAssessment evaluation sheets), can help the communities in addressing all relevant issues, especially when complemented with commented guidance and examples in the PDK. How to evolve the RPS (if needed), and how to address the guidelines in AARC-G048/AAOPS should be merged with the RPS in RFC3647 format, are also good topics for discussion at TechEX19 (ACAMP and/or TAGPMA). -- The short term process to be applied to the LIGO request -- The document that LIGO sent to start the CAM process (the "InAndOut" policy) will be distributed and discussed in the current form and, based on the feed-back received, should proceed to preliminary acceptance under the CAM model (the implications for meeting REFEDS Cappucino were not discussed). Any evolution, for LIGO as well as for new communities, in evolving the RPS to ease the process (and aim for more complete descriptions if so required) can then proceed at its own pace. Comments on the content (e.g. on the non-expiration of accounts, or which of the models would be the ones selected for use with CAM, or on the processes for LIGO LSC collaborators and staff) are welcome as input for the interim go-ahead. Peer review and assessment of SCI version 2 ------------------------------------------- The WISE Security for Collaboration among Infrastructures (SCI) working group (SCI-WG) is the home of the development of the policy framework that supports the trust interoperability between digital infrastructures for research. Having the SCIv2 framework endorsed in 2017, the next steps include the assessment model, self-assessment, and the peer review that helps building trust between both e-Infrastructures as well as the research infrastructure services. An assessment sheet and rating method has been developed (see https://wiki.geant.org/display/WISE/SCIV2-WG+documents) but the combined scoring of criteria (especially when there are many sub-points to be considered) is non-trivial: neither an average nor a lowest value would do justice to the complexities encountered in evaluating policy. The Spider diagram concept (for example the one for SVIv1 in slide #16 of https://indico.nikhef.nl/event/1795/contribution/7/material/slides/0.pdf) allows for a far more detailed comparison, and this model was chosen as the starting point for evaluations. To structure the process, a number of elements could be put in place: * a guidance document to aid the assessment, and this can thereby help both communities and infrastructures to do the assessment (and peer assessments). For SCIv1, this was partially developed (on the Wiki, see https://wiki.geant.org/display/WISE/Guidance+for+SCI+version+1) but it is incomplete and does not reflect the version-2 changes. * for the assessment sheet, it might be useful to image a '3rd dimension' to the sheet (e.g. different sub-sheets), so that the relation can be seen in how the different peer infrastructures assess and 'rate' the information provided. This can subsequently inspire a different maturity rating model. In conventional assessments, having a document is a prerequisite for meeting any maturity level, but if peer infrastructures typically value material compliance over documentation, this can or should be reflected in the relative rating (and could be seen this way). * to get the intended continuous improvement, a sub-set of the elements can be targeted each level, or an increase in maturity can be so-targeted. This can be done in the same way that 'baselines' are now being introduced in various places, and then gradually improving (raising) the baseline over time. This way, the infrastructures and communities are both included as well as gain greater benefit over time by being part of the scheme. The subset can thus be either a subset of points, or only showing (for everyone) only the first few maturity levels Which elements are targeted can also be interactive, picking one section at a time -- e.g. starting with OpSec since much material is already in place because of Sirtfi and the existing SCIv1 guidance. The peer review process can support that, and/or be akin to the assessment of the baseline process in InCommon and in eduGAIN, where the bar is being gradually raised. For SCI: many of the infrastructures are already operating and interworking in most cases anyway, and the model used there could perculate up from the generic e-Infrastructures (putting a baseline on their communities) up to the other infrastructures for research (that can be a subsequent target, and could then benefit from the experience gained). And in general SCI is better appreciated for DI4R's than the single-org ISO27k-like assessments. To get this going - following discussion with the WISE SCI co-chairs and the WISE community obviously! - would likely need some dedicated effort and maybe a workshop (but with work actually done also in-between meetings!) But the result could be very worthwhile: if a 'assessment trust mark' can be conceived and 'gained' as a result of this, it's certainly worth a press release and maybe a ceremony at TNC in 2020 or so, following up from the SCIv2 endorsement. The work in the WISE SCIv2 WG on this can be supported by the GN43 EnCo task (Uros and DavidG) as well as from other sources. Inclusion from other partners (e.g. at the NSF Cybersecurity Summit, from Susan at OSG, and from BoBC at TrustedCI), and using the NSF CSS in October to spread the word, would be beneficial. Assurance Framework comparisons [see https://aarc-community.org/guidelines/aarc-i050/ for context] ------------------------------------------------------------------- The assurance framework comparison done by Ian Neilson was presented in the form of a series of abstracted diagrams with a specific 'content encoding' that makes it possible to compare visually a wide range of identity assurance frameworks: from REFEDS RAF and the IGTF to the Kantara IAF (close to NIST v2) and the European eIDAS eGov levels. The diagrams can be downloaded on the AARC Wiki for the Comparison Guide to Identity Assurance Mappings for Infrastructures https://wiki.geant.org/pages/viewpage.action?pageId=123766068 and their context is explained in the white paper AARC-I050 https://aarc-community.org/guidelines/aarc-i050/ with Kantara being the most complex one (since it has the fewest implicit assumptions or 'grains of rice' to depend on). It also shows that the REFEDS RAF framework has been effective in keeping out complexity. Some of these diagrams are even more complex than others: in the eIDAS diagram the sub-boxes with dotted line offer alternative paths through the criteria, and in the Kantara diagrams the dashed boxes indicate text which is highly similar in content yet differently worded across the various profiles. The 'empty' (hollow) boxes there indicate negative requirements ('one shall NOT do this') for the methods that are permitted or required for other profiles. Finally, the Spaghetti Diagram shows the relationship for identity vetting based on the REFEDS RAF vetting levels. Foreseen work (e.g. as part of NGI-Trust) will target risk assessment commonality between the frameworks, on which also Leif and Collin are expected to work with Ian and DaveK - looking for the feasibility of finding common parameters for the risk assessment. Considering the eIDAS use cases, it is interesting to note that the UAE (as the first non-member state) is also pushing adoption of the eIDAS interoperability, inspired by the need of fintech and other sectors to interwork with the EU. Scott has the relevant policy mappings. For the practical work for e.g. exchange students in Erasmus, the thing that actually works now (eduGAIN) is much more suitable, but can be linked to eIDAS as and when relevant (there is effort going into that). The adoption of the REFEDS RAF profiles should be encouraged as well. The was CERN introduced the Sirtfi requirement - even if it was rather sudden - did create the appropriate level of attention and strongly stimulated adoption. Upsetting R&E identity federation people is an apparently effective way of making things really happen ... although SPs requiring the adoption of RAF and e.g. Cappucino could be done a bit more gently, maybe ... Privacy Notices and Transparency for GDPR ----------------------------------------- The GDPR (the personal data protection regulation for the EU that is gaving global effects) requires the presentation of 'privacy notices' to users (data subjects) to be transparent about the processing. Doing that in a way that is actually user-friendly and feasible is a non trivial exercise, and having common (overarching or template) notices drafted at the infrastructure level can significantly ease the burden for all. The most urgent need being with WLCG, the team evolved the latest draft "WLCG Privacy Notice" - although the principle applies to any well-organised and structured community. The text was discussed and revised, and the (snapshot of) the latest version (0.7, May 22nd) is available at https://indico.nikhef.nl/event/1795/contribution/10/material/0/0.pdf and is both a 'default policy' and template, but does allow for per-service overrides of the policy notice, since specific services can (and will in some cases have to have) their own processing requirements. The document itself will be presented to WLCG (MB) for endorsement. And then whatever we do here is anyway far better than having the researchers use Google since that is the 'only thing that is easy enough'. Security Communications Challenge Coordination Joint WG ------------------------------------------------------- The Sirtfi challenges, of which Hannah ran two during the AARC project against a carefully selected set of entities and organisations, have again shown the benefit of testing both contacts and procedures for incident response. The detailed reasoning and background can be found in the presentation https://indico.nikhef.nl/event/1795/contribution/12/material/slides/0.pptx and the idea of challenges coordinated per constituency is widely endorsed. When presented at the joint SIG-ISM/WISE workshop in Kaunas, both SIG-ISM as well as REFEDS chairs expressed the desire to have a joint effort in this area -- and thus the SCCC will likely be a joint JWG working group between all of these. Who is to challenge e.g. the entities for Sirtfi? That would be eduGAIN in the logical case, esp. with the evolution of eduGAIN to have a stronger lvel of coordination and a security capability embedded. Yet there are also potential issues: it is felt that entities (in eduGAIN like in eduroam), are more amenable to answer if they are contacted by their 'own federation', yet the Sirtfi contact meta-data is direct and point-to-point, so if challenges are run my the natl. federations, it is not representative of a 'real case' where the contact would by definition come from outside. ` The discussion converged on aiming for a 'all entities comply or have been fixed' model, where all involved at least meet the baseline expectations for responsiveness. Although some statistics can be shared, and details made available within a community, there is - at least for now - still reluctance to share even distributions between the infrastructures. Pushing this could be reminiscent of the "Orlando eduGAIN gripe', where even tagging entities by relying parties was by some considered 'not done'. But of course, rating (and sharing those ratings with peers that want to re-use such assessments) can neither be prevented nor should it be frowned upon, actually. It does highlight the fact that the IGTF RATCC challenges have been lagging a bit. Hannah volunteered to - with the available tools - contribute to the effort. Thanks! Jens' Soapbox ------------- The lack of a proper venue to discuss and share technical and operational developments in support of issuance is getting more obvious, and the Q-series soapbox this time focussed on easing issuance of host (TLS) certificates and how to both support automated revocation (and by whom) as well as look at issuance. The slides are available at https://indico.nikhef.nl/event/1795/contribution/15/material/slides/0.pptx and by extension the discussion leads to awareness of ACME and the need to evolve ACME to also address OV and EV use cases. What it also shows is the wide national diversity in platform availability, with somethings being easier in a country, whereas different thing conversely are more complex. The need for a venue (like CAOPS) was re-identified, and the option for TechWednesday revived. It would need actual (in-person) participation to make that one effective, and participation by techie-developers as well Beyond AARC ----------- The AARC/2 project finished on April 30th, and the collation of information for the final review of the policy and best practice activity is available at . But the AARC community, and the work that AARC started and supported over the past four years, will continue - and we hope that the community that has grown up around AARC will continue to thrive. Following discussions with the key stakeholders in the AARC Engagement Group for Infrastructures (AEGIS), it has been decided to keep the community alive, and support that via the continued existing of the web site and mailing lists. Work on architecture is already happening on the AppInt list, and the policy work in IGTF, WISE, REFEDS, &c, but e.g. the Guidelines pages and the Policy Development Kit are key resources on the AARC web site that will need to keep evolving. The AARC brand is far better recognised than AEGIS at the moment. Therefore "aarc-community.org" will take over from aarc-project.eu, and the latter will forward to the community AARC site that will have new content and updates (a historic version will be preserved of the project site as well). That can also support ongoing work on the PDK, which has seen broad adoption (on the SURF Science Collabroation Zone, in the UK IRIS infrastructure, &c): https://aarc-community.org/policies/policy-development-kit/ The AAOPS and AUP work should be brought in to the Policy Development Kit as well. GEANT: Enabling Communties -------------------------- The 'EnCo' task in the GEANT project, specifically the subtask on eScience Global Engagement, is there to support those developments in the policy and best practice areas that would benefit the community at large, and do that by means of supporting the work in the existing forums such as WISE, FIM4R, IGTF, REFEDS, AARC-community, and the research and e-Infra communities directly. The schedule for 2019 will include the following activities -- subject to the evolution and alignment in the respective groups, obviously: * SCI evolution and assessment to trust Guidelines development Selection points per phase / year Assessment -> Spiders diagram Baseline for their benefit Planning Y1 2019: Contribute effort in WISE - Uros & DavidG; Aim for the guidelines to be finished; Align with the other people in WISE SCI WG * SCCC - Security Communications Challenge Coordination Joint Working Group Many different challenges to be coordinated ?? List of type of challenges & putting it on the wiki Create a shared calendar Invite infrastructure who challenge their own infra Planning Y1 2019: Contribute effort in WISE/REFEDS/IGTF - Hannah & DavidG; Aim for charter/scope, get challenges on wiki & shared; calendar of challenges; Align with the other people in the WISE SCCC JWG * Assurance Profiles Working out FAQ: Technical, and Best practices Outreach to research communites: Find the right conferences, Find research collabs to request the RAF profiles,Stories/Blogs experience, IANA registry (6711) -> Put in the REFEDS profiles Logo for assurance and more in general (should we make a 2x2 square on who supports what? and take care to not suggest unlikely combinations like Espresso+SFA or so) Planning Y1 2019: Contribute in REFEDS - Jule; Aim for finish FAQ & Outreach; Align with the other people in the REFEDS Assurance WG * SIRTFI Evolution of the incident response process Get input for the eduGAIN security team Planning Y1 2019: Contribute to REFEDS SIRTIF WG - Hannah * AA operation guidelines Target 3 infrastructures (eduteams, checkin, WLCG ) for trying/feedback Planning Y1 2019: Target 3 infrastructures - David, Maarten * Targeted advise on PDK implementation Give advise at request If needed adjust PDK (Curate and improve) Planning Y1 2019: At request, all ppl * FIM4R Support and Pushing FIM4R further : Hannah Lastly, the EnCo mailing list does contain more people than 'just' the eScience global engagement/policy people, whereas the 'AARC' NA3 list (policy and best practice harmonisation) does contain the intended subset, and includes the other relevant folk. We can continue to use the 'aarc-na3@lists.geant.org' list, even while we consider a better name for that list (since "NA3" will soon be meaningless). PMA operational matters, review, and accreditations --------------------------------------------------- - Pending self audits: CESNET is still pending (the reviewers need to read the updated documents), for MAGrid and MD-GRID the work is still pending as described on the self-audit pages. The AustrianGrid CA will be withdrawn in a future release. Thanks to Cosmin for tracking self-audit progress! The BYGCA is closing down once a migration to a catch-all service or solution for the WLCG community users has been implemented. - the TCS Generation 4 requirements with respect to the infrastructures for research were presented and validated based on the collective expertise. - DigitalTrust (AE) presented the results of the audit and changes to the structure and new trust roots DigitalTrust will be able to offer client and TLS certificates that are both publicly trusted as well as compliant with the IGTF profiles (Classic/CEDAR). Although the exact details of the RA process will still have to be worked out, this would open the option for service global individual subscribers as also these profiles will be offered via the Retail portal. This retail option for the first time opens the way for global end-user- targeted certificate issuance - the distributed operational model of RCauth.eu was reviewed and explained to the PMA. Pending the implementation of the dedicated VPC for low-latency database synchronization, a multi-factor authenticated direct OpenVPN connection with super-encrypted communications is considered adequate as a transitional solution (AES256 + shared secret _and_ PKIXEEC for mutual authentication of the service end-points involved). The distributed setup will include a Luna USB-based HSM at RAL, and a PCI-e based Luna at GRNET. Both GRNET and RAL will provide the details relevant to the CP/CPS by early June and that version is available for the PMA to review at - the next policy meeting for NA3/EnCo/EOSCH/EGI/WLCG will be in Ljubljana in early June. The agenda and topics will be: WLCG policy framework; LIGO assurance and the CAM model; containers vs VMs in the VM endorsement policy - or alternatively look at the requirements for policy around alternative risk mitigation models for VMs like network-level detection and isolation (and cooperation with e.g. the SOC WG and Bro/Zeek work, as well as Contail/Bagpipe tenant network isolation); processes to follow up on identified risks in risk assessments; input from FIM4R and the rest of GN43; solve the EUDAT AUP comments; reflect on the restructuring of the EOSC integration levels; a general discussion on cloud risks; and more. Meeting hosted by the Jozef Stefan Institute and joint with EGI CSIRT. Attendance ---------- We would like to thank the following members for the in-person attendance: Maarten, DavidG, DaveK, Uros, Jana, JanC, Ian, Scott, Hannah, Walter, Jule, and Mischa and for their extensive presence in the videoconference: Miroslav Dobrucky, Nuno Dias, Vladimir Dimitrov, Mirvat, Roberto, AndersW, Reimer, and also thanks for Jens, Nicolas, JohnK, MarcusH for joining in. Thanks to Derek Simmel and Eric Yen for joining from a different time zone and presenting the TAGPMA and APGridPMA updates. As usual, the names are entirely random order.