DutchGrid CA Operations and Practices

1. DutchGrid CAOperations and Practices David Groep DutchGrid CA

2. Outline follows 2527 • Constituency • Organization • Types of certificates • vetting requirements • Re-keying • Technical controls • Auditing and trails • Statistics • Future?

3. Grid in the Netherlands BIG GRID – the Dutch e-Science Gridinfrastructure and application engangement, NBIC, NCF, NIKHEF Not a comprehensive list virtual laboratory for e-Sciencemethodologies and advanced techniques, 20 partners Plus participation in European projects, e.g. DEISA, EGEE, HEI, … NBIC BioAssistsupport and dissemination of BioInformatics tools & expertise NIKHEF Applications (LCG and others) ASTRON, Lofarradio astronomy and the Lofar network applications Philips ResearchCOS groep ASCI Distributed ASCI Supercomputercomputer science research, DAS-2/3

4. General Provisions • Constituency: a closed community • all organisations based in (or with offices in) the Netherlands that • are research or education organisations (or research depts of other organisations), • and are involved in research or deployment of multi-domain ICT infrastructures intended for resource sharing • all entities that are part of the DutchGrid Platform • all entities on the Science Park Amsterdam(clause to cover NIKHEF itself) • with non-discriminatory service • but no service to consumers (be it as EE or RP) New in 3.0 OID: 1.3.6.1.4.1.10434 (nikhef). 4 (services). 2 (CA). 2 (medium). 1 (policy). 3.0 (version)

5. CA Organisation • Independent organisation • a function of the DutchGrid Platform, a volunteer collective of organisations involved in Grid computing in the Netherlands • hosted and supported by NIKHEF/PDP • with funding from different sources:VL-e, BioAssist, NL-Grid/NCF, …

6. CA Operators • three people can operate the CA (i.e. know the pass phrase for the CA private key and pin to the safe)** • they can act alone (so control in 1-out-of-3) • with 3 people, and some careful planning, we can get full coverage during working hours (even over holiday periods) ** [13] passphrase is not written down but remembered by the operators – when revieweing noted we lack a paper copy in a separate location

7. Registration Authorities • Aad van der Steen, Universiteit Utrecht, Utrecht • Angela Luijf, AMC Amsterdam • David Groep, NIKHEF, Amsterdam (Central RA) • Dick Epema, TU Delft, Delft • Djuhaeri Harapan, NIKHEF, Amsterdam (Central RA) • Frank B. Brokken, RC-RUG, Groningen • Hans Blom, Netherlight, Amsterdam (for Netherlight hosts only) • Hans Zandbelt, Telematica Instituut, Enschede • John Romein, ASTRON, Dwingelo • John van de Vegte, KNMI, De Bilt • Kees Verstoep, VU, Amsterdam • Lex Wolters, LIACS, Leiden • Marco Konijnenburg, AMOLF, Amsterdam • Maurice Bouwhuis, SARA, Amsterdam (Roving RA) • Piter de Boer, IvI/UvA, Amsterdam • Breanndan O Nuallain, IvI/UvA, Amsterdam • Robert Belleman, IvI/UvA, Amsterdam • Ronald van Driel, PHICOS, Philips Research, Eindhoven • Ron Trompert, SARA, Amsterdam • Jules Wolfrat, SARA, Amsterdam • Rutger Kramer, DANS/KNAW, Den Haag • Salim Ansari, ESA/ESTEC, Noordwijk • Theo van der Krift, UU Cell Biology Group, Utrecht • Wouter den Otter, TNW/TU Twente, Enschede since 2006

8. Certificate classes • Personal • issued to individuals • must be protected by a passphrase • may be on a token • may optionally have email • … and objectSigning* • Host/service • issued to administrators/contacts for hosts • must be protected with OS permissions • has DNS SAN, but no objectSigning • Server • same as for host/service • not recognised for grid use (only NIKHEF/SARA internal, e.g. for CA operations and the CA web site) New in 3.0

9. Robot certificates New in 3.0 • Robot certificates • issued to individuals for automated tasks • must be stored on a token(token password, if required, may be protected by OS permissions only) • CN starts with “Robot: ” • issued by qualified RAs only • only the Central RA Service and the Roving RA currently support this

