Dear EUGridPMA and IGTF members, dear AARC, EnCo, and EOSCH-ISM policy people, The 48th EUGridPMA meeting is now over, and I would like to take this opportunity to thank again CESNET, and in particular Jan Chvojka, Jana Kejvalova, and Daniel Kouril, for their unbounded hospitality during the week in Prague. 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/2020-01/eugridpma48-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at https://www.eugridpma.org/agenda/48 And these notes you can re-read at https://eugridpma.org/meetings/2020-01/summary-eugridpma-2020-01-prague.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. Alo thanks to Ian Neilson for making notes during the meeting. These are available at https://www.eugridpma.org/meetings/2020-01/Prague_PMA_meeting_notes-IanN.pdf Subsequent meetings will be: ** 49th EUGridPMA meeting, May 13-15, Garching near Munich, DE LRZ (Leibniz Rechen Zentrum) supercomputing centre hosted by Jule Ziegler This meeting again will be in collaboration with the policy harmonisation groups of our major relying parties, supported by GN4 EnCo and EOSCHub. ** 50th EUGridPMA meeting, September 7-9 in The Netherlands (for the moment we are keeping the choice between Utrecht and Amsterdam open, it will be either at Nikhef or at SURFnet) again jointly with GEANT's Enabling Communities activities and EOSCHub. and of course our affiliated meetings: * APGridPMA, ISGG, & SecWS, Taipei 9 (+10-14) March 2020 * TIIME workshop (and sidemeetings) 17-20 February 2020 Vienna (MGC Wien!) * TNC20 Brighton, UK 8-12 June 2020 * SIGISM & WISE-community, London, UK 21-23 April 2020 * NSF Cybersecurity summit Indianapolis 22-24 September (with likely IGTF all-hands meeting directly before or after, but at NCSA in Urbana-Champaign, Illinois) * Internet2 TechEx, Atlanta, GA, USA 4-8 October 2020 (with REFEDS likely on the Sunday) 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 ---------------------------------- * Risk Assessment Team Communications Challenge - RATCC and the SCCC-JWG * GEANT Enabling Communities (Engagement) - topical activities SCI Security for Collaboration v2 and AARC Policy Development Kit SCCC Communications Challenges Joint Working Group Assurance Profiles Sirtfi Attribute Authority Operations (AARC-G048) FIM4R - Federated Identity Management for Research OpenID Federation for Research Outreach for policy work * Applying AAOPS guidelines (AARC-G048) to the WLCG Token Issuers * On OAuth2 endpoint trust and federation distribution * SCI Assessment methodology and progress and WISE * Policy Development Kit and the top-level policy evolution * Assurance and REFEDS RAF paper * RCauth.eu distributed deployment update * Community specific policy recommendations - EGI * Jens' Soap box - a story of time and false dichotomies * PMA operational matters: The closure of INFN CA, one of our founding members GEANT TCS service will start its fourth iteration reviews and retirements * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/48 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/2020-01/eugridpma48-notes-davidg.pdf Risk Assessment Team Communications Challenge - RATCC and the SCCC-JWG ---------------------------------------------------------------------- The IGTF Communications Challenge was run on October 7th 2019. With messages sent out to 91 trust anchor contacts representing 60 organisations, within the challenge period of 12 calender days 90% of the organsiations responded, acknowledging the challenge, representing 88% of the trust anchors. Individual non-responses were followed up by the chairs, and were in most cases due to outdated contact information. Refreshed contact information will be included in the upcoming IGTF distributions (some changes were already implemented in the 1.102 release). Those that were not able to respond to the first challenge will be challenged again. Following some discussion the consensus was not to repeat-challenge the ones that did respond, although the burden indiced thereby was actually considered to be minor. "Transparency is the instrument of trust" A write-up summarizing the results (albeit without naming the individual organisations involved) will be curculated soon. This writeup will further strengthen the overview and cross-infrastructure trust that is being established through the "SCCC-JWG" - the Security Communications Challenge Coordination Joint Working Group. This group is a joint effort of the IGTF, WISE-Community, SIG-ISM, Trusted Introducer, and REFEDS to prevent overlapping challenge and - through sharing of high-level information - engender trust across infrastructures. The work, coordinated on the WISE Wiki pages, shared dates, periodicity, constituency, and summarized results for the major teams running comms challenges. Other communities are also welcome to add to this joint effort! https://indico.nikhef.nl/event/2146/contribution/3/material/slides/0.pptx https://wiki.geant.org/display/WISE/SCCC-JWG https://wiki.geant.org/display/WISE/Communications+Challenge+planning https://wise-community.org/ [will be updated shortly for the SCCC-JWG] GEANT Enabling Communities (Engagement) - topical activities ----------------------------------------------------------- The GEANT Project supports a range of trust and identity activities in support of the (global) eInfrastructures and Research Inrastructures: evolution of the SCI framework, promotion of assurance profiles, Sirtfi, Trusted AA Operations, the Policy Development Kit, and FIM4R. The work of this "ENCo" (Enabling Communities) task is done mainly in the context of existing initiatives, including the IGTF, FIM4, and WISE - with outreach foreseen at the upcoming FIM4R workshop in Vienna, and likely at the Security Workshop of the International Symposium on Grids and Clouds (ISGC) 2020 in Taipei. https://tiimeworkshop.eu/ http://event.twgrid.org/isgc2020/ https://fim4r.org/ ** SCI Security for Collaboration among Infrastructure (WISE-SCIv2) and PDK The SCI assessment sheet presented in Karlsruhe (Sept 2019) was tested using the EGI infrastructure as an example. The result was a spreadsheet that contained a large number of L2 and some L3 scores, reflecting both the documentation process and the implementation. However, collecting this information is a non-trivial exercise done by Uros, which does not necessarily scale quickly to other infrastructures. Uros will upload what is there to support such other evaluations. New work is needed on the top-level policy (on which more later), since the version in the current Policy Development Kit (PDK) - when applied to a new infrastructure - depends too much on adopting the PDK as a whole. With the references to supplementary policies it is not very suitable for incremental introduction of new documents, and also adds an additional layer of indirection that makes pertinent policies more complex to find for participants (sites, users, and communities alike). Work on a new top-level policy that will contain directly applicable high level concepts, which is then supported by more specific implementation measures for specific target groups, is the intended evolution of the PDK. It is useful to write this new structure in a separte publication (e.g. a paper for ISGC or another journal) - to be done by or through the WISE Community. https://wiki.geant.org/display/WISE/SCIV2-WG+documents https://aarc-project.eu/policies/policy-development-kit/ ** SCCC Communications Challenges Joint Working Group (see also the section on the RATCC4) The website for WISE to reflect the existance of the SCCC needs to be done and DavidG will request write access to make that actually happen. The Wiki page with future and recent Comms Challenges is available and the model seems to work, with different groups adding their plans and results (with of course some results being private). In 2020, we should encourage other groups that do challenges (XSEDE, SURFcert, hopefully PRACE or EUDAT) to join in this effort. Since SURFcert (also for the SURFconext federation) is already doing such challenges, adding them hould be simple, and Maarten has already requested that. We also see that encouragement for compliance and proper checking through dedicated prodding does work, with the InCommon baseline effort being an excellent example. With approx. 1200 hrs of work, adherence to the InCommon baseline went up within the year to almost 99.9% of all (3000+) entities. So with the right encouragement and some effort, great things can be achieved. https://wiki.geant.org/display/WISE/SCCC-JWG ** Assurance Profiles There is ongoing work to improve the REFEDS pages on the REFEDS Assurance Framework (RAF). Jule has registered the profiles with IANA in the RFC6711 designated registry, and is in the process of getting specific logos to advertise the profiles (SFA, MFA, and the Cappuccino and Espresso from RAF) [the 'AARC Assam' profile for social identity signalling is not included in this for now] The submission to ISGC to present on the REFEDS Assurance work has been accepted and work on the full paper is ongoing. A session at the TIIME unconference part will be proposed to discuss where the assurance work can lead (and how to best present it). To further the REFEDS RAF, Jule has also joined the InCommon Assurance group. Promoting the use of REFEDS RAF should now come from exposure and entities actually adopting it, both sending the assurance components as well as requiring them in order to access valuable services. The good example of CERN requiring R&S+Sirtfi comes to mind, which did effectively and efficiently boost the adoption of both by relevant IdPs - even if not universally appreciated by some. Signalling the capability for RAF profiles as well as SFA and MFA for (a non-negligable number of) entities in an IdP, or the need for having this for SPs, is ongoing, with entity categories being one option (the poll to discuss this is still open). It should however be noted that introducing new entity categories has been shown to be complex in the case of Sirtfi. A dedicated videoconf in February 2020 is planned on this topic. In some cases the RAF profiles already have been very successful. The TAGPMA-accredited CILogon authority has re-specified the requirements for the CILogon Silver assurance - previously linked to the now-defunct InCommon Silver assurance - to be based on RAF Cappuccino, allowing communities to assert verified compliance with this profile and obtain BIRCH-level IGTF certificates (since in this respect Cappuccino and BIRCH are equivalent). Jim Basney has also developed an assessment spreadsheet for REFEDS RAF, MFA and SFA, and both XSEDE as well as FNAL (Fermilab) have been assessed against this. It makes TAGPMA/IGTF in the US a good place to perform these peer-reviewed self-assessments in a way that is actually better scalable than InCommon by itself doing these. Discussions with InCommon are on-going (see the TAGPMA for more information). The FAQ for the Assurance Framework will be further enhanced in 2020. https://refeds.org/assurance https://www.iana.org/assignments/loa-profiles https://www.iana.org/go/rfc6711 https://refeds.org/profile/sfa https://refeds.org/profile/mfa https://aarc-community.org/guidelines/aarc-g041/ [Assam SocialID profile] https://indico4.twgrid.org/indico/event/11/session/14/contribution/7 https://doodle.com/poll/e9yxii72d6qfygvw [poll RAF as entity categories] https://indico.rnp.br/event/13/ [TAGPMA I2 TechEx meeting] https://indico.rnp.br/event/13/contributions/122/attachments/68/87/go ** Sirtfi The eduGAIN Security Team is now also involved in the Sirtfi working group, adding more procedural and operational background to it. The initial idea of writing an incident response handbook targeted at federation participants has been discarded, and replaced by a push for a set of simpler procedures that participants can refer to in case of (suspected) incidents, or when communicating between them (based on AARC I051). Borrowing some of the concepts from WLCG and EGI, a 'poster-style' leaflet with a checklist of things to do -- and specifically: in which ORDER to do them, and to communicate early and not wait for a final analysis - so that one can actually try and stop an ongoing attack by sharing draft Indicators of Compromise (IoCs) is being developed. Since the federaiton world is much less coordinated and more loose than the e-Infrastructures in which the work originated, these leaflets have to be adapted and evolved to be useful in their new environment. Uros and Sven are jointly developing these 1-2 page docs, which an operator can 'post on the wall' and refer to in case of crisis. One particular challenge is that in many cases the communications end-points are not well known, e.g. the list of federation contact points. This will be evaluated and then improved by communications challenges, using a mailer framework initially populated with generic contact addresses if a security contact is not (yet) known. The framework is borrowed from the one of the Security Service Challenges and developed by Jouke of Nikhef based on MailTrain. https://refeds.org/sirtfi https://aarc-project.eu/guidelines/aarc-i051/ https://docs.google.com/document/d/1aP5R8FRP5r2YMy4P_TeyzK9Tb1I_fENU7b6vNEk3rGc https://wiki.egi.eu/wiki/SEC01 https://wiki.egi.eu/wiki/EGI_CSIRT:Incident_reporting ** Attribute Authority Operations (AARC-G048) The AAOPS guidelines (which have been in the IGTF works since 2012) describe the minimum requirements and recommendations for the secure operation of Attribute Authorities and similar services. These are now being tried by various providers, such as eduTEAMS and the WLCG Token Issuing service, and further clarification is being requested [see also Hannah's talk] For example, the text on the use of virtualised environments leads to confusion, as it can be read to exclude any kind of cloud-based hosting. This was actually not what was meant with the text - which should rather be read as guidance on how to security provision and deploy such services in a cloud, including the use of commercial clouds like AWS. For example, in the case of AWS one can readily add HSM-based hosting of signing keys (since also the HSMs can be provisioned on-demand through the AWS console and APIs), and isolation guidance can be ensured by controls available through the AWS model (like full role-based separation, 2FA controls on all accounts, and putting in controls on the use of the API keys). Proper cloud services, including AWS, do have such controls available, and the guideline calls for those controls to be properly and fully deployed and implemented to achieve the security goals. The guidelines will evolve as experience is gained with their implementation (so that e.g. using the AWS MAAS capability is not a prerequisite for running a properly-secured attribute authority). In environments where there are less implementation controls (e.g. in private clould or self-deployed OpenStack environements, or where network isolation cannot be fully guaranteed at the host and network layer through e.g. per-customer EVPN, or where no advance warning of vulnerabilities is available, dedicated segments can be used to achieve similar levels of security. For this, cross-container and cross-guest exploitability - also in case of faults or virtualisation vulnerabilities - should be considered. E.g. AWS is known for getting vulnerabilty information in advance of the general public for their hypervisors (Xen security pre-disclosure list and the Linux-distros mailing list), and a Security Operations Centre with a plenty of staff is in place. In general, the AAOPS document merits more explanatory text and guidance, and a dedicated meeting should be set up to provide this. https://aarc-project.eu/guidelines/aarc-g048/ *** FIM4R - Federated Identity Management for Research The extensive activity of the group is on all the blogs posted at the FIM4R web site. Recently, also case studies (the first one from DAASI) has been added to the web site by Hannah. At the recent FIM4R meeting at TechEx (December 2019) it became clear that some communities have had enough, and are giving up on ever getting useful things from the home organisations. LIGO (ScottK) stated that R&S is no longer a priority since the adoption is much, much too small, and anyway the research communities themselves need to do the work. Initiatives like the ResearcherID (RID) by LeifJ are also indicative of the failure of IdPs to provide relevant attributes. Yet the IdPs do hold one elements - affiliation - that actually is relevant in many contexts (like "bona fide researcher" in the life sciences), so a use case for R&S does remain for some communities. Should FIM4R reflect on this in the follow-up paper to FIM4Rv2? Where are we know, and how can we circumvent the non-working bits if these are not going to be solved anyway anytime soon? https://fim4r.org/ https://docs.google.com/document/d/1dsc4WW3-OvLxwsf0GSV-oUQypK-mfeGz4vaD4mTASuw [on the RID concept - notes form ACAMP2019] ** OpenID Federation for Research Augmenting the traditional multi-lateral federation model, OpenID Connect (OIDC) federation allows for a more dynamic, meshed, system, with multiple roots of trust and ways to build trust bridges and hierarchies Using both authority_hints as well as dynamic retrieval of intermediate trust anchors, this could for example effectively support orchestration scenarios with dynamic client creation (and dissolution), as well as delegation of control to organisations. Over time, the spec has now gained many of the qualities that the PKIX model has, which indicates a growing maturity of the spec Although the general issue is very broad (and the domain of REFEDS/eduGAIN), doing federation specifically in the research scope (R/E-Infrastructures) is a far more traceable problem, with a few OPs (the proxies) and a large and dynamic, but still hierarchical, set of RPs. There is now an IGTF prototype OIDC federation service (formally: the meta-data signing service or MDSS), which for the time is a signed blob (signing by file-based key or HSM) but without entities in it. The application of this is discussed in the session on OAuth2 federation for WLCG and others. https://oidcfed.igtf.net/.well-known/openid-federation https://github.com/rohe/oidcfederation https://www.axini.com/files/2019_jouke_roorda.pdf ** Outreach for policy work Both FIM4R but also Enco specifically have challenges getting into contact with new communities. The option to do 'guerrilla marketing' at existing events was discussed, and bringing and spreading leaflets, such as those from the AARC project, may be a good way of getting noticed and engage in conversations. The AARC leaflets are available for use at e.g. ISGC. It is not known whether there are FIM4R leaflets, but these would be useful as well! https://aarc-project.eu/outreach/ https://aarc-project.eu/wp-content/uploads/2017/04/Sirtfi-Poster-2016.pdf https://aarc-project.eu/wp-content/uploads/2019/04/AARC-final-results-A4-final.pdf Applying AAOPS guidelines (AARC-G048) to the WLCG Token Issuers --------------------------------------------------------------- The WLCG community will be using IAM (Indigo's Identity and Access Management product) to issue OAuth2 compatible tokens for use in the WLCG services - in first instance primarily to authenticate user workloads that are run in overlay-execution clusters ('pilot jobs', where a placeholder jobs is submitted that acts like a container to execute within it payload jobs obtained from the outside). In the future, the applicability will of course get broader. The current model is to deploy the token issuing software as containers through a Kubernetes ("K8S") orchestrator. Can IAM be deployed with K8S and adhere to the AAOPS profile in terms of trust and security. Hannah's presentation highlights the discussion points: - validity periods of the access and refresh tokens (where the refresh tokens are revocable, but the access tokens are not) - what is a 'dedicated system' - and can a set of K8S deployed containers meet the virtualisation requirements stated in 3.4.2: "a virtual environment that has security requirements the same or better than required for the AA, and for all services running in this environment, and it must not leave this security context. Any virtualization techniques employed (including the hosting environment) must not degrade the context as compared to any secured physical setup." Some of these items were already discussed during the EnCo session (in the AWS context), but clearly more clarity is needed. This means that we should likely add an FAQ or more guidance to the document itself. In brief: - the 'dedicated system' was intended to apply to - in this case - the system itself, e.g. do not co-host a web-based content system like WordPress alongside the AA - such would be really bad practice. But a K8S deployed container, along with suitable orchestration, can meet this requirement OK. - the use of K8S itself is fine, as logn as all controls then meet the security requirements of the most sensitive service run therein. The intent is to protect against scenarios like 'mortal' end-users being able to reorhcestrate or influence the AA deployment, or having just a single layer to protect the AA (e.g. when a vulnerability in K8S would immediately endanger the whole AA because it is a global public facing service or so). Assuming it is protected in ways equivalent to, say, AWS's RBAC controls on VMs and making sure that untrustworthy services are not colocated with the AA on the same (virtual) machine. - for the token life time requirements in the AAOPS guideline, these apply ot the access token in this case (and 20min is much shorter than then 24hr max recommendation). The refresh tokens are revocable and this more similar to SLCS-like credentials for the user In addition, the refresh tokens are scoped to a specific relying party, making the risk assessment more local. For verifying the OAuth2 JWTs (which are signed) at the RP, there is a need to have trusted keys. At the moment, WLCG distributes files through a package management system, and there is no freshness mechanism built in to the (RPM-based) system. In also requires explicit installation of the JKWS material. To get to a more scalable system, deploying the (OAuth version) of OIDCfederation would make sense, and provide the trust fabric for obtaining the signed information from a single source. Meanwhile, one could also get the information from the .well-known endpoint, but there is a risk there since the trust in these endpoints would be purely relying on the integrity of DNS. In the absence of DNSSEC or actual organisation validation, relying on the well-known URL poses a risk both on installation and during use. This is a case where using EV (preferably) TLS public certs (or the requivalent IGTF classic) actually makes sense until validation of fingerprint through a federation-like service is in place. DCV-only leaves this open to DNS attacks (against the DCV authority and the site) as well as targeted phishing/disinformation. To check in an automated way for EV can be done by checking the policy OIDs, and for OV (and IGTF) on mandating the presence of an "O" (Organization) attribute in the subject DN of the TLS server cert in combination with public or IGTF trust. In general it is recommended to augment AAOPS/G048 with an FAQ, and document all these considerations and clarifications. https://codimd.web.cern.ch/p/HkURdTH-U/ [slides] https://zenodo.org/record/3460258 [WLCG Common JWT Profiles] https://tools.ietf.org/html/rfc6749 [OAuth2.0 framework] https://tools.ietf.org/html/rfc7009 [OAuth2 revocation] https://cabforum.org/baseline-requirements-documents/ [O in BR guidelines] https://cabforum.org/extended-validation/ [EV OIDs] On OAuth2 endpoint trust and federation distribution ---------------------------------------------------- The token issuer discussion and OpenID Connect federation discussion is similarly applicable to the work that communities are undertaking to move to 'tokens' (usually OAuth2 JSON Web Tokens or JWTs). These JWTs may be lean or, like in the case of the WLCG common profile, contain a lot of additional information of use for authorization decision making. In order to trust such tokens, they have to be signed, and the signature needs to be validated. Today, such information usually comes either from locally installed and (partially managed or unmanaged) files, or from just querying the ".well-known" endpoint. As described in the earlier sections regerding the vulnerability of of DNS and spoofing, there are potential issues with using only .well-known without further controls such as the equivalent of OIDCfed for OAuth tokens -- or automated or manual checks of the having the correct URL as intended using OV/EV validation checks in case such a URL is conveyed over unsecurd channels (email or so). The mechanisms that make OIDCfed scale to O(100) OPs and O(1000+) RPs will work equally well for OAuth2 issuers of JWTs, and the mechanism may provide some scalability and the opportunity for adding meta-data (descriptions, policy URLs, scoped and filters) that will become important if there are more than a few issuers of tokens. Also, it may better support token exchange protocols, such as those discussed in AARC G052 on the AppInt AAI architecture mailing list. Basically, one would want to automate such services and discovery in an almost P2P fashion, but then reliance and assurance are needed, beyond what just a DCV-validated URL will give you. The authentication of the endpoints provided through "OIDCfed-like" meta-data brings this assurance and proper identification. This applies btoh for the RPs (who needs to trust the issuer of the JWTs), but also to the token issuer, who may otherwise send (sensitive) personal data to RPs that have no right to know. ALthough in most scenarios now that would require that both the RP is untrusted *and* that the user additionally gives an OK to send the data (based on the insterstitial approval page presented before issuance). Without a (fingerprint) of the key in the upstream validated meta-data, the trust remains in just the jwks_uri. Adding jwks:keys to the meta-data is needed to protect agains DNS compromises But the risk appears smaller that what it could have been, as long as controls [*] are put in place on the validation of the endpoint. An OIDC Meta-data signing service (MDSS) for the federation (see spec) can assert policy URIs hat act like trust marks. Such marks cn be added to 'decorate' issuers that meet certain standards, and be incrementally added to improve the trust and integrity of the fabric over time. - the minimum would be a good well-known endpoint, and basic key sanity for the token issuer - then add other qualities as we learn more: AAOPS adherence, adherence to a membership management policy and processes, &c The result actually looks like a mix of TACAR and the meta-data marks and entity categories. Practically, with the OIDCfed MDSS service run by the IGTF today, the IGTF can sign collections of organisations, that can in turn sign the meta-data for the token issuers that they host. This actually matches the AAOPS model nicely, in that one professional organisation can host many communities and token issuers, without having to register each of them at the global level. Initially, there will only be a handul anyway (the 4 LHC experiments...) But in the future as this model gets more widely spread, one ends up with more (O(100) issuers), with thousands of RPs and OAuth clients (=services). Especially if services are being created on the fly and are ephemeral, e.g. driven on-demand by K8S or even in traditional clouds. This is a good use case for the oidcfed.igtf.net service - put the issuers in the MDSS including a unique name and URI for the endpoint of the key. In the same kind of format - even if manually created - and the result is a service that can scale in the future without fundamentally changing the concepts. A simple script can extract the relevant data and feed a local installation, making it more flexibly then a package management system like RPMs since it can be run from con on a frequent basis (hourly, or so). Initially: JUST distribute the trust anchors without further qualifying policies and marks and start incrementally with willing entities in oidcfed.igtf.net (and keep the software evolving - ask Jouke Roorda for details) https://tools.ietf.org/html/rfc7519 https://jwt.io/ https://zenodo.org/record/3460258 [WLCG Common JWT Profiles] https://tools.ietf.org/html/rfc5785 [.well-known URIs] https://lists.geant.org/sympa/arc/appint https://docs.google.com/document/d/11Amv6kjPvVVgWB71iEaj6NcrhlNzht7HP9GJK6cNOS8 [AARC-G052 draft] https://openid.net/specs/openid-connect-federation-1_0.html https://www.tacar.org/ [*] the controls are those discussed under "Applying AAOPS guidelines" on OV/EV, the O attribute, and the OIDs in the TLS server cert issued under CABF or IGTF guidelines. SCI Assessment methodology and progress and WISE ------------------------------------------------ The progress in assessing infrastructures using SCIv2 has slowed down (as noted earlier in the EnCo review), so there is a need to recall the SCIv2 working group in WISE and define a common direction for >2020 Beyond interoperability between infrastructures and services, the SCI assessment can also potentially be used in a wider context, e.g. in the EOSC, to engender trust also between services themselves based on the self-assessment sheet. Or between and with emering collective service offerings such as those coming out of CS3-for-EOSC or the EOSC supporting projects (Synergy, Pillar, &c). This could however need some work to make the framework more applicable to individual services. This might also help to make SCI more useful (or autoritative) for fostering cooperation between services and infrastructures (in like with the planning for EOSC trust as described in the EOSC White Paper on "Trust Coordination for Research Collaboration in the EOSC Era" But the SCI framework is also a good mechanism for the infrastructures themselves to do their own assessment and plan improvements - maybe with support by way of the WISE community. Dave Kelsey will reconvene/activate the WISE SCI working group, and at the same time validate with the group whether the evolution of the top-level policy and the Policy Development Kit in this WG is appropriate. https://g.nikhef.nl/eosc-sec-wp [EOSC Trust White Paper] https://wise-community.org/sci/ https://wiki.geant.org/display/WISE/SCIV2-WG+documents https://g.nikhef.nl/eosc-sec-wp-suggest [suggestions to EOSC White Paper] Policy Development Kit and the top-level policy evolution --------------------------------------------------------- The AARC policy development kit, as well as the recent updated to the top-level policy for the EOSCHub project, have significantly reduced the amount of text and statement in the top-level security policy that was inherited from the JSPG and in effect for EGI (and WLCG). Part of that was done to align with the rest of the PDK and prevent duplication of text and policy statements when used together, but when a policy suite is introduced gradually to a community (such as UK-IRIS), then it becomes apparent that is too minimalist. For example, there are no requirements on users or communities, since in the PDK such were described in the AUP and the community membership management policies. But the top-level policy now seems critically deficient in content in those areas. Adopting all of the policies referenced from the top-level document and the whole of the PDK in one go is considered overly complex, also because some of those documents are for now incomplete or not yet endorsed. A comparison between the current EGI top-level policy, the EOSCH one, and the one from the PDK was made by Ian Neilson in a doc -- with a graphic showing the interdependencies. Bootstrapping a new infrastructure idually needs only a top-level policy, the AUP, and the Privacy Notices. Subsequent steps can then include community management (probably aimed at the membership service operators rather than the communities themselves), but at least for a while a top-level policy needs to be able to stand on its own - thus replicating statements that may later also show up elsewhere. The direction towards a more comprehensive top-level statement (even if it may be a bit higher level), accompanied by specific implementation measures - in the manner already foreseen in the SCI PDK work described earlier - seems a viable approach, as long as enough substance and firm statements are included in the top-level policy. Accompanying the top-level policy can then be a (wiki) page with lists of measures and processes for specific target audiences (sites, communities, users, &c). Very specific guidance like operational, physical, and network security also makes more sense in an implementation measure rather than in the top-level policy, where is now feel out of place. This work will also need to happen for the EOSC at large, and has to be prioritized. Initially DaveK and IanN will address the immediate concern for UK-IRIS, and then bring the results back to update the PDK. This is linked to the other work item (in AARC/EnCo context) of restrucuting assigned to DavidG and Maarten. https://drive.google.com/file/d/1nJKsAbyyqYeUu6ObwXBX7tNIqaxok0pb https://drive.google.com/file/d/1owB45IssYibLKwIqbyZm0Gghij8ACjsf [policy comparison and the dependency graphic for the top-level docs] https://aarc-project.eu/policies/policy-development-kit/ [AARC PDK] https://docs.google.com/document/d/1Mv99Z50VgQSyLHcmdp16I-URy6lN-HJNLxckZtxkNB8 [policy development kit top-level policy] Assurance and REFEDS RAF paper ------------------------------ The work on Assurance will be presented at the ISGC conference and included in the proceeding thereof (Jule is the primary author). It leverages the AARC I-050 assurance comparison, which will be entered into Zenodo for reference (10.5281/zenodo.3627594). The paper can illustrate the profiles by picking a few use cases and describe how the profiles could be fulfilled in practice - and what mechanisms would qualify. In doing that, one should keep in mind that in giving such examples we set a precedent, so we should pick those examples where the implementation is clear (or the risk of misinterpretation is low). Like discussed for the renewed policy development kit and policy structure, in the end it boild down to a risk assessment for the relying parties invovled. So the examples could highlight a 'medium' (Cappiccuno) assurance for random-payload execution jobs (like a platform or infrastructure cloud), and a use case where low-assurance is sufficient in e.g. a 'canned application' (as per the VO portal model, see e.g. EGI Doc 80) scenario. AARC did conduct a survey to identity high-assurance needs, and the results indicated the 'usual suspects', namely the biomedical cases for ELIXIR and BBMRI. But in general hardly any service provider has done a self-contained risk assessment (and even the ones given do not yet contain sufficient information to make very firm statements on the assurance level needed). There is however a larger body of best practice, such as WLCG requiring a medium (BIRCH, c.q. Cappuccino) assurance level, and portals such as WeNMR also allowing social identity and self-registration (so basically DOGWOOD, a low level with just unique identifiers like R&S+Sirtfi). Further inspiration may be taken from the FIM4R paper and communities, although assurance was not a specific question in the FIM4R survey. The various elements of assurance merit discussion in the 'risk' context as well. For example, 2FA may appear a good choice in all cases, but that is offset by the cost (not for the factors per se, but for implementing the issuance and restoration-on-loss processes and vetting). In those cases where MFA is successful, it is either self-managed, or there is actual regulatory pressure to make it strong enough (like for financial institutions, where 2FA is being pushed hard). In many other cases, a step-up service is effective, given that it addresses only those flows where 2FA is actually needed without requiring a universal deployment and implemenation. Step-up is quite popular, with both e.g. SURFconext as well as the Life Sciences AAI/ELIXIR deploying them). The freshness quality also required processes, and the biomed use case again may push for prompt freshness to assess if users still meet the criteria that ethical access and data set protections impose on them. But for other use cases a 1-day freshness is overkill, and the more usual 31-days is adequate. Lastly, since proxies chain the workflow together, the provenance of assurance should be conveyed throughout. The discussion on these topics (and the paper) may continue at the TIIME unconference sessions next month. https://indico4.twgrid.org/indico/event/11/session/14/contribution/7 https://aarc-project.eu/guidelines/aarc-i050/ https://doi.org/10.5281/zenodo.3627594 [AARC-I050] https://documents.egi.eu/document/80 [VO portal policy] https://wiki.geant.org/x/JYFgBw [AARC high assurance inventory wiki] RCauth.eu distributed deployment update --------------------------------------- The RCauth.eu credential translation CA service (taking materially R&S+Sirtfi and issuing DOGWOOD-assurance IGTF certificates based thereon) is being re-engineered to allow the current single Nikhef/SURF hosted instance to be distributed across three sites, supported by RAL in the UK and EGI/GRNET in Greece. This work, supported by the EOSCHub project, is ongoing and in previous PMA meetings the secret key distribution mechanisms and processes have been discussed and approved. The exchange of one-time pads has almost completed now, and the plan is being implemented as agreed. The process took longer than expected due to the limited amount of randomness available in some cases. Issues to be addressed in Q1 2020 include the database synchronisation, initially using a VPN over the general GEANT IP service (to be replaced thereafter by a dedicated lower-latency VPC). The new CP/CPS also has been prepared for distributed operations, and the final details on the physical security and installation at GRNET will be added soon. The expected timeline to report the final status for review/self-audit is by Q3 2020. Front-end portals will be distribued as well, but need state synchronisation to allow the user to use active-active round robin selection of portals (e.g. using memcached over the VPN/VPC service). Having consistent state is especially important for back-channel attribute consumer services where the same end-point sate must be retained. This can follow the high-availability setup now in use for EGI CheckIn. https://rcauth.eu/ https://rcauth.eu/governance/ https://rcauth.eu/policy/DutchGrid-RCauth-Pilot-ICA-G1-CPCPS-2-v4.02.pdf Community specific policy recommendations - EGI ----------------------------------------------- Increasingly, services need to broaden there audience and are faced with users whose authentication credentials are not at the once-uniform assurance level to which communities like EGI had become accustomed. For a long time, differentiated assurance has been on the agenda, but it is only recently that the issue becomes pressing. For example, granting read-access to the infrastructure database of connected resource providers and services to view the list of avialable services and their contact end-points. In the case of EGI, for example the need to access "GOCDB" (the configuration database for the infrastructure) to users who do not and cannot readily get access to BIRCH/CEDAR level credentials. The risk assessment, to be done per service in this case, does suggest that alternatives are not necessarily bad: read access to basic non- personal information may not need such identity vetting. Or there are other ways in which a proper non-reassigned identifier from a socialID provider like Google can be linked to an authorization role. The generic statement "don't do harm", both to your users but also to your peer service providers, underpinning providers of service components, and to the infrastructure as a whole, is a good generic statement, but not many people and orgs are able to make a truly good risk assessment. The top-level policy thus should also add policy recommendations on a per-service target, andidentify a few 'reference services' and recommended assurance levels. As such, even thoguh the SPG is a policy body, it is often called upon to give recommendations to management on what could be acceptable. While making absolutely clear that the EGI SPG is not a decision body but providing recommendations, this does seem like an increasingly important role. This again ties in with the restructuring of the top-level policy and the implementation measures proces. The quality of the "2-factor" authentication of social IDs like Google should not be overstated. Firstly, because the '2fa' is not communicated through the authentication statements given (like in the ID token from OIDC), so the service cannot see whether 2fa was actually used. Secondly, since the 2fa is user managed, the strength of the 2fa _and its reset mechanism_ is an unknown element. And there are trivial attacks on the 2fa factors and the reset mechanism, even those using TOTP on a mobile device. SIM cards are anonymous in many countries, and even if not an activated virtual SIM card with message forwarding can be bauft for a few bitcoincents from e.g. Romanian providers. SMS itself is obviously insecure because of faults in the SS7 protocol, and TOTP soft token on mobile phones can happily store the secrets in plaintext (e.g. andOTP, which is a very good app and actually is upfront about it). Google actually does give you non-reassignment only and then only PROVIDED that an @gmail.com identifier is used (and not a link to an existing email address). But otherwise these are fully anonymous. https://codimd.web.cern.ch/2XbfoPJ2TwyiQwU3YfXjNQ#/ [may be restricted] https://aarc-community.org/guidelines/aarc-g041/ [social ID assurance] https://tools.ietf.org/html/rfc6238 [TOTP specification] https://github.com/andOTP/andOTP For the provacy notices, there is in many infrastructures a distinction between those services contracted by the (legal) entity managing the infrastructure (EGI.eu foundation for the EGI federation, for instance), and for the federation as a whole. For the former, data processing agreements are appropriate and the coordinating entity takes on the role of data controller. For the federation, the correct model is that of multiple independent controllers, bound together and adhering to a Code of Conduct, or CoCo, (or in absence of something formal there the informal CoCo and the BCR-like approach as described in AARC-G016. Meanwhile, the GEANT DPCoCo version 2 work is nearing completion. The final discussions on the 'monitoring body' that is needed are on-going, with the Dutch data protection authorities ("Autoriteit Persoonsgevens") being the agency to which the CoCo will be submitted. They will surely however talk to the EDPB before saying yes ... Meanwhile, the WLCG Privacy Policy is quite appropriate for the EGI federation, and DaveK will propose this one again now that the uncertainly about EGI.eu's direction with regard to data protection has been cleared up. https://wiki.refeds.org/display/CODE/Code+of+Conduct+ver+2.0+project [CoCo] https://aarc-project.eu/guidelines/aarc-g016/ [BCR-like approach] https://edpb.europa.eu/ https://edpb.europa.eu/our-work-tools/our-documents/topic/code-conduct_en Jens' Soap box - a story of time and false dichotomies ------------------------------------------------------ In the past forty years, programming languages changed - few people today are proficient COBOL programmers, with the popular language-du-jour changing ever more rapidly (the Go language seems to be the most popular with students nowaways). But languages are not the only thing that appears to change, the same holds for skills, or protocols. Yet change is gradual, and even now about 90% of the financial transation in the USA still involve a COBOL program in one way or the other. So should one adopt the latest and greatest thing, change continuously, and break backwards compatibility -- or now? Like using Ruby and Python that keep breaking backwards compatibility, or C and Perl that keep stability around for longer? In the IGTF context, with a vast range of interoperability challenges and latency in rolling out updates, complexity has to go somewhere anyway. And what holds for PKIX similarly holds for SAML. Or OIDC. So is SAML vs. OIDC such a false dichotomy? Or X.509 vs. token-based access? In the end, one still needs trust and authentication. What will you be thinking in 40 years, sitting in your rocking chair? https://indico.nikhef.nl/event/2146/contribution/18/material/slides/0.pptx Operational matters ------------------- * Roberto Cecchini has sadly informed the PMA that the INFN CA will be discontinued. As of January 2020, no new certificates will be issued, and the CA will stop issuing CRLs by the end of January 2021. We regret this decision of INFN management. Roberto is oen of the fathers of the EUGridPMA and IGTF, bringing rogour to the DataGrid CA coordination group in its first meeting in the year 2000, setting a shinign example for all, and helping out both peers as well as subscribers all over the world. His role as catch-all CA for various communities around and south of the Med was crucial in creating the e-Infrastructure landscape as we know it today. Moreover, Roberto hosted the founding meeting of the EUGridPMA in April 2005, and has welcomed us many times in Italy, both Rome and Firenze, creating and fostering unique trustbuilding opportunities. That is worth more thanks than can be expressed here. Those of us active in data protection and GDPR may meet Roberto in his other role as the INFN Data Protection Officer. * the GEANT TCS service will start its fourth iteration with a new back-end issuance provider: Sectigo (formerly Comodo). This means that the TCS CP/CPS documents for Server and Client certs will undergo some minor modification, referring to a new provider CP/CPS -- it is a modular design, augmenting specific RFC3647 sections whilst taking "other stipulations beyond those set forth in this document" from the CP and CPS of the back-end provider. There will be new trust intermediate and self-signed anchors, with new names (like "/C=NL/O=GEANT/OU=TCS/CN=GEANT eScience SSL CA 4"), but the subject DNs are expected to remain the same -- provided the subscriber organisations enters the same name on enrolment in the new system. Sectigo as a back-end provider is already accredited by way of InCommon at the TAGPMA (and indeed did already feature IGTF Server MDC SSL profiles). This makes the process much simpler. In any case, the OV validation under CABF rules meets or exceeds the IGTF Classic requirements. And for personal and robot certs, the TCS CP/CPS is leading (both for eduGAIN as well as the non-SAML-issuance process) and that process does not change. Reimer and Scott will review the changes and scan the Sectigo CPS version 5.1.6 (and 5.1.7 that should be issued to address those outstanding issued not yet resolved in 5.1.6 ...) and a red-lined version of the TCS CP/CPS documents https://sectigo.com/legal https://sectigo.com/uploads/files/Sectigo-CPS-v5.1.6.pdf https://www.terena.org/activities/tcs/repository-g3/ [TCS G3 pages] https://wiki.geant.org/display/TCSNT/TCS+wiki+(2020)+Sectigo https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ * The RDIG self-audit process and the timeline observed have resulted in the decision to initiate the proceedings forseseen for such cases under the Accreditation Guidelines * The open issue for the MD-Grid CA (discrepancy between root validity and the CP/CPS statement of 20 years) can be resolved with an update to the stated section of the CP/CPS * UK eScience CA CP/CPS update is still pending * the AustrianGrid CA will be withdrawn in the 1.103 version of the IGTF distribution Attendance ---------- We thank the following people for their in-person attendance: Reimer Karlsen-Masur, Dave Kelsey, Jule Ziegler, Jan Chvojka, Jana Kejvalova, Jan Jona Javorsek, Maarten Kremers, Sven Gabriel, David Groep, David Crooks, Ian Neilson, Scott Rea, and Uros Stevanovic and admire the endurance of those attending the meeting remotely: Cosmin Nistor, Lidija Milosavljevic, Miroslav Dobrucky, Mischa Salle, Hannah Short, Nuno Dias, Ronald Osure, Mirvat Al Jogami, John Kewley, and Jens Jensen.