Dear EUGridPMA and IGTF members, The 29th EUGridPMA meeting is now over, and I would like to take this opportunity to again thank Cosmin, Alexandru and the ROSA team for hosting us in Bucharest and providing such excellent facilities and trust building opportunities! Consolidated minutes of the meeting 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: - IGTF All Hands, La Plata, Argentina November 6-8 - Abingdon, Oxfordshire, UK in 13-15 January 2014, followed by the SCI meeting on 15-16 January (all IGTF members are welcome at SCI as well) - Tartu, Estonia in May 2014. The exact dates depend on when the EGI TF will be. The current preference is May 13-14 (Tuesday and Wednesday), but it may move to May 27-28 in case it would clash with EGI TF - Belgrade, Serbia (tentative) September 8-10 2014 and also remember the upcoming TNC2014 in Dublin (May 19-22)! See all of you in La Plata and Abingdon! Best regards, DavidG. Subject discussed and listed below ---------------------------------- IOTA AP SHA-2 time line OCSP progress RAT Communications Challenge Resilience, redundancy and preventing HSM vendor lock-in Credential Repositories AA Operations Guideline Renewal of CA root and intermediate certificates IGTF Test Suite New CAs Auditing and compliance Miscellaneous topics IGTF All Hands IOTA AP ------- The rationale behind the IOTA AP is by now well documented in e.g. http://agenda.nikhef.nl/materialDisplay.py?contribId=8&materialId=slides&confId=2586 and presentation to the TAGPMA and the EGI TF in Mancester. This time we focussed on the relevance of the IOTA profile to European RPs and how to best assess the requirements and needs of the RPs (and to some extent also user communities) on a IOTA AP. In its current form, the IOTA AP allows the accreditation of the the InCommon 'Basic' CILogon CA, and includes all InCommon members even those that do not have firm registration processes or have their own opinion on incident response. While acceptable for XSEDE, it has not been verified that this works for the RPs in Europe yet but does open the interesting possibility for a 'blanket' acceptance of any federation in Europe, e.g. through eduGAIN. It is expected for now that IOTA accredited CAs will be backed by some form of (existing) federation. (note that there is no eduGAIN CA yet even planned!) The presentation by Vincent Ribaillier http://agenda.nikhef.nl/materialDisplay.py?contribId=7&materialId=slides&confId=2586 contains the current PRACE model, indicating that whilst a lot of data is collected by the home sites there is a significant gap between the Classic AP and IOTA that would be left open unless the registration procedures inside PRACE would be tightened. The documentation of and implementing registration policies for PRACE is foreseen but is not there yet. The incident response paragraph is very weak at the moment, and some examples of 'industry best practice' should be added. References to ISO2700, NIST SP800-63 and the relevant DIN norm have been added as examples but this is not an exhaustive list. The fact that upstream IdPs are not required to collaborate in incident response is considered worrisome. The ability to have the /possibility/ to audit upstream IdPs is important. It is supposedly part of the reference federation agreement that was drafted by GEANT, and should be imporant for any SP and federation (and is expected to be also in the UKAMS federation document which underlies SARoNGS). Without some agreement on being open to reasonable audit requests it would be hard for PRACE (and others!) to accept this profile for any valuable purpose. For selected use cases (mainly portals) in DEISA alternative authentication mechanisms have been allowed in the past (.e.g. for running the bio-informatics BLAST application), but since access to the actual resources must be well-controlled (and in some cases pre-vetted), compensatiry controls for tracability and auditability had to be implemented in the portals themselves. This was actually a non-trivial task. Unless sufficient compensatory controls are in place a IOTA credential will not be of much value. The use of pseudonyms poses different challenges: in principle there is no issue since the binding to a real user is maintained (should be maintained) by the RP or community: - 'real looking' pseudonyms are very confusing on registration - if there is (deliberate) 'spoofing' of names, innocent people can get severely implicated if their name is used - these pseudonymous IOTA common names may be hard to distinguish from fully-trusted real names in Classic, MICS and SLCS. It is suggested that IOTA names should *all* be opaque meaningless strings, e.g. ePTID, or another hash derived from the real (or pseunomymous) name. In that way it is obvious for registrars and RPs that the binding to a real name should be taken from another source. Almost all changes suggested by PRACE were implemented in the profile; the discussion on auditability of upstream IdPs and their incident response is now part of the RP questionnaire. There is no official point of view (yet) from wLCG through the GDB - also this has not been requested yet. Other important considerations include: - the IOTA AP must not include any specific provisions that are not also in Classic and MICS (to remain consistent and prevent community divergence) - all CAs present were willing (and able) to act as a communications intermediary with the subscriber in case of severe incidents, but thsi does not include release of email or other attributes, and by design will notify the subscriber that 'something' is going on. - These certificates cannot be used for email: since emailAddress must be embedded in the SAN it is visible, but the mail will be pseudonymous as well and confusing in main clients showing the commonName as the sender. - the trust chain with IOTA includes both IGTF bits and VO bits. But today, there is no software that can make validation decisions based on the combination thereof: so "VO A has good processes and thus can use IOTA on by resource, but for VO B I insist on a classic/MICS credential because their processes are not up to par". This kind of combinatorial logic cannot be expressed in software today (Argus may go someway towards it, but it gets complicated quickly). Both RPs and sites MUST consider this issue! The following list of Questions to RPs (and VOs) was drafted. This contains some purposefully provoking statement to make clear what IOTA does and does not provide (and where also the RPs might have an understading of Classic and MICS that is not fully correct). * BASIC PREMISES - Subject names must be globally unique - Subject names must be persistent (for the life time of the authority) - It’s about people and robots - Naming of IOTA subjects must be different from other profiles (no overlapping namespaces and no 'migration' between pseudonym and real person with the same full subjectDN) * REAL NAMES AND PSEUDONYMS "Do the RPs/RCs need the ‘real name’ of the person the certificate subject?" - Is it enough to be able to ask another entity to give you the name (e.g. the VO, community, other site or central LDAP)? What assurance level do you expect from this 3rd party? - Do you need this information up-front (before or at use time)? - Do you need this information at end (e.g. for accounting)? or: - It is sufficient to be able to ask an entity to contact the user on your behalf (like a privacy forwarding service)? - Should pseudonyms be clearly identifiable (e.g. if they look like a name they should be the real name)? * COMMUNNITY/VO EXPECTATIONS "Vetting assurance level and responsibility" - Given that the name may be a pseudonym and is weakly verified, do you (RP, or community) have the mechanisms in place to strongly identify the real user? - Should we enforce obfuscated naming for all subjects? - How will you (RP, VO) deal with ‘identity spoofing’? - How do you currently enrol users in the community? Do you use or rely on the commonName of the subject for adding people to your databases (or get a ‘warm fuzzy’ feeling in association with e.g. unsigned email)? "Traceability by the VO or community" - Are you set up to provide traceability for your users? - Do you have means and procedures for incident response and mitigation? * AUDITABILITY AND TRACABILITY FOR RPs AND RESOURCE CENTRES "Access to the user information by RPs" - Do you insist that the collection of this data is verifiable? - Should the chain of processes be documented? - Should the chain of processes be audited periodically (expensive!)? - Should the chain be auditable? Or contract/sanction-based? - A user may and will have many credentials and changing names: does this pose issues for you? - Do you expect e.g. the community to provide a real name up-front with every access request (e.g. in a VOMS generic attribute for those using VOMS)? Do you have software able to record that in logs? "Do the RPs (RCs) need to be able to independently trace the user without involving the user community?" - Can a registration mechanism, retrievable or callable by the RP, satisfy this requirement (e.g. like the EGEE CIC portal having an ability to send email to the 'owner' of a DN)? "Can you distinguish between VOs when deciding which user credential to accept?" "Do the RPs need to be able to trace without involving the CA?" - Which are the ‘emergency cases’ where they expect CA involvement in tracing or contacting subscribers? * INCIDENT RESPONSE "Do RPs/RCs expect the CA to be involved in incident response?" - What is an incident where you expect CA involvement? - What is the level of involvement? - Do you see a classification of incidents? - If there are up-stream IdPs, are you ‘happy’ with just the CA response even if upstream IdP does not participate? - Do you expect more than pure credential revocation in case of demonstrable credential compromise? - Do you see the CA more than a fall back to point to in case LEA comes after you? - Do you expect/prefer suspension possibilities? Do you have this capability at the RP level (through authorization)? "Can you get by with just your own response capability?" SHA-2 time line --------------- The SHA-2 deployment is progressing well: a software version including support for SHA-2 family hash functions is now available for all necessary software packages. However, for a few products (dCache, SToRM) this support is very recent (since early September) so the products are far from being universally installed. Following a request from the EGI OMB, and keeping in mind the need for a continuously operational infrastructure, the following was decided: - the issuance of SHA-2 certificates as the default is preferentailly deferred until 1 DECEMBER 2013 - large issuing authorities are strongly requested not to change their default issuance before this date - although not forbidden to shange the default, also smaller CAs are encouraged not to change - none of the EUGridPMA CAs present will change before 1 december - it is very likely this deferment is followed by APGridPMA members, and we hereby strongly encourage TAGPMA CAs to defer as well (especially those important for EGI and wLCG, such as OSG/DigiCert, GridCanada and many LA ones) - dependent deadline also hereby move +2mo: 1st February 2015 (‘sunset date’) - other milestones can remain in place (CRL hash default for instance) - CAs can wait longer before making SHA-2 the default to prevent a rush of subscriber support issues during the New Year break. Almost all CAs can now indeed issue SHA-2, for some the change is technically possible but has not been put into effect yet (TCS being one of them - we did not request this new profile yet for various reasons, but Comodo will change anyway as soon as CABforum says so. Soem others need trivial modifications to the setup (BalticGrid)). Those running multiple CA instances to support SHA-2 of course have a definite preference to return to running just a single CA ;-) *** We hereby request TAGPMA members to follow this deferment by +2mo *** OCSP progress ------------- With the increased emphasis on emergency suspension services by the RPs such as EGI, the use case for OCSP is getting stronger -- this would have revocations take effect much sooner and not wait for (1-4 times daily) CRL updates. CERN IT/IS reployed a RFC2560 'heavy-weight' OCSP responder alongside the SHA-2 CA but did not see much requests yet - probably because there are few client certs and today mainly browsers and email client use OCSP via AIA. More (grid) middleware should be enabled to check AIA and use OCSP, with the VOMS AC server itself being a particularly good candidate. There is OCSP support in common software elements: the EMI Common Authentication Library CANL, and also LCMAPS verify-proxy and thus dependent products and EGCF Globus. Given that we at one point will start using SHA-3, OCSP, and many more elements, use of common libraries should be encouraged, and we would be grateful for continued support and development of common authentication libraries like EMI CANL. RAT Communications Challenge ---------------------------- The RAT Communications Challenge (RATCC) conducted by Ursula has been very valuable is getting updated contact points for many CAs. The result summary is available in the agenda, detailed results to the PMA only. Now that contact data has been revised, a new RATCC will be sent to those CAs that did not fully make it in the first round. This will be done after the new contact addresses are in the release (so after early October and the 1.55 release) for all Red and Blue CAs. In some cases we note that person email and alternative contacts (phone) work a lot better than the public contact email list. In a very few selected cases, this contact method via the PMA chairs might become the preferred method. Resilience, redundancy and prevening HSM vendor lock-in ------------------------------------------------------- On-line IGTF accredited CAs are all using HSMs to protect their CA private key material. However, as the CAs are no longer in operation, it is increasingly problematic that these HSMs lead to vendor-lock-in, trouble with resilience planning, or very high costs (either fore spare parts or maintenance contracts). The use of (otherwise perfectly fine) HSMs for prolonged periods also results in CAs having to run old versions of operating systems to have driver support. For example, some of the UK eScience HSMs only function on RHEL3 systems with old kernels. This is worrisome, and effectively forces the CA to become an 'off-line' one (the old OS cannot be kept on-line), thus obviating the need for the HSM in the first place. Generating the key inside the HSM (as per FIPS140-2L3) also locks you into a specific vendor is the only one to provide an (encrypted) export/import mechanism. So what do we need from the HSM? Mitigation from various risks, including: - compromise of the key by having it stolen - compromise by attackers copying a software based private key - &c but it does not protect against many other risks, since in an on-line CA the key is anyway continuously activated. Key generation can also be handled by a properly documented and auditable key generation ceremony after which the key is imported ina a controlled way. The backup can then be a shared distributed backup or the key can be imported into multiple HSMs by different vendors (which is expensive). IIRC HEBCA used a documented key generation/import ceremony, probably others as well. It may be worthwhile considereeing alternative mitigations for the 140-2L3 risk level, such as the light-weight computer (like a RPi) + eToken solution Tamas presented in Rome, embedded in a physical safe. Probably the most important elemenbt is to limit the outside attack surface (just a USB stick in dangerous since many OS'es auto-run elements on it, but and an ensite system such as a RPi need minimalistic services on the network, just signing, and not even SSH &c). It should be noted that there are many CAs where a signing bend-end is used over web services (https+username+password+IP whitelist). If you can then feed it more-or-less arbitrary CSRs for signing, this setup is no better than a RPi in a safe, and probably worse. The HSMs at the back-office of the web service do not improve security in this case. it is desireable to come up with - a list of risks from which we need to protect the key - what does FIPS140-2L3 actually protect us from - what are the considerations that underpin FIPS140 (and how does any kind of alternative solution mitigate those risks)? - can we document alternative allowed methods to 140-2L3 (e.g. tokens and a RPi/Wandboard/NUC) - a shared CA issuing back-end that is highly secure but costs sharable between many front-end CAs? (that does introduce a single point of failure!) If back-ups of CA material exist, the protection thereof is as imporant as the activated key. We should remember that today CA compromise is a high-impact event even for intermediate CAs and revocation works but replacement takes a long time. Having more simple on-line CAs may also help though (e.g. quicker revocation and more timely CRL generation). People (and memory of people) are probably the largest part of this issue. In many cases the CA manager has an alternate that has sufficient knowledge to take over all operations in case of an failure of the primary CA manager (although this is unfortunately NOT true in all cases). But if there are more people that know all, you need a process for changing all secrets and passphrases in case one of them leaves. So the back-up operators and alternates should preferably be long-term staff that have no urge to switch jobs. There is (given the size of most CAs) no multi-person control, and implementing multi-person n/m control would quickly lead to undesireable delays to get sufficient people to gether for any action. And multi-person control for 'rare tasks' like recovery from backup does not make much sense as long as the primary key is under a single person's control. It may be good to consider these risks in terms of the cost involved with a compromise -- byut can this cost be quantified in our environment? A discussion on non-FIPS or non-L3 HSMs for La Plata is requested. Credential Repositories ----------------------- The new guidelines on the operation of trustworthy credential repositories (TCRs) is available, but has not seen much use yet. It is a feature which is highly appreciated by users: the CILogon service in the US which can be linked to various front-ends and completely hides certificate management for the users is frequently mentioned by, e.g. the EGI user support team. There are no obstacles to building one in Europe, but the initiative for this will mostly rest with the RPs (so EGI or each NGI could set on up), in collaboration with the CAs in case the request process goes through the TCR. Easy ways of obtaining certificates /are/ widely available through the TCS, although not all users may realise its availability (depends on the country and NREN). But also there the user today gets to manage the credential directly. There is interesting work (and thought) by EENet in Estonia on the use of mobile SIM cards, phones and NFS to manage credentials: many users are very familier with these technologies and phone hardware has additional security controls for these functions (although today many contactless smart-card are for low-value transactions, you still get good revokability as users will complain and take action when their phone is stolen). Existing software like MyProxy can also be used to setup TCRs and, as long as the user initiates, authenticates and manages the credential, it might even fit most existing CA policies and TCS eScience Personal. The IGTF Guidance is available in the form of the TCR Guidelines and the Guideline on Private Key Protection, but there are still very few TCRs planned in Europe. * We encourage EGI and the NGIs to - in collaboration with their national CAs - * study the possibility of establishing TCRs. To make TCRs better usable, the access to these TCRs should preferably be linked to existing credentials, via the existing RE federations, but the access should be well secured (so not Facebook or twitter ;-) The use of TCRs raises potential issues for email signing/contentConfirmation credentials. For example, the current split in TCS between 'personal' and 'eScience personal' is based on target audience. Maybe it's better to split this per application: one (tightly controlled) credential for document signing and content Confirmation; another for pure authentication purposes. Still two sub-CAs, but the authentication one has a clearer purpose and can have different generation/storage/escrow controls. It is not ommediately obvious how the (TCS) Personal/eScience Personal certificates are used: mainly for mail, mainly authentication/eScience or other things. Teun may know (and DG will ask). AA Operations Guideline ----------------------- It is foreseen that the usefulness and match of the guideline to current practice will be done soon, still with the wLCG VOMS servers as the initial test subject (to be confirmed with Steve Traylen by DK). Renewal of CA root and intermediate certificates ------------------------------------------------ There have been recent cases where the CA (root) certificate was renewed with a validUntil date further in the future, but the serial number was kept the same. This leads to all kinds of terrible trouble -- but the EUgridPMA Wiki on this was unclear. There is now new definitive guidance: CHANGE the serial number! http://wiki.eugridpma.org/Main/ChangingCARootCertificate 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. New CAs ------- The TSU GRENA CA from Georgia reviewers will be RobertoC and Jens (since Jens already did a quick scan of the CP/CPS), with DavidG as progress monitor. The latest CP/CPS is version 1.0.1 dated September 10th, 2013. Auditing and compliance ----------------------- The self-audit status monitoring by Kaspars has significantly improved our understanding of the process and accellerates reviews. In a few cases the original peer reviewer has left the community and a new peer has been assigned to the task. New self-audits presented in this meeting AEGIS, with regular updates from CERN and EEnet (BalticGrid CA). Please see the agenda material page for the relevant slide decks. Self-audits for January 2014 are requested from at least: UKeScience (Jens), PolishGrid (Pawel), SRCE (Emir) and LIP (Nuno). The TCS can wait till after the new contract is done. Other CAs need to reset their attendance quotum by being in Abingdon (the list is obvious from the internal pages). Consistent and long-term video attendance during full meetings also resets the attendance clock. Miscellaneous topics -------------------- - new CAs expected from the other regions: InCommon SSL Server CA (TAGPMA) and the HPCI CA in Japan (APGridPMA, replacing AIST and NAREGI CAs) - the MICS profile as agreed by the TAGPMA includes our proposed change so this is of course approved! - DG will follow up with individual CAs on the RATCC faults and attendance IGTF All Hands -------------- For the IGTF All Hands in La Plata we propose the following topics that might merit discussion: - non-FIPS140-2L3 HSMs and secured alternatives (and the risk analysis) - where will the IGTF be in 10years time? it will likely have lost the 'grid' word in the name, but still look for 'interoperable global trust' as a federation - Resiliance procedures and ROBAB-proofness of authority operations - IOTA - results of the RP questionnaire and consolidation of requirements - Trusted Credential Repository guidelines - who is willing to act as a validator for these guidelines? - Status of the AAOps guidelines - IGTF Test Suite