Скачать презентацию EUGrid PMA CAOPS-WG and IGTF Issues June 2012 Скачать презентацию EUGrid PMA CAOPS-WG and IGTF Issues June 2012

622280cce753a9685bcd6d3d95d393ba.ppt

  • Количество слайдов: 22

EUGrid. PMA CAOPS-WG and IGTF Issues June 2012 Delft, NL David Groep, Nikhef, EUGrid. EUGrid. PMA CAOPS-WG and IGTF Issues June 2012 Delft, NL David Groep, Nikhef, EUGrid. PMA, EGI and Bi. G Grid

Geographical coverage of the EUGrid. PMA · 25 of 27 EU member states (all Geographical coverage of the EUGrid. PMA · 25 of 27 EU member states (all except LU, MT) · + AM, CH, DZ, 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 – [email protected] org ZA, SN, TN, EG, AE APGrid. PMA Taipei 2012 meeting - 2

Agenda · 26 rd EUGrid. PMA meeting 10 -12 September 2012, Lyon FR · Agenda · 26 rd EUGrid. PMA meeting 10 -12 September 2012, Lyon FR · 27 rd EUGrid. PMA meeting Abu Dhabi, 14 -16 January 2013 · 28 th PMA meeting Kyiv, UA, 13 -15 May 2013 · 29 th PMA meeting Bucharest, RO, 9 -11 Sept 2013 David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 3

Karlsruhe meeting results and issues · https: //www. eugridpma. org/meetings/2012 -05/ · · · Karlsruhe meeting results and issues · https: //www. eugridpma. org/meetings/2012 -05/ · · · · SHA-2 migration AAOPS Guidelines available – to be applied now IPv 6 support OCSP RA Practice Profile RA migration to a new CA** GFD. 125 bis David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 4

Why the Risk Assessment? · hash algorithms (like SHA-x, MDx, RIPE-MD) are basis for Why the Risk Assessment? · hash algorithms (like SHA-x, MDx, RIPE-MD) are basis for cryptographic integrity of all PKI certs · SHA-1 most commonly used, but weaking rapidly · · ‘strength’ is the inherent entropy of the digest value strength is decreasing due to clever cryptanalysis good advice (NIST) has deprecated SHA-1 in 2010 more attacks are forthcoming · but moving to new hash algorithms (SHA-2) requires ubiquitous software support · which needs to be in all M/W used by IGTF RPs · but which is not (yet) there David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 5

Weighing the risks · assess the current state of the attacks on SHA-1 · Weighing the risks · assess the current state of the attacks on SHA-1 · gauge probability of successful exploit in our PKI · document possible remediations · that can be taken to preserve integrity of the IGTF · for various attack scenarios and ‘complexity levels’ · and consider the impact on our RP operations · which things may break? · how severe is a such breakage and balance these risks against each other · in an orderly fashion Risk Assessment Doc · ahead of time! David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 6

To. C for https: //www. eugridpma. org/review/sha 1 David Groep – davidg@eugridpma. org APGrid. To. C for https: //www. eugridpma. org/review/sha 1 David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 7

SHA-2 Decisions and Road Forward · ALL IGTF CAs should have or get the SHA-2 Decisions and Road Forward · ALL IGTF CAs should have or get the capability of issuing SHA 2 based certificates. All CAs MUST implement this a. s. a. p, and REPORT on the implementation of SHA-2 issuing capabilities by October 1, 2012. · This implementation of SHA-2 should encompass BOTH end-entity certs AND CRLs · CAs should schedule to start issuing SHA-2 based certs by January 1, 2013 (only if by December 2012 it is clear that everything will still break in more than one infrastructure may some CAs consider not moving). · CAs MAY consider shortening the validity period for EECs that are still SHA-1 based after 1 -1 -2013, so that the sun-set date for SHA- 1 (March 2014) is maintained. This will also encourage users to move to SHA-2. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 8

SHA-2 decisions – the user end · There should be user explanatory documents describing SHA-2 decisions – the user end · There should be user explanatory documents describing the move to SHA-2 · From Jan 2013 onwards, users SHOULD have the capability of requesting SHA-2 based certs from all CAs · Since software should accept at least SHA-256 and SHA-512 out of the SHA-2 family of hashes. To ensure that will happen, some CAs should use SHA-256 and others SHA-512, so there will and should be no IGTF guidance as to which one to choose. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 9

IPv 6 use at the CA end · All CAs should have an IPv IPv 6 use at the CA end · All CAs should have an IPv 6 capable end-point for their CRL (and OCSP responder), preferably BEFORE OCTOBER 1, 2012! · To encourage CAs to enable IPv 6 and get the proper DNS records set, monthly reminders will be sent if your CA does not offer the CRL over IPv 6 (or lacks the AAAA records). After October 1 st, these reminders will come weekly. · Get your DNS servers on IPv 6 as well · And, yes, I know the IGTF itself does not have that yet, but I’m looking into alternatives for Enom Inc. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 10

RA MIGRATION AND RPS David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2012 meeting RA MIGRATION AND RPS David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 11

RA Practices Profile · 'well organised' communities of subscribers · which are called 'RAs' RA Practices Profile · 'well organised' communities of subscribers · which are called 'RAs' in the context of e. g. Do. EGrids · could benefit significantly · from having their own well-defined 'Registration Practices Statement' (RPS) AND · keeping their own records and vetting data and gain the ability to 'outlive' their CA issuing providers and even migrate between CAs with only limited impact to the individual subscribers. · and contract issuing CAs in competition · However, this is *not* going to result in any change in the IGTF structure itself, nor in additional 'membership categories' for PMAs. It is the CAs that are anyway responsible for ensuring proper RA practices, and as such they get to defend and present RPS practices. All communication will be and remain through the CAs. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 12

RA migration: the practical use case · In this case, the community RA in RA migration: the practical use case · In this case, the community RA in NZ actually is well organised and has retained all documentation, so a migration of the entire community to the ASGCCA Catch-All function would sole the problem. The IGTF discussed the options and since · the RA has retained all documents and vetting data · the existing CA will continue to operate in a 'transitionary' mode, so there is an authentication point for the RA's subscribers · the documentation and vetting processed for the old and new CA are compatible · the RA will transfer audit capability for their documents to the new RA the users will be allowed to migrate from the old to the new CA without a new F 2 F vetting step, since the documentation remains available, and through authenticating with the 'old' credentials subscribers that reapply to the new CAs can link their new request to the original vetting data. The new CA will issue in its own name space, so the full DN of the subscribers will change. This is, however, well solvable in the VO registration systems today, and common practice. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 13

OCSP – PART II David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2012 meeting OCSP – PART II David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 14

OCSP conclusions IGTF CAs SHOULD provide production OCSP responder JAN 1, 2013 To enable OCSP conclusions IGTF CAs SHOULD provide production OCSP responder JAN 1, 2013 To enable this to happen, the following actions will be taken: · those that run OCSP responders (either the regular 'heavy' ones or the precomputer 'light-weight' OCSP responses that can be cahed and served over a CDN) will send some documentation · CABForum will (in about 3+ month) produce two whitepapers on OCSP: one for service operators and one for RP clients · All CAs should start deploying OCSP responders now, and setup a server for that · authority. Info. Access OCSP endpopint extensions should be included in all EECs issued after Jan 1, 2013 · from then on, AIA in client certs will be used, and after 400 days all EECs should have it. David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 15

OCSP conclusions · the server(s) running the OCSP responders should be highly available, and OCSP conclusions · the server(s) running the OCSP responders should be highly available, and have controls around them to make sure they are secure and safe. If you use a signing OCSP responder, it should have an OCSP signer cert which is reasonably shortlived , and preferably hosted on an HSM. · pre-computed responses should be preferred, and can be signed beforehand off the normal issuing CA directly (making them smaller and easier to process) Client will interpret the OCSP responses and do the 'right' thing (known should be equal to 'bad'). David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 16

But: what to do at the client end? Experiments by Krysztof Benedycak (quoting from But: what to do at the client end? Experiments by Krysztof Benedycak (quoting from his mail): “I did a small experiment using all OCSP responders defined in all CA certs from the IGTF distro + one from big guys, i. e. Veri. Sign. There is only few of them: http: //EVSecure-ocsp. verisign. com -> OK http: //ocsp. usertrust. com -> OK https: //ocsp. quovadisoffshore. com -> OK http: //ocsp. digicert. com -> OK http: //ocsp. cesnet-ca. cz/ -> no luck, 4 xx HTTP error https: //ca. grid. arn. dz: 2560 -> no luck, connection timeout Results: For all that I managed to query and get a positive answer I've used the same settings and get the same results, i. e. : · I've used unsigned request, however signed one was also accepted · anonymous TLS in case of https (for quo vadis) · nonce extension was not honored, never it seems that all responders create responses once per day (or so) as I always had "produced. At" several hours in the past and it was constant. ” David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 17

The current proposal by Krysztof “Solely basing on this experiment, here are defaults and The current proposal by Krysztof “Solely basing on this experiment, here are defaults and assumptions that I'm going to implement. Any comments are welcomed … 1. use in request or require response nonce? NO, not supported by servers 2. hash algorithm to be used in requests (for hashing checked cert issuer and key, not the one used for request signing) · · fixed to SHA 1 do we need to make it configurable? Are there any SHA 2 hashes required/supported? and if the answer is yes: is there any chance that admins will be able to guess a better default value for the hash? 3. server's authentication in case of https responders · · don't support this at all, i. e. use https for connection encryption only, as it would be quite hard in general (hen and egg problem) alternatively we can check the responder's SSL certificate simply, by requiring it to be the same as the certificate of the authority which signed the later received response. But does such effort makes sense? David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 18

More from Krysztof. . . 4. signing of requests --> no; seems to be More from Krysztof. . . 4. signing of requests --> no; seems to be ignored by servers 5. client's authentication to the responder in case of https --> as above 6. no other extensions are going to be supported 7. OCSP answer for a particular certificate will be cached -> by default up to 24 h -> cache time will be configurable David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 19

GFD. 125 BIS David Groep – davidg@eugridpma. org APGrid. PMA Taipei 2012 meeting - GFD. 125 BIS David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 20

Grid Certificate Profile Update · Document URL https: //forge. ogf. org/sf/go/doc 16402 · version Grid Certificate Profile Update · Document URL https: //forge. ogf. org/sf/go/doc 16402 · version 3 with track changes · One addition made based on mail from Roberto · Can we sign off on this version? · Has anyone looked at it? David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 21

Agenda · 26 rd EUGrid. PMA meeting 10 -12 September 2012, Lyon FR · Agenda · 26 rd EUGrid. PMA meeting 10 -12 September 2012, Lyon FR · 27 rd EUGrid. PMA meeting Abu Dhabi, 14 -16 January 2013 · 28 th PMA meeting Kyiv, UA, 13 -15 May 2013 · 29 th PMA meeting Bucharest, RO, 9 -11 Sept 2013 David Groep – [email protected] org APGrid. PMA Taipei 2012 meeting - 22