10. Robot token clause 6.2.1 • Secure hardware tokens, whenever referenced in this document, are those hardware security cryptographic devices or hardware security modules that operate on and hold asymmetric cryptographic key pairs in such a way that • the private part of the key pair cannot ever be extracted in unencrypted form, • can only be unencrypted inside the device, • and the encrypted form, if available, uses 128 bit symmetric key encryption or equivalent or stronger, and where the key pair has been generated inside the cryptographic device. • Any tampering, any substitution or extraction of keys, and any unauthorized modification of the activation data, must leave evidence on the secure hardware token. • Secure hardware tokens and hardware security modules that comply with the requirements of FIPS 140-1 level 2 or higher, or FIPS 140-2 level 2 or higher, • and where the key pair has been generated inside the module are adequate to meet the requirements set forth above. • If not FIPS certified, implementation of an equivalent security level and appropriate mechanisms on the token must be demonstrated: the vendor must have built the device with the intention of obtaining FIPS 140-2 certification at level 2 or higher, and must either intend to submit the device for certification, or have it in process of certification.

11. Naming • All names start with • ‘/O=dutchgrid/O=users’ – personal certs • ‘/O=dutchgrid/O=hosts’ – host and service certs • ‘/O=dutchgrid/O=robots’ – robot certsneeds change in signing policy! • ‘/O=dutchgrid/O=servers’ – servers, non-grid use • Limited allowed character set to protect applicants against themselves • Organisation and O.Unit only designate initial RA New in 3.0 New in 3.0 New in 3.0

12. Vetting Process • Unified process • no difference between personal, host/service, or server certificate(robots are different, since RA needs to be present at generation time) • all based on paper forms and a request digest • allows for many ‘process-oriented’ RAs

13. Scripts • Applicant ‘builds’ the script and paper application form via the web interface • download ‘customized’ script with DN embedded • script will generate email or text file for upload • The script prints a digest of the key pair • applicant write this digest on the form • used by the CA to match paper request and CSR • RA verifies that this digest is written, by the applicant him/herself before counter-signing the form

14. Terms and conditions pop-up By requesting medium-security certification from the DutchGrid Certification Authority (CA), you agree to abide by the Certificate Policy and Practice Statement (CP/CPS) of aforesaid CA, and to accept all obligations and liabilities implied for end-entity certificate holders and subscribers mentioned therein. You must select a passphrase at least 12 characters, including non-alphanumerics, to protect by private key, and you must inform the CA or my Registration Authority promptly in case of actual or suspected compromise of your private key. By requesting a certificate, you also agree that your certificate (which includes your subject identifier shown above) will be published on a web site, and that the CA will record all other data provided in a private database, as specified in the CP/CPS of the DutchGrid CA.

15. Terms and conditions

16. Registration forms

18. Identity vetting • Process shows initial application • On renewal • script generates signed request • goes innediately to CA • CA generates mail to original RA for confirmation • RA confirms • CA issues rekeyed cert • Submission interface • refuses renewal • refuses incorrect naming, too-short key was in effect since 2003 3.0 now describes this correctly

19. Express mode • In case a certificate is needed right now • User follows generation procedure, goes to RA • RA retains possession of the vetting forms • contacts CA Operations by reasonably secure means (e.g. signed email) • provides applicant PoP and subject nameidentity document type and number • CA Operations approves request and issues cert • RA (and not the applicant!) sends the forms to the CA by fax or postal mail within a few days

20. EE email Dear David Groep (davidg@nikhef.nl): This mail contains your newly issued host or service certificate. Copy this entire mail to the certificate directory (usually this will be the file "/etc/grid-security/certificates/hostcert.pem" for grid software). Make sure that the "userkey.pem" file in that directory matches this newly issued certificate. If this is a renewal, you may need to move the existing userkey.pem file out of the way and rename "newkey.pem" to "userkey.pem". There is no need to extract parts of this e-mail, and you can just save this entire message. And if you have any problems please mail for help. … * You can always download your certificate again from this URL: http://www.dutchgrid.nl/ca/medium/details/newcerts/056E.pem * REKEY your certificate in time, it will expire in one year. * in case your private key is lost or compromised, please notify the CA immediately: by phone at +31 20 592 2179 or by e-mail <ca@dutchgrid.nl> Legal notice: By accepting this certificate, you re-confirm your acceptance of the DutchGrid/NIKHEF CA Certificate Policy and Certificate Practice Statement, including the stipulations made therein regarding the registration of your personal data in an automated registration system and the publication of such data in a world-wide accessible repository. If you want to correct, complete, remove or protect your entry in the automated repository, as meant by the Dutch Personal Data Protection Act (Wet bescherming persoonsgegevens) 2000, contact the NIKHEF CA at <ca@nikhef.nl>. ------------------------------------------------------------------------

