Dear EUGridPMA and IGTF members, The 43rd EUGridPMA meeting is now over, and I would like to take this opportunity to thank again Ingrid and Melanie for hosting us at KIT, and the generous support in terms of organising side-events, tours, and on-site audit opportunities - and much more! And thanks to Andreas for the introduction to the wide range of activities at KIT, and to the KATRIN staff for the tour. 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/2018-05/eugridpma43-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at http://www.eugridpma.org/agenda/43 More extensive notes, kindly taken by Hannah Short, will be available on the web site as well. Specific thanks goes to the AARC project and participants, who have contributed their effort and ideas and attendance, and reinvigourated the work on the AA Operations Guidelines. And whose joint session for Policy Harmonisation (Policy Development Kit, Training, and the AUP analysis) formed a great contribution to the IGTF schedule. Subsequent meetings will be: ** 44th EUGridPMA meeting, September 24-26 2018 (location to be announced - expect one in an easily-accessible location) ** 45th EUGridPMA meeting, Jan 21-23, 2019 (to be confirmed) location to be announced and of course our affiliated meetings: * TNC18 & REFEDS, Trondheim 10-14 June 2018 * PEARC18, Pittsburg 22-27 July 2018 * APGridPMA @APAN, Auckland, NZ 6-10 Aug 2018 * I2 TechEx & REFEDS, Orlando 14-18 Oct 2018 * APGridPMA, IGTF All Hands & ISGC 2019, Taipei 31 March - 5 April 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 ---------------------------------- * OpenID Connect Federation development * On the discussion whether DCV makes sense (TAGPMA) join the working group: https://groups.google.com/a/tagpma.org/d/forum/tagpma-le-dcv-loa * Policy Development Kit (jointly with AARC) * GDPR compliance and your CP/CPS * Key Distribution for RCauth.eu * Acceptable Use Policy (jointly with AARC) * Attribute Authority Operations (jointly with AARC) * PMA operational matters, reviews, new Grid-FR, RCauth.eu governance * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/43 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. OpenID Connect Federation development ------------------------------------- The developments in terms of both specification evolution as well as deployment models are ongoing, and as a result we continue to see significant changes in the way that - in the larger and more complex multi-identity-source world - the relationships will have to be shaped. This work, executed mainly in the context of the GN4 project, continues to evolve and we strongly aim to remain closely aligned with this process. It does mean that also the 'simpler' case (leveraging the AARC BPA proxy elements to hide multi-OP complexity) has a continuously evolving baseline. As an (AARC project) pilot, Mischa and Jouke at Nikhef are tracking this work and will support also the IGTF developments in this area. The issue of initial enrolment (before discovery) of OIDC clients (i.e. the systems through which users will authenticate later) may likely be addressed by specific formatting of the client-ID (which is used for registration). Mimicking the SAML concept of entityIDs (abstract URIs) and re-using them for discovery could address getting the URLs for enrolment. SWAMID, the Swedish R&E federation, is experimenting with that model. With the dynamic environment (many new clients) of the cross-infrastructure use case it will certainly be needed, yet out simplified scheme having the proxy in place will also help. To get something going soon, a practical yet simple EXAMPLE is needed. The most basic one being a single (web) service using either the MasterPortal (e.g. the component now fronting RCauth.eu as a credential management service) or CILogon as an OP in the scheme. A rather more interesting client would be WaTTS, doing dymamic registration with INDIGO IAM. Although you would have to figure out which identity sources to support, such information can be gleaned back from the OIDC federation meta-data sources. Doing this with EGI CheckIn is similarly possible. The "Fed" bit would have to be implemented, but both IAM and CheckIn are part of the WLCG pilot and this coud be a testing ground as well. Note that IAM already does the dynamic client registration (but not the OIDCFed bit). Although many policy templates are available, some concrete actions are needed in this space as well: - develop/adapt a template for OP and RP policy documents akin to RFC3647 And even if we never before in the iGTF put requirements on the RPs, this is a viable now in OIDC since both parties need something from the other, and the RPs will not 'get users' unless the OP actively sends claims to them (scopes these to the RP) - that's different from the user-held and user-initiated authN that you have with PKIX. - for RPs, pressure will also come from other compliance things like DPCoCo (GDPR) - we need to identify the _minimal_ set of policies - and these can be expressed as 'policy_uri' in the OIDCFed meta-data Contributions from the IGTF members are very welcome! Other OIDCFed notes: - An aspect not to be forgotten is training. The January EUGridPMA meeting materials as well as the summaries we gave to the APGridPMA (linked from the Karlsruhe agenda page) give at least an introduction. - The use case for registering (many) mobile clients in the federation, thought to be one of the special capabilities that OIDC fed would make possible on the relying-party side (with the hierarchical registration and signature model) is perceived as less viable now, given that fundamentally you cannot trust the platform itself for BYOD scenarios - but only in combinations with specific trusted execution environment (TEE). In the end, user-based registration may be simpler - essentially coming closer again to the original OAuth2 flow. - an 'out-of-band' profile for establishing trust is being worked on by RolandH, which may be relevant for the (initial) registration service for new organisations that is needed for the IGTF in its role as a Federation Operator (OIDC FO). - Relation to the WLCG AuthZ WG the WLCG AuthZ WG is focussing on claims (and the semantics of some of the values of those claims), and does not address the trust issue. The standardisation of claim is important and valuable, but - as we have seen before in the community contexts for both VOMS and SAML - is unlikely to extend between communities. The semantic value of roles and groups will be very much scoped to a community. So this effort is very useful, but rather orthogonal to the trust bit. On the discussion whether DCV makes sense (TAGPMA) -------------------------------------------------- Following changes in the US OpenScienceGrid (OSG) infrastructure (making it in their own words 'more agile and streamlined'), funding for the operational services was withdrawn last month, including that for the OSG Classic CA front-end interface. Although the CA itself (the issuance infrastructure operated by CILogon) remains stable and working, there is after May 31st (!) no longer a way to request and receive credentials from it. Most users can get certificates elsewhere (mainly CERN), but host and service credentials would have been less straightforward. Of course the InCommon IGTF CA (which is an IGTF classic CA which is also publicly trusted backed by Comodo) is available - either already in many US universities or for a small fee, and also the sites within the US DoE have access to the service. This is a flat-fee unlimited certificates service (like TCS in Europe). See also Derek Simmel's presentation (linked from the agenda page) for the highlevel overview and more links. * Keep in mind that since these slides were written it was confirmed that * in fact US DoE sites _do_ have access to InCommon CA services, contrary * to what is stated in these presentations. Brain Bockelman (U. Nebraska) proposed [1] to the TAGPMA to also consider Let's Encrypt ("LE" from here, and generalised to all domain-control validation-only "DCV" CAs) as a issuer of host (and service) certificates. Although this is obviously a lower assurance level than the current classic host certificates (which are at least "OV" organisation validated) OSG assessed their risk as acceptable (slide #8), taking inspiration from the "combined assurance model" that DOGWOOD user credentials in combination with community provided identity assertions provide today for some communities. Registering the resources (site registration) would then 'allows us to vet a resource prior to adding services to the production grid'. Additional elements (reactive removal from the site registration service, shorter life time, software changes to add check mechanisms for host certificates, parsing CT logs to detect abuse. * The TAGPMA has set up a working group to look at these issues, and * members from across the other PMAs are welcome to join: * https://groups.google.com/a/tagpma.org/d/forum/tagpma-le-dcv-loa * It was stressed already during the TAGPMA meeting, and re-iterated here * by the joint members, that it is a valid outcome of this working group * to say that there must not be a DCV-only profile (say, "Elm"). During the meeting, we reviewed elements of the risk assessment and looked in a bit more detail also to the LE-specific elements. Based on this discussion we identified at least the following issues: - the combined-assurance model for user certificates (DOGWOOD+community vetting assertion) works and is trustworthy because of the dual-signature approach. When used with PKIX and VOMS ACs, both elements of the trust are actually signed and shall be verified, and bith both linked to the same keypair and identifiers (DOGWOOD gives the uniqueID), checking both means that you can link the signed community assertion also to the keypair presented and thus to the session. For other technilogies that's similar (e.g. signed SAML statements, or authenticated binding to a directory of users). The equivalent for servers as proposed by OSG would imply that servers will present a PROXY (RFC3820) certificates, into which is embedded a signed statement from the community that this host actually belongs to the community. Both signatures (one from LE, one from VOMS) that have to be checked by the client. In absence of this binding, the association of the host to the community vetting process cannot be made. Note that this has to be done in-line in the (TLS) handshake, and on the client side -- and none of the software suites like Argus are today available *on that client side*. Also, doing the checks on the client side (against dual-signatures, but also against site registration databases for instance, or checking CT logs in real-time) will delay the handshake process for each connection. - binding between the LE certificate and the site can be done post-hoc only if the key is again checked, essentially duplicating all the work that the RA usually does. As a result, this checking process would all but re-create the current CA validation process if it is to provide similar assurance. It also means that you need the RA infrastructure to remain in place -- and that's actually the really costly bit in the operations. - responding to the CRL usage claim on slide #10: today all clients in the infratructures check CRLs and download CRLs frequently (usually every 6 hours, the load is O(50k) downloads per hour from the CRL web servers, typically. In security service challenges for some of the WLCG and EGI communities, we noted that emergency suspension had limited effect on the ability of a miscreant to authenticate, but inclusion in the CRL of the credential almost always fully mitigated the issue and removed the authenication capability. So CRLs work and are used (and thus allow the DN to be re-issued to the legitimate owner). That works both on the client and server end. - The technical profile of the certificates issued by LE violates the intent as stated in their CP/CPS that you should only use the certificates for server authentication. The extendedKeyUsage explicitly also asserts webClientAuth as a permissible purpose. So much for adhering to your own policies ... - LE is operated by IdenTrust. Although the 'encrypt-only' DCV certificates are free, the entire scheme does have to be sustainable, so the model is that for certificates that allow authentication (so OV or better) It is for these higher-assurance certificates that you would then have to pay, and this revenue stream can then fund the 'encrypt-only' DCV certificates. The flipside of this is that of course it would be unwise to support third-party schemes (like the OSG one) that also increase the assurance level or allow 'higher-assurance' certificates to be identified - that would impact the sustainability model. - any changes should not expose un-involved infrastructures and resources to additional risk. Mitigation measures around e.g. CAA (as in [1]) can protect a site itself against (local) people who try to get LE certificates, but it cannot prevent everyone else in the world against a site permitting LE. So that control works 'the wrong way round'. We see in practice indeed a large use of CAA, with organisations explicitly forbidding LE (yet allowing traditional CAs) to protect against unmanaged systems claiming domain ownership - which may later be reverted for specific cases on demand. The advent of LE thus already has put a burden on organsations to deploy CAA to protect themselves (but against the reverse threat as the one discussed here). - the validation model of DCV (and LE in particular) uses a single challenge for (web site) ownership, issued from a single point (the LE validation server). This leaves the validation process open to BGP hijacking attacks, which only need to last ~30 seconds to maybe a few minutes - only as long as the ACME client takes (and those time out in 30 seconds typically). BGP hijacks (which happen often, both for longer period that are registered by the RIS/Looking Glass services and RIPEstat, but also shorter ones that are only found regionally) are frequent, and can be directed against both the target machine, the target's DNS servers, or against a DCV validation server routing on its way to the client, as well as in between - and these can be regional (e.g. visible only to a few 'chosen' peers). - CT logs don't really help, since to mitigate misissuance you need to pro-actively parse all CT logs for all domains that could be involved (globally) in client connects. The risk of domain typo squatting in our infrastructure is low (since it is almost always automatically generated), but for the known domains you would need to monitor all CT logs and be able to associate each issued certificate with a valid request. That check (including check of the keypair used) again re-created what an OV CA does by default and up-front. - If we are to maintain a global authN capability (and then use AuthZ in the way intended, of course), if would mean that sites where DCV CAs are installed (e.g. because of an infrastructure-wide method) are then automatically exposes to LE unless they take active measures to prevent it. And measures in software have to be implemented and deployed before LE accidentally ends up on such a site. This is similar to the rather careful and phased way by which the combined-assurance model for users is slowly being introduced in operational infrastructures such as EGI. If not deployed (which is a safe default), then users in those sites that need to access resources that use LE will experience strange failure modes and will not have access to those resources, because they use the shared trust store on a (potentially unpredictable) compute resources. This would be a rather difficult scenario to debug. - we note that there is a big difference between 'software can do it' and 'software has been operationally deployed, configured, and verified for correct operation'. There are usually many years inbetween those two phases. - the accreditation and trust model of DCV-CAs outside our community is unclear as well. It is unlikely that a free-for-all CA like LE would invest effort in showing up to our meetings and going through the accreditation process. If and when relevant, the way how to trust entities that we do not know or control will have to be worked out And that model should - if only for fairness - than work and be applied to all DCV-only CAs. - as a general aside: keep in mind that LE and the enrolment protocol ACME are completely separate things, and you can do ACME to an OV CA just as well - with an additional secret of course as part of the protocol and finally it was noted that very cheap and reliable alternatives (like the InCommon IGTF CA) are available to all relevant sites in the US, and the effort expended by the rest of the world to discuss LE should remain commensurate to any gains that could be had from using LE in OSG. The non-involved parties, communities, and sites should not be put at risk as a result of a (maybe partially overlapping) community. We note that, at least in EMEA, the majority of the relying parties offer shared services to many communities, and these communities are not set up or prepared to also take on a role in host registration. Just like also the combined-assurance model is only applicable to a specific subset of the communities in, e.g. EGI. Most communities rely on the CAs to provide also verified name and contact/traceability data, and this will likely remain the case for a long time. The "combined assurance" model also today is very much the exception. [1] OSG CA Transition plans by Brian Bockelman - TAGPMA26, May 10, 2018 http://indico.rnp.br/getFile.py/access?contribId=19&resId=0&materialId=slides&confId=254 Policy Development Kit (AARC) ----------------------------- The Policy Development Kit is an AARC supported initiative to help user communities, proxies, and infrastructures in developming and maintaining a consistent set of policies without too much effort: https://docs.google.com/document/d/176vzNaoK6KvKTMp8Glk2n1NaM6bxiS1QqH8M3_mu7NI This document and the structure were reviewed (and edited) during the meeting. The scope today is mainly Research Communities, but the idea is to extend it to include e-Infrastructures as well. It was an answer to specific questions by the AARC communities (like EPOS). Ancillary documents are available, and those collectively make up the policy development kit PDK - which augments it with guidance on writing and deploying them (and how to read them). Since policy has to be adopted by the highest relevant level of management, it must be worded in the right way and also sent to the right people (not everyone in the community will be a 'policy geek'). For "acceptable assurance", Guideline AARC-G021 (assurance profiles for use between Infrastructures) is available, which levarages the REFEDS Cappuccino and Espresso profiles (both formally still in draft, and suggesting specific SFA/MFA profiles as well), the IGTF BIRCH and DOGWOOD APs, and - for social ID login - AARc Assam. These 5 are considered the minimal set with which the Infrastructures can work. Which one to apply of course depends on the risk profile, and having communities do risk assessment is known-difficult. It was concluded that making a 'risk assessment guidance' process would be useful, a bit like a flow chart with simple choices, taking also inspiration from some of the 'example boxes' that you now see in recent WP29 Opinions. Making that flow chart is of course all about making choices, and interviews with a few communities would be very helpful. Hints can be gleaned from the requests we already got from the operators of the LSAAI (G040) and also from the Helmholtz Data Federation use case. Then, in order to be effective, the policies should preferably come with a set of example practices that implement it. This would be a very welcome role for the e-Infrastructures to pick up. The EOSC-Hub project, as part of the 'talk to the communities' action plan, is about to send out a questionnaire on AAI solutions used to ~15-20 communities. The initial focus is on technical issues, but a specific question was already added today to also ask for a _contact point_ to talk about policies. If communities have such a contact point - which may be different from the technical AAI person - this will be extremely helpful to make the PDK known, and EOSC-Hub (and AARC as well) can help them with specific needs they have (as part of the PDK and training work there). Survey will be sent in early June, with a discussion by the end of the month. Also the FIM4R community will have policy-aware people in it. In the more diverse EOSC(hub) ecosystem, we should envison many kind of services, including services hosted by the community themselves. While for access to generic e-Infrastructure resources they will (also) be bound by the Infra policies (like a baseline AUP), similar policies will be necessary for their own services. And communities may of course have their own additional needs (such as non-reversing of pseudonymisation, or ethical requirements). But on community services themselves of course you cannot 'impose' external policies like the e-Infra ones. To progress, we can now start with a policy checklist (and a flow chart for risk assessment) to determine what is needed in a community. Then, add procedure examples as found relevant from the questionnaires. This can also include the work from CTSC on risk assessment (which in NSF grants is 'compulsory for large communities' and useful for all). However, assurance is not usually an element therein, so we need that risk assessment as a new element in the PDK flow chart. To make it work, you will likely need a 'story' to show how policies help as (managerial) controls for your services. Acceptable Use Policy --------------------- During a live editing session led by Ian, it was concluded that - we will have a layered AUP approach - a preamble must be added to the 'baseline' AUP - the 'citation' requirement really does not belong here (EGI pushed that one in their version), and if relevant is part of a community augmented version This idea was confirmed when an external org wanted to re-use the AUP, asked about copyright, and told us it was all very good, except that #2 citation did not make sense. As for privacy policies (GDPR): _every_ service must have one (also non- web services), and it is best that the _community_ on enrolment shows and then maintains a list of such policies for all the services that they offer, so that the user has a single place to go to and does not get interposition screens all the time. This is in line with AARC-G040 for the LSAAI. "You agree that use of your personal data shall be governed by the published privacy policies of the body or bodies granting you access, the infrastructure and resource/service providers." which will replace the specific list which does not quite meet GDPR requirements on purpose instead of implementation. Attribute Authority Operations ------------------------------ The AA Operations Guidelines, originally developed in the PMA to support the move to authorization policies, is proving useful in a new context for federated communities and the BPA 'proxy' scenario with community AA services (self-hosted or more often outsourced to an e-Infrastructure or operator). The original was already technology-agnostic to a large extent (supporting then also the DEISA/PRACE use case as well as issued assertions: https://www.eugridpma.org/guidelines/aaops and this document will now be evolved to support also FIM communities. Lead by Hannah, during the meeting we reviewed the concepts and terms introduced, and aligned them with standardised FIM terms from the AARC Blueprint. It will continue to evolve at https://cern.ch/go/bP6p and then be issues as an EUGridPMA Guidelines (IGTF document) supporting the Snctfi work - which is also managed by the IGTF. The same document will also be released for AARC as an AARC Guideline. Contributions to this work are welcome! GDPR compliance and your CP/CPS ------------------------------- Your "privacy notice", according to the GDPR, should always be presented separately and not be buried in a longer set of terms and conditions. So should it be in the CP/CPS or outside? And can you keep your records and for how long? First off: you will need a separate notice and present it (and ask for active confirmation that it has been read, so no pre-checked boxes) when you (first) interact with the applicant. If you allow application by email directly, you will have to inform the user at the first opportunity. But on what basis are you processing the data? As usual, the best way is to claim legitimate interest, so that you can balance your own interests against the impact on the user. Maybe the issuance itself is 'performance of contract' (6b), but then in order to maintain your own standing and trust you will have a legitimate interest in keeping your audit records - so you then claim (6f) interests for keeping the records. You must define an end-time (you did in your CP/CPS already ages ago), but that can be long, e.g. 3, 5 or i even 7 years. Depends on the requirements (at least 3 years after validity for classic) and local regulation. In principle, the privacy notice you show must be understandable. But understandable by the target audience. And there is something to be said for being very open and transparent in what you do, so why not also describe _how_ you balanced your legitimate interest? This is the (bit longish) approach the Legacy DutchGrid CA took: https://ca.dutchgrid.nl/privacy but of course if you can cast your statement in a simpler way, that is also recommended. You mght want to re-use the balancing test description, but remember that you don't _have_ to publish it unless queried. The (v2) draft GEANT Data Protection Code of Conduct is a _very_ good place to start: https://wiki.refeds.org/display/CODE/GEANT+Data+Protection+Code+of+Conduct+workshop+6+February+2018 https://geant.app.box.com/s/11rkxkqsp8d62ouq500pwbxz8n5nel9j The 14 points at least must be addressed... Key Distribution for RCauth.eu ------------------------------ The RCauth.eu CA is about to be distributed to three parties that will jointly run a HA issuance setup: STFC, GRNET, and Nikhef. For now, Nikhef has the only instance, but that is hosted (deliberately) on a low-volume HSM - and lack some of the HA features. https://docs.google.com/document/d/1cHp1xBmXKIo4H8_nFmHN9S9Vu-jslxKWXh0KYAYCydc Jens collected several options for distributing the key and setting up the new HA service. Based on feasibility, ease of use for end-users and software support, option (1) (multiple keys) was either not feasible, too cumbersome, or would upset the user base. For option 2 - doing distribution of the existing key from the copy of the ICA held after the generation ceremony in a safe - a model was devised taking inspiration from the distribution done by a bank in CZ for their key material, kindly shared by Jan. The draft proposal will be elaborated in a readable document ("option 2, unqualified" in the document above). Other options, like using LUKS containers, are likely too complex and then complexity may haunt security and trust later. And using just two independent partial channels should be sufficient for this purpose here. "In the end, all we need to transfer is a prime" PMA operational matters, review, and accreditations --------------------------------------------------- - For the pending self audits, the one for GridKa has a single open issue left, and RDIG has to submit the revised CP/CPS to the reviewers. Others are pending either updates or reviewer comments. - 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. We thank Willy - not only for the long and stable service, but even more for the great contributions to the social workings of the PMA and for showing us the hidden gems of (an extremely cold) Vienna! - MaGrid, RENAM, SRCE, and CESNET presented self-audits and/or major updates during this meeting. The reviewers for RENAM are Feyza and Cosmin, for MaGrid Walter and Ingrid, and for CESNET Emir and DavidG. - As is good practice, the encrypted private key and its passphrase must not ever be together in the same place (so not both in the same safe - if in doubt even a personal safe is better), and the backup copies distributed spatially for business continuity/disaster recovery purposes. - if you issue ECC certificates, these should be at least 256 bits matching the 2048 bits RSA equivalent. - A new trust anchor for roll-over will be added for RENAM (soon) and CESNET CA4 (once the CPS update is ready - adding identity vetting via national Qualified Certificates, i.e. Kantara LoA3 compliant) It depends on national (EU) legislation whether a private party must then accept all eIDAS credentials or can just do the national ones. A personal QC should be used only in conjunction with another form of affiliation registration if that is part of the issued EEC And as always: Jens' Soapbox is hard to summarize. Here it suffices to say that we continue to see a need to work together - there is too much complexity, and we need simpler solutions that can be shared. The larger the community, the more stable the service will be. And so, using DogTag CA with Tomcat and Java in a docker container is likely to lead to disasters. Especially if the only person who understands it then goes on a week-long holiday. If you have issues with software: change your requirements, not the software! Attendance ---------- We would like to thank the following members for the in-person attendance: Ingrid Schaeffner, Melanie Ernst, Scott Rea, Walter de Jong, Hannah Short, Dave Kelsey, Ian Neilson, Uros Stevanovic, Valentin Pocotilenco, Emir Imamagic, Reimer Karlsen-Masur, Marc Turpin, Nabil Talhaoui, and DavidG and for their extensive presence in the videoconference: Jan Chvojka, Lidija Milosavljevic, Miroslav Dobrucky, Feyza Eryol, Nuno Dias, Mischa Salle, Cosmin Nistor, and Jens Jensen. Thanks to Eric Yen and Derek Simmel for joining from a different time zone and presenting the APGridPMA and TAGPMA updates.