EUGrid PMA Status and Current Trends and some

EUGrid. PMA Status and Current Trends and some technical topics November 2013 La Plata, AR David Groep, Nikhef & EUGrid. PMA

EUGrid. PMA Topics · · · EUGrid. PMA (membership) status Risk Assessment Team IPv 6 readiness and fetch-crl · · SHA-2 time line CA readiness for SHA-2 and 2048+ bit keys · · · OCSP support documents and guidelines GFD. 125 bis Private Key Protection Guidelines v 1. 2 IGTF Test Suite On on-line CAs and FIPS 140 -2 level 3 HSMs IOTA AP and RP Questionnaire David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 2

Geographical coverage of the EUGrid. PMA · 25 of 27 EU member states (all except LU, MT) · + AM, CH, DZ, EG, HR, IL, IR, IS, JO, MA, MD, ME, MK, NO, PK, RO, RS, RU, SY, TR, UA, CERN (int), Do. EGrids(US)* + TCS (EU) Pending or in progress · David Groep – davidg@eugridpma. org ZA, SN, TN, AE, GE APGrid. PMA Taipei 2013 meeting – 3

Membership and other changes · Responsiveness challenges for some members · JUNET CA – proposed for suspension · HIAST CA – keeps running! (albeit with some connectivity issues) · Upcoming changes · More countries are moving towards TCS (IUCC, BE, …) · TCS tender – aim for start end of 2014 with selected new partner … pre-ITT market consultation on-going · New CA in Georgia (Tblisi) · Self-audit review · Kaspars Krampis as dedicated review process coordinator · Self-audits progressing on schedule for most CAs · biggest challenge in getting peer reviewers to actually review David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 4

RAT challange · Ursula Epting to conduct early June against all CAs · Timeline taking into account time zones 4 th June, Announcement of the test 18 th June, 10. 20 h, Start of the test 20 th June, 14. 50 h, Reminder for not replying CA's 21 th June, 10. 20 h, End of the test · Request for · Acknowledge receipt · for each trust anchor David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 5

Results (2) Furthermore 4 CA's replied later, after the official deadline IGTF communication test holistic view no reply final received replies > 72 h no reply until official deadline received replies <72 h time received replies <48 h received replies <24 h 0 10 20 30 40 50 60 70 80 number So in the very end 13 % did not reply at all. This comes down to 11 CA's (with 'one CA' as 'one structure') 6 08. 09. 2021 Ursula. Epting@kit. edu Steinbuch Centre for Computing

Resulting actions proposed · 24% late (longer than 24 hr), 13% non-response · Some non-response reasons clarified quickly · Incorrect email address in distribution – fixed · Already in decommissioning mode · Being located in conflict areas, at times near FEBA · For others, it correlates with known behaviour · Re-challenge non- and late-responders again · After 1. 55 distribution release fixing mail contacts · ~ December 2013 · For some require in-person self-audit remediation David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 7

IPv 6 status · FZU runs a continuous v 6 CRL monitor http: //www. particle. cz/farm/admin/IPv 6 Eu. Grid. PMACrl. Checker/ (needs to be updated with new distribution URLs) · 22 CAs offer working v 6 CRL · but there also 4 CAs that give an AAAA record but where the GET fails … · Still 72 endpoints to go (but they go in bulk) · dist. eugridpma. info can act as v 6 source-of-last-resort · fetch-crlv 3 v 3. 0. 10 has an explicit mode to forceenable IPv 6 also for older perl versions · Added option "--inet 6 glue" and "inet 6 glue" config setting to load the Net: : INET 6 Glue perl module (if it is available) to use IPv 6 connections in LWP to download CRLs David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 8

http: //www. particle. cz/farm/admin/IPv 6 Eu. Grid. PMACrl. Checker/ David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 9

UPCOMING MEETINGS David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 10

EUGrid. PMA Agenda · 30 th PMA meeting (+SCI? ) Abingdon, UK, 13 -15/16 January 2014 http: //www. eugridpma. org/meetings/2014 -01/ · 31 th PMA meeting Tartu, EE, 13 -14 May 2014 (alt: 27 -28 May) · TNC 2014: 19 -23 May 2014, Dublin, IE · 32 nd PMA meeting Belgrade, RS, 8 -10 September 2014 David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 11

SHA-2 HSMs OCSP and OGF CAOPS-WG PKP Guidelines, Test Suite, IPv 6, RAT ONGOING WORK ITEMS David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 12

Time line Status SHA-2 David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 13