21. Routine re-keying • New CSR electronically signed with old key pair • base64 super-encoded to withstand mailers that mangle MS-DOS and MacOS style line endings • Submit the re-keying blob to the CA (email, web) • if signature is invalid, may be processed as a new request if applicant asks to • submission interface checks for ‘originality’ of the key pair to prevent renewals • CA sends a request for confirmation to the RA • RA must answer positively that subscriber is still OK • a unique token is used to link the email to the application • CA issues re-keyed request

22. Revocation • Will handle with priority, of course • but there are not that many … • are the users too lax, though we tell them to warn us? • is the process so complex that subscribers are careful?

23. Getting Technical

24. Systems and repositories • Public Repository (ca.dutchgrid.nl) • all issued certificates, CA cert, CRL, docs • CA Operations & Protected repository(ra.dutchgrid.nl) • limited audit trail • request, ID doc type and number, transaction history • retains all incoming requests • CA operations interface (approve/discard) • CA Operations transfer systems • used to retrieve zip files from op interface and put them on USB • on the NIKHEF managed LAN* • only the desktop/laptop systems of the CA operators are used • Off-line signing system • log of all startup, issuance, CRL generation, revocation &c • on signing lists cert serials issued, which are written down on … • … transaction paper log which is kept and stapled to the vetting forms • Backup services • non-dedicated host for on-line backups (pull) • non-dedicated off-site dual-copy near-line backup (Tivoli) (pull)

25. Technical setup

26. Environment • Server room • access restricted to NIKHEF ICT staff • access-key history kept • room contains paper archive, safe, cabinets with the on-line and off-line systems • approx. 20 people have access to the room(and I know them all , they’re fine) • but the CA keys are in a dedicated safe inside this room, where only 3 people can get to it • but then each of then can operate alone … Server room colocated with our AMS-IX housing activities: - 620 kVA no-break/300s, 1320 kVA short-break, 24x7 guard on site - located on the first floor, above sea level

27. Server room H1.39 • “protected environment” deel: FN BI15k AMS-IX H1.40

28. Safe box • Simple box from a DIY store  • pin controlled access • pin known to CA operators only (3 people) • bolted to the cabinet • entire safe can be stolen of course, … … but at least … … that’s quite noticeable … also contains the old hard rive of the previous off-line CA system [12]

29. Off-line system • Booted from Knoppix CD-ROM • Knoppix image is constant, and checked against different web sites • All CA software is on the USB stick(initialisation is via a ‘. /mnt/auto/sdb1/setup medium’ command) • Machine is not connected to any network • Machine has no hard disk anymore

30. Audit logs and vetting papers • Paper based audit trail • during a certification session • is a log of all issued certs [14] • For every signing action on the off-line CA system • electronic log on the CA USB media • “geleideformulier” with the list of certificates to issue • stapled to the vetting forms for new applications • re-keyings only have the entry on the accompanying singing form • geleideformulier is signed by the CA operator • and stored in a binder, ordered by date • Separate binder contains RA compliance forms

31. On-line CA operations system • Connected to a “grid CA service” network • Dedicated LAN cabling • In controlled environment • but still awaiting installation in dedicated rack … • hosts the limited on-line audit trail • HW: SuperMicro box, single Xeon 2.8 GHz, 512 MB mem, RAID-1 disk, 100Mb interface

32. Operations Interface • List of pending requests • Send warnings • Package & publish via USB • Discard, search, and bulk-approve • Comment/revoke • Automatically see all previous vetting data for a DN

33. On-line CA web site • Connected to a “grid CA service” network • Dedicated LAN cabling • In controlled environment • but still awaiting installation in dedicated rack … • HW: SuperMicro box, single Xeon 2.8 GHz, 512 MB mem, RAID-1 disk, 100Mb interface

34. Cert Profile: CA certificate Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, O=NIKHEF, CN=NIKHEF medium-security certification auth Validity Not Before: Sep 21 00:00:00 2001 GMT Not After : Feb 9 00:00:00 2021 GMT Subject: C=NL, O=NIKHEF, CN=NIKHEF medium-security certification auth Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a3:dc:c0:e5:91:32:75:cb:30:2a:00:5d:e1:9c:

