DutchGrid CAOperations and Practices

David GroepDutchGrid CA

Outline follows 2527

• Constituency• Organization• Types of certificates

– vetting requirements

• Re-keying• Technical controls• Auditing and trails

• Statistics• Future?

Grid in the Netherlands

BIG GRID – the Dutch e-Science Gridinfrastructure and application engangement, NBIC, NCF, NIKHEF

virtual laboratory for e-Sciencemethodologies and advanced techniques, 20 partners

ASCI Distributed ASCI Supercomputercomputer science research, DAS-2/3

NBIC BioAssistsupport and dissemination of BioInformatics tools & expertise

NIKHEF Applications (LCG and others)

ASTRON, Lofarradio astronomy and the Lofar network applications

Philips ResearchCOS groep

•Plus participation in European projects, e.g. DEISA, EGEE, HEI, …

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)

OID: 1.3.6.1.4.1.10434 (nikhef). 4 (services). 2 (CA). 2 (medium). 1 (policy). 3.0 (version)

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, …

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

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

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)

Robot certificates

• 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

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 moduleare 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.

Naming

• All names start with – ‘/O=dutchgrid/O=users’ – personal certs– ‘/O=dutchgrid/O=hosts’ – host and service certs– ‘/O=dutchgrid/O=robots’ – robot certs

needs 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

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

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

Terms and conditions pop-up

By requesting medium-security certification from the DutchGridCertification Authority (CA), you agree to abide by the CertificatePolicy and Practice Statement (CP/CPS) of aforesaid CA, and to accept all obligations and liabilities implied for end-entitycertificate 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 informthe 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 aprivate database, as specified in the CP/CPS of the DutchGrid CA.

Terms and conditions

Registration forms

Identity vetting

• Process shows initial application

• On renewal1. script generates signed

request2. goes innediately to CA3. CA generates mail to

original RA for confirmation

4. RA confirms5. CA issues rekeyed cert

• Submission interface– refuses renewal– refuses incorrect

naming, too-short key

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 name

identity 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

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 thefile "/etc/grid-security/certificates/hostcert.pem" for grid software). Makesure that the "userkey.pem" file in that directory matches this newly issuedcertificate. If this is a renewal, you may need to move the existing userkey.pem fileout 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>.------------------------------------------------------------------------

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

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?

Getting Technical

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)

Technical setup

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

Server room H1.39

• “protected environment”

•AMS-IX H1.40 •deel: FN BI15k

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]

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

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 system1. electronic log on the CA USB media2. “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 form3. geleideformulier is signed by the CA operator4. and stored in a binder, ordered by date

• Separate binder contains RA compliance forms

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

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

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

Cert Profile: CA certificate

Version: 3 (0x2)Serial Number: 0 (0x0)Signature Algorithm: sha1WithRSAEncryptionIssuer: C=NL, O=NIKHEF, CN=NIKHEF medium-security

certification authValidity Not Before: Sep 21 00:00:00 2001 GMT Not After : Feb 9 00:00:00 2021 GMTSubject: C=NL, O=NIKHEF, CN=NIKHEF medium-security

certification authSubject 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:

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

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

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 Signing 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: 56e7acf1-ae0090 X509v3 Subject Alternative Name: email:xxxxx@sara.nl

Signature Algorithm: sha1WithRSAEncryption

Statistics

• Issued 1396

• Valid 393– users 231– hosts 149– servers 13

Users by organisation

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

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•unique individuals ever issued to

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?