WP 6 Certificates for Data Grid Testbeds David

WP 6: Certificates for Data. Grid Testbeds David Kelsey CLRC/RAL, UK d. p. kelsey@rl. ac. uk 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 1

Members of WP 6 CA group • • • Luca dell Agnello INFN, Italy Roberto Alfieri INFN, Italy Jean-Luc Archimbaud CNRS, France Roberto Cecchini INFN, Italy Jorge Gomes LIP, Portugal David Groep NIKHEF, NL Denise Heagerty CERN Dave Kelsey (Chair) RAL, UK Daniel Kouril Cesnet, Czech Rep. Rafael Marco Spain Pietro Paolo Martucci CERN Andrew Sansum RAL, UK 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 2

Meetings • 4/5 December 2000, CERN • 2 March 2001, CERN • Next meeting: 5 June 2001, CERN 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 3

CA status • National CA already in operation for Data. Grid Testbed 0 – CERN – Czech Republic – France – Italy – Netherlands – Portugal – Spain – UK • Successful tests of globus job submission between CA domains • Sites not represented? 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 4

Certificates for users/hosts • All testbed users should obtain a certificate from their own national CA. • Same for host certificates • See WP 6 web page – http: //marianne. in 2 p 3. fr • Countries not yet running a CA – Implement one or – Find an existing CA willing to issue certificates • Globus certificates are still OK for Testbed 0 but should be avoided if possible – Will be removed in Testbed 1 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 5

Configuration of systems • See WP 6 web • We will provide configuration advice for globus – To configure complete list of trusted CA’s – To configure the certificate request mechanism – To maintain grid mapfile • But no automatic updates • Local site is free to accept trusted CA’s or not. – We will check CPS of each CA to define “trust” 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 6

CA Policies • CP (Certificate Policy) – Applicability of the certificate to a particular community and/or class of application • CPS (Certification Practice Statement) – Practices used in issuing certificates • INFN and NIKHEF have prepared a CP/CPS • Others working on this – To be completed by mid-April • Review of all CP and CPS by small group before Testbed 1 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 7

Minimum CP/CPS • Discussed a minimum set of requirements for a CP and CPS – Also being discussed in GGF Security WG • Registration Authority (RA) – An acceptable procedure for confirming the identity of the requestor and the right to ask for a certificate – The RA should be the appropriate person to make decisions on the right to ask for a certificate and must follow the CP – requests for machine certificates must be signed by personal certificates or verified by other appropriate means • Communication between RA and CA – Either by signed e-mail or some other acceptable method 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 8

Minimum CPS (2) • Certification Authority (CA) – The issuing machine must be: • • a dedicated machine located in a secure environment Not connected to any network be managed in an appropriately secure way by a trained person – the CA private key (and copies) • should be locked in a safe or other secure place • must be encrypted with a pass phrase having at least 15 characters • the pass phrase must only be known by the Certificate issuer(s) 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 9

Minimum CPS (3) • minimum length of user private keys must be 1024 • min length of CA private key must be 2048 • lifetime of personal certificates should be no longer than one year. • question: how many farm nodes will require host certs? And how long should these certs live? • Revocation – see later • Users must generate their own private key and must keep this private and secure • Publishing of user public keys is not required. 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 10

Minimum CPS (4) • Recording - audit trail – RAs must record and archive • all requests • all confirmations – CAs must record and archive • • • 8 -Mar-01 all requests for certs all issued certs all requests for revocation all issued CRLs login/logout/reboot of the issuing machine D. P. Kelsey, Certificates, WP 6, Amsterdam 11

Naming • To date, different choices have been made – No proof of uniqueness • Longer term, do we want a hierarchical namespace? (o=hep? ) • Coordination with Info services LDAP namespace? • This needs further study 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 12

Revocation • • lost or compromised private key person left organisation Can be requested by either the user or the RA Every CA must generate and maintain a CRL – The lifetime of the CRL should be no more than 30 days. – This must be updated immediately after every revocation and at least before the expiry of the lifetime. • All clients must update their local copies of CRL's at least once per day. 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 13

General Security group • PTB asked me to join the ATF for security – See my talk on Friday 9 th March – I propose to create a general security group • WP 6 security reps plus reps from other WP’s plus … • How do we handle authorisation in Data. Grid? • Strong recommendation not to mix authentication and authorisation – Industry trends • PMI (privilege management infrastructure) – X. 509 V 3 extension fields should only carry authorisation information that is stable and constant over time – “Attribute Certificates” – PKIX IETF working group – CAS from Globus looks very interesting 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 14

Future Plans • Complete WP 6 web pages with CA details and configuration advice (by Easter) • CA’s to complete CP and CPS (by Easter) • Small group to review all CP/CPS (before Testbed 1) • More work under the general security group – Authorisation – Mapfiles – etc 8 -Mar-01 D. P. Kelsey, Certificates, WP 6, Amsterdam 15