Dear EUGridPMA and IGTF members, dear AARC policy people, The 44th EUGridPMA meeting is now over, and I would like to take this opportunity to thank again both Mirvat (as well as Jean-Francois and Claude) of GIP Renater for arranging the meeting and the truly excellent ambience and support - and our local hosts Jean-Michel and Anna of the national digital trust centre PNCN for hosting us in Toulouse. 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 (to come) https://eugridpma.org/meetings/2018-09/eugridpma44-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at http://www.eugridpma.org/agenda/44 And these notes you can re-read at https://eugridpma.org/meetings/2018-09/summary-eugridpma-2018-09-toulouse.txt Specific thanks goes also to the AARC project and participants, who have contributed their effort and ideas and attendance, and reinvigorated the work on the AA Operations Guidelines, the WISE baseline AUP, and the SCI assessment methodology work: the joint session for Policy Harmonisation formed a great contribution to the IGTF schedule. Subsequent meetings will be: ** 45th EUGridPMA meeting, Jan 21-23, 2019 starting at ~13.00 and finishing Wednesday at ~12.00 at the CERN, the European Organisation for Nuclear Research, Geneva, CH details on how to best book your accommodation will be circulated later - there is an on-site hostel that still has available rooms! and of course our affiliated meetings: * I2 TechEx & REFEDS, Orlando 14-18 Oct 2018 * APGridPMA, IGTF All Hands & ISGC 2019, Taipei 31 March - 5 April 2019 * TNC19 and REFEDS, Tallinn, Estonia 16 June - 20 june 2019 * APGridPMA fall meeting with APAN48 See all of you in Geneva in January, or at any of the upcoming meeting of the IGTF or elsewhere! Best regards, DavidG. Subject discussed and listed below ---------------------------------- * Attribute Authority Operations * Acceptable Use Policy * Key Distribution for RCauth.eu * Security for Collaboration amongst Infrastructures SCI Webinar * SCI: framework assessment versus formal ISO methods * PMA operational matters, reviews, new Grid-FR, RCauth.eu governance * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/44 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. Attribute Authority Operations ------------------------------ The "Guidelines on Attribute Authority Operations" should deal with the _operational security_ aspects and the operational trust aspects that are inherent in deployment of sources of Attribute Authorities and other issuers of access-granting statements. It can in many cases apply also to the other elements of a Proxy (from the AARC blueprint model), but should not stray into discussing architecture and choices there - this is mainly targeting operational trust and operational security. Reflecting on the fact that the same aspects are also seen in technologies like (capability) tokens, it will be equally relevant in the JWT/OIDC space. Yet keep in mind that (apart from the fact that they may be bound to anonymous bearers), these tokens and capabilities are no different conceptually from what we have always had with ("VOMS") attribute certificates and SAML statements that have attribute data (groups, roles, and capabilities are just different names for the same things - they all in the end need to be interpreted by a service's authorization system!) This guideline does not address the (receiving) service authorization systems, but purely the issuer c.q. source of attributes and the proxy. One thing that must remain in scope are systems using attribute look-up, like the "central" LDAP for PRACE. Attribute lookup sources are in-scope for this guideline. Specific questions answered: 1. Are issuers of capability based tokens (indirectly determined from attributes) classed as Attribute Authorities? - these are in (probably by extension to much of the SP-IdP-proxy ops as well) since capability tokens are no different from other assertions besides them potentially not being bound to a subject 2. Do we need to differentiate between access tokens and refresh tokens? this is very "OIDC" specific, but there is a valid case to discuss re-usable tokens and renewable ones -- although how much bearing it has on the issuer is to be seen (at least the issuer should have a means to (implicitly) 'revoke' a refresh token if the underlying attribute entitlements have changed or the owner thereof is no longer valid 3. There are several points where the AA Operator is communicating with the AA. This will now be the communications (agreements) between the Community and the AA Operator. But that communications still has a role in OpSec. and the definitions were aligned with the Community Membership Management Policy from the PDK/Snctfi suite. The document (introduction and sections on naming, attribute management and assertions) were reviewed and edited in real time in: https://docs.google.com/document/d/1k1Xdk456cq6ILiodqkmRJRevBWzfWjwau9tkuRjIAWQ/edit but it is also clear that the structure of the document does not make for easy reading and makes it verey hard to apply to concrete use cases. Suggested is to restructure the way the document is presenting the various elements: - Add to each section an introduction with the reasons why and context (akin to the one in the LSAAI DPCoCo/R&S guidance - Clarify specific guidance for each ‘technology’ in boxes like in the generalised LoA document (“CEDAR” &c) and list (per item/section?) the technology types identified: - Direct directory lookup (“PRACE” model) - Issuance of subject-bound attribute statements (“VOMS”, SAML assertions, subject-bound tokens “JWTs” with attributes &c) - Issuance of pure anonymous bearer (capability) tokens (“JWT”s) - provided they have any special requirements This still has to be discussed also with Hannah Short - the main editor now. If useful, also Uros and DavidG can have a go at this. Complementary to this (at least that would be the intention) is the guideline on architectural requirements "AARC2-DJRA1.3" which discusses the "VO Platforms for Research Collaborations" https://drive.google.com/file/d/1_4B_1rD9Ewx0QFh9g-LU5kCQeGxiHQ9E/view and supports the development and evolution of platforms that can implement the Community Membership Management Policy. How such platforms (and others like the Directory) are best viewed from an operational security perspective should be the object of this 'AAOPS' guideline. Acceptable Use Policy --------------------- The WISE baseline AUP was discussed and revised in real-time during the meeting. An open issue - and one on which people are invited to send suggestions - is a better terms for "Granting Authority"! The new draft v1.1 of the AUP is now available at https://docs.google.com/document/d/1Jd8b53nCQktI6f3RyL4k72XwHzQp-jm46YMZNR34vFw/edit?usp=sharing and the next step will be send this to WISE for comments (and wording suggestions for the Granting Authority :) Of course also all other IGTF members can send comments. After that it will be presented (for acceptance, not wording comments) to the Infrastructures for adoption. Key Distribution for RCauth.eu ------------------------------ The distributed redundant operations of RCauth.eu in the long term are supported by EOSC-Hub (an EC H2020 supported project) to enable its distributed operations both in terms of software and in terms of process. A draft plan has been drawn up (linked from the agenda pages, "***mgj14") on how to securely move the pieces of key material that need to be present in each of the three locations: STFC/RAL, GRNET, and Nikhef. The choice to use a single key pair was discussed and agreed in the Karlsruhe meeting. Now the challenge is to make sure the key is safely transferred and not taken/copied/stolen in transit (e.g. at a customers border control point forcibly taken off the courier). Experience by JanC from the banking sector showed that for that level of risk using three independent complementary channels is sufficient. That is best done by generating two fully-random sequences and XORing these two with the private key, together generating three elements. Each can then be carried in an independent way, _sequentially_ with 'canarie detection' to mitigate the border-control-post scenario. The method discussed and agreed was to use three mechanisms: 1. hand-carried by a trusted person of fragment 1 on a USB key face-to-face 2. a USB key sent (while the first is not in transit) by registered postal mail 3. a fragment sent by encrypted (GPG or IGTF personal S/MIME) email to ensure the transfer was itself correct, a simple (Adler32/CRC) checksum would be enough, given the inherent redundancy in the encrypted key blob The EUGridPMA approves this transfer procedure. The governance boards of the new RCauth will be populated as discussed, where Jens _may_ decide to nominate another STFC/EUDAT person for the governance board. Security for Collaboration amongst Infrastructures SCI Webinar -------------------------------------------------------------- Dave Kelsey presented in-person the webinar on SCI to TrustedCI. You can view the webinar at https://www.youtube.com/watch?v=vZvfRvMQfFg SCI: framework assessment versus formal ISO methods --------------------------------------------------- The AARC project has committed to evaluate the suitability of the "IGTF style" peer reviewed self-assessment model to compare Infrastructure policy frameworks using a community-based model ("SCI") versus the advantage of using ISO 27000 formal audits and rely purely on those between the different infrastructures. This work can build on preliminary efforts in the context of SCIv1 done in 2013, yet both SCI and the ISO methodology have evolved (with e.g. FITSM becoming continuously more prominent in EOSC-HUB). The basic methodology proposed for SCI assessment is to retain the various 'components' and assess them each independently, e.g. using the 'spider' diagrams by Urpo and inspired by the NIST SP800-63v3 vectors methodology. In particular, an assessment based on the SCI spreadsheet and methodology should be sufficient (and better attuned to!) the ISTM needs expressed at times by the EOSC-HUB project. The parameters of SCI, agreed globally between federated infrastructures for security and trust aspects, are a recognised and endorsed set that has been agreed and explicitly endorsed by all major infrastructures at TNC16 (June 2016). The AARC Policy Development Kit (PDK, see the AARC Wiki at https://wiki.geant.org/display/AARC/Policy+Development+Kit for info) will help the EOSC infrastructures to 'meet SCI' requirements in an easy way. The exact parameters of course are specific to each (research) infrastructure. "You must have a risk assessment that has determined your policy parameter choices" :) Dave Kelsey will be making the latest charts ("v4") available to the AARC team to post them on a collaborative editing spreadsheet to evolve this process. The methodology and spreadsheet evolution can then be supported by AARC, and the infrastructures such as EOSC-HUB will provide the validation (and contribute the essential bit fo actually doing it!) by using and filling the sheet and can provide the necessary feed-back. This work may be started in the November EOSC-HUB SPG meeting in Juelich. The Policy Development Kit (PDK) itself is based on Snctfi (itself an SCIv1 derivative), and some elements like software update requirements &c are not dealt with in the PDK. Yet for inter-Infrastructure trust these - where relevant - need to be able to be compared. The assessment alignment of SCIv2 also needs to be sone, which in itself is a good reason for a refreshed assessment spreadsheet. The aim will be to present a self-assessment (of EOSC-HUB, EGI, and/or the HDF Helmholtz Data Federation) during the January Geneva meeting. The scoring will be based on the (already described) 0..3 model, but some elements can be (for very good reasons) not applicable. This N/A should not influence the over-all score as presented by the Infrastructure. The peer reviewers can (orthogonal to this) use the GFD.169 A..D model to rate the specific issues found as either good enough, minor, major, and ReallyBad ... or - by themselves - not applicable. PMA operational matters, review, and accreditations --------------------------------------------------- - For the pending self audits, GridKA is now completed and accepted, MDGrid, MAGrid, and CESNET are still pending, and RDIG has presented an updated self-assessment. Thanks to Cosmin for tracking self-audit progress! - Anna (PNCN for Grid-FR) presented their operations and structure, integrating several elements of the educational PKI in France. - The ACAD.BG authority self-assessment was presented by Vladimir. During this process several omissions and inconsistencies in the "v1" assessment sheet were noted that need to be fixed in https://wiki.eugridpma.org/pub/Main/AssuranceAssessment/IGTF-CAs-Auditing_v1.xlsx For example in section 3.2. "Registration Authority", and in 3.2.1. there are 4.1, 4.2, 4.6, 4.7 which are not related to RA's duties and so on. GDPR privacy notices can in general be separate from the CP/CPS document The assigned reviewers are Ian Neilson and David Groep - Jens presented the UKeScience self-assessment, highlighting several places where guidance can be improved. E.g. one suggestion is to use CT logging (RFC6962) also for non-public trust certificates to support the immutable log requirements. The assigned reviewers are Jan Chvojka and David Groep - Eygene presented the RDIG CA self-assessment. The 'tricky' bits are mainly users that renew(rekey) their credentials after expiration when they find out after 13 months that it no longer works. There is always a proof-of-possession involved. There are some pending changes to the CP/CPS that will be implemented soon The assigned reviewers remain Anders Waananen and David Groep - Cosmin presented the RomanianGrid CA by ROSA. The assigned reviewers are Ian Neilson and David Groep. - the future of TACAR is being evaluated in the context of the larger GEANT PKI strategy and the need to host also other kind of trust anchors. This will be further dealt with in the (near) future and early 2019 - The AustrianGrid CA will wind down after the last subscribers have migrated to the TCS service in Austria. Following that the trust anchor will be withdrawn from the distribution. - the DCV TAGPMA working group has not had any further deliberations up till now. The EUGridPMA input to this group remains as-is, described in https://www.eugridpma.org/meetings/2018-05/summary-eugridpma-2018-05-karlsruhe.txt which people are invited to re-read - there is no longer obvious full coverage for BIRCH/CEDAR personal certificates in the USA. Although some users have managed to find workarounds and now use e.g. GridCanana/ComputeCanada credentials for SNO+ this may not work for collaborations that have no links outside the USA that permit proper vetting Derek and the TAGPMA will discuss this issue at their next meeting - Meanwhile, DarkMatter is considering to extend their personal certificate *retail* offering to also support the IGTF accredited personal profiles. This would for the first time open a global end-user retail offering for personal credentials that are CEDAR compliant. Contact Scott Rae for info. Attendance ---------- We would like to thank the following members for the in-person attendance: Mirvat, Vladimir, Scott, DaveK, Ian, Jana, Jan, Cosmin, Uros, Stefan, and Laurent Vivier, Anna Barcelie, and Jean-Michel from PNCN, and DavidG and for their extensive presence in the videoconference: Lidija Milosavljevic, Miroslav Dobrucky, Nuno Dias, Anders Waananen, and Jens Jensen. Thanks to Eric Yen and Derek Simmel for joining from a different time zone and presenting the APGridPMA and TAGPMA updates.