35. Cert Profile: CA certificate X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 Subject Alternative Name: email:ca@dutchgrid.nl X509v3 Subject Key Identifier: 5B:05:3A:99:C6:D5:22:BD:FD:94:80:FC:11:A8:D0:F1:71:D6:4B:A4 X509v3 CRL Distribution Points: URI:http://ca.dutchgrid.nl/medium/cacrl.pem Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA Netscape CA Revocation Url: http://ca.dutchgrid.nl/medium/cacrl.pem Netscape CA Policy Url: http://ca.dutchgrid.nl/medium/policy/ Netscape Comment: DutchGrid and NIKHEF medium-security Certification Authority; policies at http://ca.dutchgrid.nl/medium/policy/ Signature Algorithm: sha1WithRSAEncryption [21] nsCertType still therealso for EE certs

36. Cert Profile: EE cert host/service Serial Number: 1390 (0x56e) Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, O=NIKHEF, CN=NIKHEF medium-security certification auth Subject: O=dutchgrid, O=hosts, OU=nikhef.nl, CN=hooibaal.nikhef.nl Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://ca.dutchgrid.nl/medium/cacrl.pem X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.10434.4.2.2.1.3.0 X509v3 Authority Key Identifier: keyid:5B:05:3A:99:C6:D5:22:BD:FD:94:80:FC:11:A8:D0:F1:71:D6:4B:A4 DirName:/C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth serial:00 X509v3 Subject Key Identifier: 8B:3A:CD:F3:0B:32:AD:5F:8C:4C:02:59:35:44:49:B5:27:02:31:32 Netscape Cert Type: SSL Client, SSL Server, S/MIME Netscape CA Policy Url: http://ca.dutchgrid.nl/medium/policy/ Netscape Comment: EEC issued under Policy version 3.0 - limited liabilities apply, see http://ca.dutchgrid.nl/medium/policy/ - Certificate Tag: 86d901d5-ba1b7a X509v3 Subject Alternative Name: DNS:hooibaal.nikhef.nl Signature Algorithm: sha1WithRSAEncryption

37. Cert Profile: EE Personal + objSigning Version: 3 (0x2) Serial Number: 1389 (0x56d)Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, O=NIKHEF, CN=NIKHEF medium-security certification auth Validity Not Before: May 21 00:00:00 2007 GMT Not After : May 20 16:12:12 2008 GMT Subject: O=dutchgrid, O=users, O=sara, CN=XXXX XXXXXXX Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://ca.dutchgrid.nl/medium/cacrl.pem X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.10434.4.2.2.1.3.0 X509v3 Authority Key Identifier: keyid:5B:05:3A:99:C6:D5:22:BD:FD:94:80:FC:11:A8:D0:F1:71:D6:4B:A4 DirName:/C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth serial:00 X509v3 Subject Key Identifier: 34:F9:CF:45:49:C0:0D:46:EE:03:AF:D1:90:A3:3F:55:68:87:93:B8 Netscape Cert Type: SSL Client, SSL Server, S/MIME, Object SigningNetscape CA Policy Url: http://ca.dutchgrid.nl/medium/policy/ Netscape Comment: EEC issued under Policy version 3.0 - limited liabilities apply, see http://ca.dutchgrid.nl/medium/policy/ - Certificate Tag: 56e7acf1-ae0090 X509v3 Subject Alternative Name: email:xxxxx@sara.nl Signature Algorithm: sha1WithRSAEncryption

38. Statistics • Issued 1396 • Valid 393 • users 231 • hosts 149 • servers 13

39. Users by organisation 102 uva 70 nikhef 35 sara 29 vu 25 universiteit-utrecht 17 philips-natlab 16 rug 14 tudelft 8 cmbi 7 wageningen-universiteit 7 lumc 6 logicacmg 6 amolf 5 universiteit-twente 5 radboud-universiteit 5 liacs 4 tno-nitg 4 dutchspace 4 dans 4 astron 3 telin 3 knmi 3 esa-estec 2 universiteit-leiden 2 unilever-research 2 feico 1 surfnet 1 sron 1 rul 1 jive 1 cosine unique individuals ever issued to

40. From here • next will be the SURFfederation backed CA • integration of a SLCS/MICS with A-select • has been in the works for ~20 months now… • but hampered by lack of time of key people(both on the DutchGrid/NIKHEF side and the SURFnet side…) • both SURFnet and BIG GRID have written this in their 2007/2008 plans • money is there (virtually), so we ‘just’ need to do it • but can we finally find the time?