Dear EUGridPMA and IGTF members, The 30th EUGridPMA meeting is now over, and I would like to take this opportunity to again thank Dave Kelsey and RAL/STFC for hosting us at The Coseners House in Abingdon. All the features customarily available to visitors on the banks of the River Thames were available to us, including the by now customary high water levels that accompany EUGridPMA meetings at Coseners. Regardless, we thoroughly enjoyed the excellent facilities and trust building opportunities! Consolidated minutes of the meeting and the notes kindly taken by Ursula Epting are to be provided later on, but meanwhile I would like to share with you a few of the highlights of the meeting and draw your attention to a few action items that will concern you all. Send corrections and omissions if you spot them, since these have been taken from my own scribbles and memory. Subsequent meetings will be: - Tartu, Estonia in May 2014. This will be a two-day full meeting on Wednesday 14th and Thursday 15th of May, in the week before the TERENA Networking Conference in Dublin and the EGI Community Forum in Helsinki. Piiu's slides show you how to get there and what to do! - Belgrade, Serbia (tentative) September 8-10 2014 and also remember the upcoming TNC2014 in Dublin (May 19-22), the TAGPMA meeting in Cancun, Mexico (co-located with RedCLARA) on May 26-28, and the APGridPMA and ISGC March 24-28 in Taipei, TW. See all of you in Tartu, Dublin, or ISGC! Best regards, DavidG. Subject discussed and listed below ---------------------------------- IOTA AP version 1.1 for endorsement wLCG plans and requirements in the federation era Step up authentication as a service Private Key Protection Life cycle SHA-2, OCSP and IPv6 time line RAT Communications Challenge On-line CA Architectures Guideline document AA Operations Guideline Auditing and compliance IGTF future IGTF Web Site IGTF Communications Miscellaneous topics Software sharing effort IGTF Test Suite All presentations are available on the agenda page: http://www.eugridpma.org/agenda/30 please review these as well as a complement to this brief summary! IOTA AP ------- During the IGTF All Hands meeting, the IOTA AP was discussed extensively and rough consensus reached that - with some minor changes and discussion in the PMAs - the current draft should go forward and be used to evaluate the first first IOTA CAs during accreditation. Based on the La Plata version (1.0) and the amendments proposed by the TAGPMA and during this meeting, version 1.1 was finalised. https://www.eugridpma.org/guidelines/IOTA/ The version on the Wiki pages will shortly be updates to reflect the modifications incorporated in the published version. For now, the differences between the current and previous version are highlighted in the document at http://wiki.eugridpma.org/twiki/Main/IOTASecuredInfraAP/IOTA-Secured-Infra-AP-1.1-tagpma-eugridpma-changetracking.pdf with the proposed changes by the TAGPMA in red and those by the EUGridPMA in blue. The material changes changes are: - Contact with the subscriber via a verified element in the credential itself (like an emailAddress attribute in subjectAltName) is no longer compulsory. Still, "one of these elements may be a subjectAlternativeName that contains an emailAddress that permits such contact" and additional information in the credential may be helpful to RPs. However, since RPs need to retain contact information anyway in their own systems, it need not necessarily be also in the IOTA credential - Due diligence for subscribers now uniquely refers to the Private Key Protection guidelines. It should be noted that the new PKP Guidelines are worded in a more general manner, and that the explicit requirement in case of long-lived user held soft-tokens does no longer include the explicit 12-character minimum -- this should now be evaluated during the accreditation The other changes are clarifications to the 1.0 version of the document, and the changes proposed by the TAGPMA are all accepted. Those present at the meeting (including all three RPs and prospective IOTA CAs) concurred that the current 1.1 version would be suitable for the stated purposes. It remains critical that RPs acknowledge that the information contained in IOTA credentials in itself is insufficient to trace individuals, and that any traceability and contact requirements rest with the infrastructures (or collectives of users). Mixing IOTA-capable and more loosely managed assurance levels within the same service requires distinguishing capabilities and policy evaluation on the receiving end that can take combined decisions on authentication credential strength and community membership or attribute information, and it must be noted that most software in current production use is NOT capable of making this distinction. Assurance levels must not be mixed unless a risk assessment has been done. Further background for IOTA is available in the presentations and minutes or many previous PMA and IGTF all hands meetings. As a result of the IOTA discussion, it is decided that the list of inappropriate cryptographic mechanisms (like MD5) is to be maintained centrally (not in each profile) and should be on a Wiki. The EUGridPMA Wiki will soon have an editable page for this (editing is open to all of the IGTF of course). wLCG plans and requirements in the federation era ------------------------------------------------- The wLCG pilot using federated identity management is making appreciable progress in a joint effort between CERN and SWITCH. The presentation (attached to the agenda page) by Romain and presented by Dave Kelsey contains the direction of ideas. It includes non-WebSSO access using CLI tools, although deployment limitations (like lack of SAML ECP) are to be considered. Considerations to keep in mind for the future include the high-volume use cases, where there are high-rate transaction systems for which a multiple round-trip protocol (like WebSSO with redirects) is not suitable. The future directions of the IGTF (with increased emphasis on attributes, authorization and input from RPs and user communities) should take the federated direction explicitly into account. This is further elaborated in the "IGTF in ten years" sessions in this and previous PMA/IGTF meetings. LoA step-up facilities in a AAI federation ------------------------------------------ Thijs Kinkhorst presented the 'step-up' LoA pilot currently running at SURFnet, where the assurance level can be increased to two-factor depending on the SP via th introduction of a re-authentication to a step-up bridge. The slides attached to the agenda show how that works in the (hub-and-spoke) SURF federation now. The second factor is a Yubikey, where the validation of the Yubikey token is done (for now) against the central service offered by Yubikey. The tokens themselves work no an device accepting USB keyboards (and emulates one). The step-up process itself is user friendly and integrates in the regular WebSSO flow. Moreover, the IdP do not have to change their setup since the step-up is done centrally in the federation. Initial use cases can include the authentication of Admin in the TCS portal. Private Key Protection Life cycle -------------------------------- The new Private Key Protection guidelines document was finalized. It is based on managing the complete PK life cycle using a few high-level guiding principles. The three cases (hardware protected, infrastructure protected, and user-managed soft keys) are all acceptable, even if they do represent different assurance levels. The new document is available at: http://wiki.eugridpma.org/Main/PrivateKeyProtectionLifeCycle In discussing the document, the following was noted: - the 'subscriber' is the entity communicating with the authority, which may change from tie to time (e.g. in case of server credentials it may also be a team). In case a key pair is generated on behalf of somebody else, the subscriber can also change - an encrypted private key MAY be sent over a network, provided the channel is also secure. JimB's use case of server-generated key pair is explicitly allowed! - user managed secure keys allows for centrally managed key systems, for example to host all robots in a central place. This also applies to hardware tokens all in one place (remote hosting in a trusted centre) - a key store may act on behalf of a user (e.g. a UHO generating a key pair on behalf of a user in a Directory). The subscriber will then change to the actual user later. The firm intention is that permitted private key protection scenarios allowed under version 1.0 are still permitted in this new version 2.0. The other PMAs are invited to review this document, which will shortly be formatted and released as a formal guideline and linked from the public web pages. SHA-2, OCSP and IPv6 time line ------------------------------ SHA-2 is progressing well. Several authorities have already switched to issuing SHA-2 EECs by default, including e.g. SEEGRID/HellasGrid and LIP, and there were no complaints from users. Problems that were still present in September (when DFN switched) are no longer found today. All other CAs are free to move to SHA-2 and are encouraged to do so. Subscribers explicitly requesting SHA-1 may of course be served a SHA-1 cert if so desired. The PRACE and EGI RPs have no further issues and all should be OK. A few corner cases were identified: - the (obsoleted) VOMRS software cannot support NEW registrations using a SHA-2 cert. SHA-2 based certs can be used to add to existing user entries. - sending accounting records to APEL from .gr may have failed only because the CA itself is also new and the distribution not yet updated everywhere. A Wiki will be maintained with the migration status for CAs. Each issuing CA is (supposed) to self-manage their entry in the table on the Wiki: https://wiki.eugridpma.org/Main/SHA2MigrationStatus For OCSP service availability not much has changed. There are no new CAs to support either full or light-weight OCSP yet. This was not expected anyway, since the OCSP campaign has been deferred till after the successful SHA_2 introduction. Also progress for IPv6 is slow. Only ~25% of those present have IPv6 capable CRL download end-points, and the number is not increasing. Experience in the HEPiX (HEP computing) IPv6 working group shows that there are many more problems in the production IPv6 deployment specifically for 'non-standard' services. But an HTTP web server works just fine... The EUGridPMA distribution site also serves all CRLs (it caches them hourly) and can be used in a LIMITED WAY as a CRL-source-of-last-resort for those RP sites that are IPv6 only. It is not set up to support thousands of downloaders on a 4-6 hour download cycle -- it is not a CDN. The site is and the CRLs are named "@ALIAS@.@R@.crl" in DER format. The IPv6 checker at http://www.particle.cz/farm/admin/IPv6EuGridPMACrlChecker/ is known to be outdated (it uses a very old distribution). We hope to get this fixed soon. RAT Communications Challenge ---------------------------- Those authorities that missed the previous RAT Communications Challenge or responded outside of the permitted time window will be re-challenged shortly. The updated contact information for some authorities has been release in the 1.55 distribution. The question this time will be to respond with the name of your authority -- no longer will a list of hashes be requested. This should help authorities operating a large number of CAs in a hierarchy. On-line CA Architectures Guideline document ------------------------------------------- The NIIF implementation of the on-line CA is an excellent example of an on-line CA architecture that incorporates the critical elements and is at the same time scalable and maintainable (as well as low-cost and green). The proposed NIIF model to be described in the CP/CPS is endorsed as complete and sufficient as far as the on-line CA services are involved. Please refer to the presentation of details of the setup that includes both a (lowish cost) L3 HSM token (Gemalto IDPrime v2 00 00) as well as a pair of Raspberry Pi's in a small chassis. To further protect the issuing CA, it is strongly advised to follow the standing recommendation that all on-line CAs be a subordinate of an off-line root, where the off-line root can have a long-lived (1-2+ years) CRL. After testing, it is concluded that self-revocation of a self-signed root (i.e. issuing a CRL with the serial number of the CA itself in it) is NOT effective in revoking said root. Although testing this with a single root certificate only appears to work, once that root is considered as a trust anchor in a chain, the revocation is ignored (since the Root is in the trust anchor store) for at least OpenSSL software version 1.0.1e We will draft the "On line CA Guidelines" document, based on some of the current wording in the Classic profile and appreciative of the following considerations: - Keep the network separation (models A or B, where A with a private link between RA system and signing system is preferred) - Allow import of a key pair into a token (taking it out of FIPS L3 mode) as long as there is a well-documented key generation and import ceremony - L2 HSMs may be allowed if there are compensatory controls against theft and tampering. Keeping the tokens plus their systems in a solid box (not easily taken away) and in a closed and locked cabinet in a monitored machine room should be OK - Keys are permanently activated anyway, so L3 mode (separate usage functions like generation or use) is not used for our purposes - Activation on boot should be manual (so the operator must be required to be present) The NIIF reference architecture most certainly complies (with L3 token). The architecture should protect against the very harmful leaking of private keys (there is no quick nor trivial way to withdraw a compromised root CA from the IGTF distribution) Models "A" and "B" are those from the classic profile (v4.4). AA Operations Guideline ----------------------- Based on the AA Operations Guideline (available at https://www.eugridpma.org/guidelines/aaops/) Keith Chadwick reviewed the VOMS attribute authority service at Fermi Lab. This is the very first review of its kind, and the resulting document (attached to the agenda) could well be the basis for all future reviews. The review is comprehensive and complete, and shows compliance of the Fermi Lab VOMS AA service with the Guideline. The review highlights a couple of issues: - it is easier to document the behaviour of the AASP than those of the AAs. In the review, the available documentation for AA content (semantics of attributes for instance) was only that contained in the service itself -- there is no further documentation available from the community - there is no general global equivalent of the EGI VO-ID cards that contain community information. OSG does maintain a web page with limited info - the actual max life time of the attribute assertion (as opposed to the user proxy) is a server setting on the VOMS AA server and cannot be changed by the requester beyond this max limit. - The term "AA" itself might lead to confusion with "Authentication and Authorization" in general, although the term AA is also well defined in RFC5028 - the separation of signing and service key pair proposed in the guideline is not expressed clearly enough. What was meant: the key pair used to sign assertions (e.g. the ACs for VOMS) is different from any key pair used to secure network channels (be they VOMS-Admin or the VOMS daemons). This separation requested is NOT present -- and not supported by the VOMS software yet either. The format of the reviews (a document like this one or alternatively a spreadsheet like those used for the TAGPMA operational reviews) is open for discussion. For now, the document seems a good starting point. PRACE will be evaluating the Central LDAP directory against these guidelines as well. Auditing and compliance ----------------------- Self-audits for the next meeting are requested from at least: PolishGrid (Pawel), SRCE (Emir) and BYGrid (Serge). Consistent and long-term video attendance during full meetings also resets the attendance clock. We laud those attendees who sat through the entire Abingdon meeting remotely. NorduGrid will re-key the Root of the classic NorduGrid CA with a longer key pair (4096 bits RSA) in 2014, after which the current historic root will be withdrawn. The AustrianGrid CA will move to the use of the HSM (as already described in the CP/CPS) this year. The self-audits of the CAs that presented in Abingdon will be reviewed -- there were no critical issues identified in either of MREN (peer reviewers: ChistosK & DG), LIP (reviewers: AndersW and DG), or the UKeScience CA (reviewers: Willy & Ursula). The new CP/CPS with the RPi architecture of the NIIF CA will be reviewed by Anders and Jens. The currently pending S/A peer reviews are being tracked by Kaspars and reviewers in need of reminders will get those from Kaspars or DavidG. The continuing efforts of the HIAST CA in remaining operational and issuing CRLs whenever possible are lauded and extremely well appreciated. We wish them strength in these hard times. The JUnet CA has been suspended in November 2013, and no communication has occurred since (there were no complains about being suspended). We remain interested in the state of affairs in Jordan and - dependent on the reasons that caused the suspension - will consider which procedures are applicable to lift the suspension only after we know the reasons for the current suspension. Those CAs still (for some legacy reason) issuing end-entity certificates based on 1024 bit RSA key pairs are urged to change immediately to requiring at least 2048 bit key pairs. IGTF future ----------- As the focus of the community moves, and attributes and authorization become more important, the IGTF must reposition itself to address these new challenges. The mere authentication is likely to become commonplace in the years to come, and the consolidation of the federations in the research and academic space means that there need be less emphasis on the classical CA work. Following on from the "IGTF in ten years" discussion in La Plata, it is proposed that the IGTF be no longer considered an acronym, but be treated as a word where we can associate it with a more appropriate byline. Based on an extensive discussion by those present, it was concluded that a proposal be circulated to the other PMAs with a new 'byline': IGTF: Interoperable Global Trust Federation supporting distributed IT infrastructures for research which should more accurately reflects the direction of the work of the IGTF, is both neutral with respect to the type of infrastructure (compute, data, or network), as well as to the variations in terminology between continents (e-Infrastructure vs. Cyber Infrastructure), and maintains the key elements of world-wide, trust, and federation. The new name has been tentatively added to the IGTF web site to gauge the reactions of the public and the other PMAs, but obviously the new name must be endorsed by all PMAs! *** We strongly invite the other PMAs to consider the change of IGTF from an acronym to an opaque brand, and consider the by-line and working title for approval Once this change is accepted, the charter document, update to the logo, and other elements can be updated without further ado. As part of the future of IGTF, we should encourage wider participation in the IGTF, in particular by relying parties and infrastructures, with an emphasis on those having operational (security) aspects and/or representing relying user communities. It should be expected that in the future the identity providers and authorities in the IGTF will have to provide a more operational capability in order to remain trustworthy and relevant to the RPs. There might be a role to play for 'catch-all' cases as well - given that most of the current organisations and authorities also work 'bottom-up' serving just a small number of researchers in each home organisation, but across a large number of institutions (with a few people each). IGTF Web Site -------------- The IGTF domain names have changed registrant (to Nikhef/DavidG) and registrar, and the web site has migrated to hosting at Nikhef. We can now do more creative things on the web site, some of which can be dynamic. Already some changes have been done: - added three 'boxes' highlighting the work of the IGTF: * Authentication Policy guidance - APs, HLCA and 1SCPs * Technical guidance - PKP, Robots, AAOps, GFD.125 * Services - distribution, fetch-crl3, locator, RAT contact - ensure all of the home page fits on one screen - revised the link of related organisations and repository links The web site should be further enhanced, bearing in mind - public-facing (RP, general public) function should be separated from any internal use - primary audience is RPs and 'general' public - it should include a section for 'our own' integral IGTF use with links, agenda, &c - home page must continue to fit on one screen The PROPOSAL is to do the following: - add an introduction for 'humans' - add links to interviews and (iSGTW-like) articles about the IGTF - add a 'news' box with current information (to change monthly or so). It can at lest include the latest IGTF release and link to the monthly newsletter (this can be easily automated) - Make map more prominent, click-able to PMA web site with authorities. - The mini-map should link to a PMA page with a click-able map or membership list - Text is kind-of OK - Add “About” tab with links to articles and promo - date of last change on homepage (auto-generated) - take out the byline of the logo - encourage TAGPMA and APGridPMA to maintain a list of their meeting that can be linked to For the internal site, the proposal is: - All information on there can be public access - List of all F2F meetings - With other related meeting dates (TNC, REFEDs, EGIT/UF, ISGC, OGF, ...) - Things like SHA-2 time line on both public and private - SCI link - Links to web/RAT tools and internal Wiki’s As for linking to external related organisations, the proposal is to add an 'intermediate' page first explaining the relation of the IGTF with said organisations. *** ACTION on all members is to collect interesting public articles and papers &c for use in the "About" section. Please! Also all other text is welcome, DavidG will merge all into site. *** ACTION - the IGTF name should be soon prominent on the new site. Please DISCUSS (or just ENDORSE) the new IGTF name IGTF: Interoperable Global Trust Federation supporting distributed IT infrastructures for research IGTF Communications ------------------- It has been over 10 years that the IGTF/PMA members published a citeable article about this work -- making it hard to reference it, and potentially missing out on publication opportunities. It should be notes that also OGF has of course a publication channel that can be cited, even though it lacks DOI or ISIWebofScience-like properties. The MoU or formal relationship between IGTF and OGF should be refreshed (the letters formally exist but are not that well known nor advertised explicitly). Miscellaneous topics -------------------- - running a sustained and robust operations required review of 'ROBAB' scenarios. Jens presented some of the consideration of the UKeScience CA, although in most cases a tamper evident paper copy in a safe with distributed knowledge of the activation data/pass phrase is employed for most other CAs Software sharing effort ----------------------- The use of the OGF facilities in RedMine (specifically GIT and the Wiki) should be considered. For the time being, once new text becomes available the EUGridPMA wiki at https://wiki.eugridpma.org/Main/SoftwareTechnology should be updated or expanded as well. All IGTF members have (or can get) editing credentials for this Wiki. IGTF Test Suite --------------- CAs should still attach (links to) their EECs and profiles to the test suite wiki to cover the whole range of potential IGTF certificates in the test suite. Please review the draft requirements at https://wiki.eugridpma.org/Main/IGTFTestSuite and attach links to example certs!