SHA-2 time line minor deferment · Now · · 1 st DECEMBER 2013 · · · CAs may begin to publish SHA-2 (SHA-256 or SHA-512) CRLs at their official distribution points. 1 st February 2014 (‘sunset date’) · · New CA certificates should use SHA-2 (SHA-512) Existing intermediate CA certificates should be re-issued using SHA-2 (SHA-512) Existing root CA certificates may continue to use SHA-1 1 st October 2014 · · CAs should begin to phase out issuance of SHA-1 end entity certificates CAs should issue SHA-2 (SHA-256 or SHA-512) end entity certificates by default 1 st April 2014 · · CA certificates in the IGTF distribution and CRLs at official distribution points should use SHA-1 CAs should issue SHA-1 end entity certificates on request CAs may issue SHA-2 (SHA-256 or SHA-512) end entity certificates on request. CAs may publish SHA-2 (SHA-256 or SHA-512) CRLs at alternate distribution point URLs All issued SHA-1 end entity certificates should be expired or revoked. In case of new SHA-1 vulnerabilities, the above schedule may be revised. David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 14

SHA-2 readiness For SHA-2 there are still a few CAs not ready · a few can do either SHA-2 OR SHA-1 but not both · so they need to wait for software to be SHA-2 -ready and then change everything at once · A select few can do SHA-2 but their time line is not driven solely by us (i. e. some commercials) · Their time line is driven by the largest customer base · All can so SHA-2 (since non-grid customers do request SHA-2 -only PKIs) · it is because of these that RPs have to be ready, because when directives come from CABforum they will change, and do it irrespective of our time table! · Keep in mind hardware issues, e. g. the old Alladin e. Tokens (32 k) do not support SHA-2 David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 15

HSMs at level 3 for on-line CAs “Inspired by the idea of NIIF for buidling an on-line CA based on a low-power Raspberry Pi and a level-3 HSM in USB format, a discussion emerged on whether it is possible to have enough compensatory controls around a level-2 HSM to make the risk comparable to the current off-line CA or level-3. It is not entirely clear which elements of level-3 improve the risk resilience when compared to an off-line classic CA. ” We think it is worthwhile doing the risk analysis compared to the off-line classic CA, and if the risk is comparable allow the use of L 2 HSM or e. Tokens in conjunction with compensatory controls like a safe. We propose to discuss this with the TAGPMA and APGrid. PMA and have a discussion at the IGTF All Hands in La Plata (October 2013). David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 16

IGTF Test Suite Software developers want to do real-life testing! Actions to get to a comprehensive suite · each CA to send a URL to or a sample of endentity certs, at least personal cert and server cert, and depending on the CA also a robot cert and/or a 'service' ("blah/") cert · each CA to indicate some edge cases for their CA (use of colons, dashes, weird characters) and parameter space of the subject naming · known troublesome certs should be included · requirements developed on the Wiki · https: //wiki. eugridpma. org/Main/IGTFTest. Suite · now has some samples and conditions David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 17

IOTA AP background RP requirements Questionnaire IDENTIFIER ONLY PROFILE David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 18

New Authentication Profile · The AP is currently being drafted · https: //wiki. eugridpma. org/Main/IOTASecured. Infra. AP · Usefulness for RP is unclear, even for PRACE · Unclear how to distinguish users on resources that are part of two RP infrastructures (one with and one without IOTA) · Many things to be decided · Need for HSM FIPS 140 -2 level 3 or 2? · What audit requirements needed? · Real or pseudonymous naming · Distribution would be through separate ‘bundle’ · Next to ‘classic’, ‘mics’, ‘slcs’, and ‘experimental’ · Note there never was an ‘all’ bundle for this very reason · RPs will have to make an explicit choice to accept this David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 19

So, is the IOTA profile acceptable for PRACE ? • Yes, as long as PRACE and the joining organization can organize themselves to meet the traceability requirement : • User should never access the PRACE environment anonymously. • An execution site (site providing computing resources to PRACE users) should have an immediate access to the user details. This can be achieved with a distributed database like the PRACE LDAP. • A prerequisite would be that all partners have solid procedures to register users. • An internal meeting will be organized to define more clearly the criteria of these procedures.

This profile may be accepted by PRACE if we are convinced that for every internal registered user we have enough information to trace that user. (the next two slides quote parts form the profile which make clear why we need the above requirement) Users from other infrastructures can only be accepted if that infrastructure has the same requirement for traceability of the user and can provide us with this information if asked for (in agreed situations).

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 David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 22

IOTA Questions for RPs · 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 3 rd 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 service)? · Should pseudonyms be clearly identifiable (e. g. if they look like a name they should be the real name)? · The email use case will not work: since email. Address must be embedded in the SAN, but the mail will be pseudonymous as well David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 23

IOTA AP · Vetting assurance level and responsibility · Given that the name may be a pseudonym and is weakly verified, do you (RP, 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 common. Name of the subject for adding people to your databases (or get a ‘warm fuzzy’ feeling in association with e. g. unsigned email)? · Tracability by the VO · Are you set up to provide traceability for your users? · Do you have means and procedures for incident response and mitigation? David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 24

Auditability, traceability · 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? · 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)? · · · 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) · 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? David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 25

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 Id. Ps, are you ‘happy’ with just the CA response even if upstream 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? David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 26

Next Steps · How to approach RPs? · Interplay in mixed infrastructures · Reconciliation of PRACE and CILogon input? · Incident response · Tracability of issuance · Codification of ‘best practices’ · … David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2013 meeting – 27