Security Mechanisms

1. Security Mechanisms The European DataGrid Project Team http://www.eu-datagrid.org

2. Contents • Concepts of Cryptography • Digital Certificates • Security problems (and solution) of the Grid • EDG user authentication (practical guide) • EDG authorization (overview)

3. Security Needs • Authentication • establish the identity of an entity (user, process, host, service, ...) • Confidentiality • a third party cannot understand the communication • Integrity • data is not modified during communication • Non-repudiation • the sender cannot claim he didn’t send the data • Authorization • establish the rights of the entity

4. K1 K2 Encryption Decryption M C M Cryptography • Mathematical tool that provides some important building blocks for the implementation of a security infrastructure • Terminology • Plaintext: M • Cyphertext: C • Encryption with key K1: E K1(M) = C • Decryption with key K2: D K2(C) = M • Algorithms • Symmetric: K1 = K2 • Public Key (asymmetric): K1 ≠ K2

5. A B ciao 3$r 3$r ciao A B ciao 3$r 3$r ciao Symmetric Algoritms • The same key is used for encryption and decryption • fast • how to distribute the keys? • the number of keys is O(n2) • Examples: • DES • 3DES • Rijndael (AES) • Blowfish

6. A B ciao 3$r 3$r ciao A B ciao cy7 cy7 ciao public Public Key Algorithms • Every user has two keys: one private and one public: • it is practically impossible to derive the private key from the public one; • a message encrypted by one key can be decripted only by the other one. • No exchange of secrets is necessary • the sender cyphers using the public key of the receiver; • the receiver decripts using his private key; • the number of keys is O(n). • Examples: • Diffie-Helmann (1977) • RSA (1978) A’s keys B’s keys public private private

7. One-Way Hash Functions • Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h) • the length of h must be at least 128 bits (to avoid birthday attacks) • given M, it must be easy to calculate H(M) = h • given h, it must be difficult to calculateM = H-1(h) • given M, it must be difficult to find M’ such that H(M) = H(M’) • Examples: • SNEFRU: hash of 128 or 256 bits; • MD4/MD5: hash of 128 bits; • SHA (Standard FIPS): hash of 160 bits.

8. A ciao ciao hash (A) A’s keys B public private ciao hash (B) = ? hash (A) Digital Signature • A calculates the hash of the message and he encrypts it using his private key: the encrypted hash is the digital signature. • A sends the signed message to B. • B calculates the hash of the message and verifies it with the one received by A and decyphered with A’s pubblic key. • If the thwo hashes are equal, the message wasn’t modified and A cannot repudiate it.

9. Digital Certificates • A’s digital signature is safe if: • A’s private key is not compromised • B knows A’s public key • How can B be sure that A’s public key is really A’s public key and not someone else’s? • A third party guarantees the correspondence between public key and owner’s identity, by signing a document which contains the owner’s identity and his public key (Digital Certificate) • Both A and B must trust this third party • Two models: • X.509: hierarchical organization; • PGP: “web of trust”.

10. PGP “web of trust” D B F C E A • F knows D and E, who knows A and C, who knows A and B. • F is reasonably sure that the key from Ais really fromA.

11. X.509 Certificates • The “third party” is called Certification Authority (CA). • An X.509 Certificate contains: • identity of the owner; • time of validity; • owner’s public key; • info on the Certification Authority; • digital signature of the Certification Authority. • Certificates are published in a directory (e.g. LDAP or WWW) managed by the CA • CA’s periodically publish a list of compromised certificates • Certificate Revocation Lists (CRL) • Online Certificate Status Protocol (OCSP).

12. Per: INFN CA Firma: INFN CA Per: Verisign Firma: Verisign Per: AltraCA Firma: Verisign Per:Leo Firma:AltraCA Per:Silvia Firma:AltraCA Per:Carlo Firma:INFNCA Certificate Chains • CA’s have their own certificates, too. • A CA can guarantee for other CA’s by signing their certificates • At the top there is a self-signed certificate(root certificate). • CA certificate are widely publicized and so difficult to forge.

14. The problems of grid security • The user population is large and dynamic • the same user will have different credentials and accounts at different sites; • the same user may have a regular account at some site, while at others a dynamically assigned one • Users want to authenticate themselves to the Grid only once (single sign-on) • The resources being used may be valuable. • The data to process may be sensitive (e.g. medical data). • The set of resources required by a process may be large, dynamic, and unpredictable. • Resources may belong to different administrative domains, each with its own specific policies. • Security mechanisms must not override local policies.

15. Grid Security Infrastructure (GSI) • Based on an X.509 PKI: • every user/host/service has an X.509 certificate; • certificates are signed by trusted (by the local sites) CA’s; • every Grid transaction is mutually authenticated: • user sends his certificate; • other end sends user a challenge string; • user encodes the challenge string with his private key; • the public key is used to decode the challenge. • Private keys must be stored only in protected places, and only in encrypted form.

16. X.509 Proxy Certificate • A Proxy is a special type of X.509 certificate, signed by the normal end entity cert (or by another proxy). • It allows process to act on behalf of user, supporting single sign-on and delegation • if there is a need to have agents requesting services on behalf of the user, avoids the need to re-enter the user's pass phrase • the Subject of the proxy contains the Subject of the signing cert • It reduces exposure of user’s private key • It is created by the grid-proxy-init command • The private key of the Proxy is not encrypted: • stored in local file protected by file system security: must be readable only by the owner; • proxy lifetime is short (typically 12 h) to minimize security risks.

17. Delegation • Proxy creation can be recursive • each time a new private key and new X.509 proxy certificate, signed by the original key • Allows remote process to act on behalf of the user • Avoids sending passwords or private keys across the network • The proxy may be a “Restricted Proxy”: a proxy with a reduced set of privileges (e.g. cannot submit jobs).

18. Communication* Job Execution Single sign-on & generation of proxy cred. from The Globus Toolkit™:Security Services, http://www.globus.org/ User Proxy User Proxy credential Or: retrieval of proxy cred. from online repository Remote process creation requests* Authorize Map to local id Create process Generate credentials Authorize Map to local id Create process Generate credentials GSI interface Site A (Kerberos) GSI interface Site B (Unix) Process Process Local id Local id Restricted proxy Kerberos ticket Remote file access request* Restricted proxy GSI-enabled FTP server Site C (Kerberos) Authorize Map to local id Access file Storage system * with mutual authentication

19. Authentication/Authorization • Authentication • 16 national certification authorities+ CrossGrid CA’s • policies & procedures  mutual trust • users identified by certificates • Authorization • Based on Virtual Organizations (VO). • Management tools for VO membership lists. • 10+2 Virtual Organizations

20. EDG AA Overview • User requests a certificate from his CA [yearly] • User registers himself in the EDG LDAP-VO [once] • User generates a proxy certificate (short lifetime) [daily] • Host/service requests a certificate [yearly] • Local site retrieves the trusted CA’s certificates [periodically] and their CRL’s [daily] • Local site generates a gridmap-file from the LDAP database for authorization and mapping [daily] • User contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap-file

21. Requesting a certificate (batch) • grid-cert-requestA certificate request and private key is being created.[...]Using configuration from /usr/local/grid/globus/etc/globus-user-ssleay.confGenerating a 1024 bit RSA private key[...]A private key and a certificate request has been generatedwith the subject:/O=Grid/O=CERN/OU=cern.ch/CN=Akos Frohner[...]Your private key is stored in .../.globus/userkey.pemYour request is stored in .../.globus/usercert_request.pemPlease e-mail the certificate request to the CERN CA • cat .../.globus/usercert_request.pem | mail cern-globus-ca@cern.ch • Your certificate will be mailed to you within two working days.

22. Requesting a certificate (online) • Online procedure: • donwload your CA certificate; • fill the online request form; • wait for the identity check by the CA; • download the certificate. • Protect the certificate. • Export the certificate and make a backup copy.

23. Download the INFN CA cert 1/2 • http://security.fi.infn.it/CA/ • Click on Certificato INFN CA • ignore warning messages about connecting to an unknow site... • Click on Scarica Certificato

24. Download the INFN CA cert 2/2 • Netscape: • select all the three options • Explorer: • save with extension.der • double-click on the file name and click on Installa certificato • choose the default answer in all the following questions • Verify that the certificate is among the “root certificates” Netscape Explorer

25. Fill the online request form • http://security.fi.infn.it/CA/ • Click on Richiesta certificati • Fill the details of the owner: • Nome sezione; • Nome e Cognome; • E-mail, it must be the official one, Nome.Cognome@sezione.infn.it. • Click on Sottometti Richiesta. • After the identity checks, you’ll receive an e-mail with the instructions for the download.

26. Download the certificate • Open the URL in the mail from INFN-CA with the same browser used to submit the request • Verify that the certificate appears in the browser DB Netscape

27. Netscape Protect the certificate • Your certificate must be password protected to avoid unauthorized use

28. Netscape Export the certificate • Export the certificate (extension .p12) and save a copy on a floppy (two is better...).The copy can be imported in another browser. • Protect the copy with a good password (it will be asked during the export procedure) • Convert the certificatefor use by the globus toolkit: openssl pkcs12 -nocerts\–in user.p12 \–out ~/.globus/userkey.pem openssl pkcs12 –clcerts \ -nokeys \–out ~/.globus/usercert.pem Explorer

29. Registration • Usersmust accept the EDG usage guidelines and be registered in an EDG VO • If you don’t have your certificate in a browser: • convert the certificateopenssl pkcs12 –export \–in ~/.globus/usercert.pem \–inkey ~/.globus/userkey.pem \–out user.p12 –name ’M.Rossi’ • import your certificate in your browser • Sign the usage guidelines • open the following URLand click on “Accept”: https://marianne.in2p3.fr/cgi-bin/datagrid/register/account.pl • Ask an account from your VO administrator.

30. Starting a grid session • „login”:grid-proxy-initYour identity: /C=IT/O=INFN/CN=M.Rossi/Email=M.Rossi@infn.itEnter GRID pass phrase for this identity: *********Creating proxy ........................................ DoneYour proxy is valid until Fri Nov 29 02:44:51 2002 • the proxy is stored in /tmp/x509up_uxxx • You can now use use the grid services. • „logout”:grid-proxy-destroy

31. Proxy certificate structure • openssl x509 -text -noout -in /tmp/x509up_u504 Data: Version: 3 (0x2) Serial Number: 981 (0x3d5) Signature Algorithm: md5WithRSAEncryption Issuer: C=IT,O=INFN,CN=M.Rossi/Email=M.Rossi@infn.it Validity Not Before: Nov 28 14:14:57 2002 GMT Not After : Nov 29 02:19:57 2002 GMT Subject: C=IT,O=INFN,CN=M.Rossi/Email=M.Rossi@infn.it, CN=proxy Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (512 bit) Modulus (512 bit): ...................................... Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption ......................................

32. Authorization: the present • Based on VO LDAP servers • Each VO manages an LDAP Directory • Only groups provided, no roles • Secure web interface for EDG AUP signing • Mapping X509 credentials  user at local site • Each site periodically generates (mkgridmap) a “grid-mapfile” (mapping DN  username). • Dynamic mapping available (gridmapdir). • Mapping customizable by the local site managers.

33. o=xyz,dc=eu-datagrid, dc=org o=testbed,dc=eu-datagrid, dc=org ou=People ou=People ou=Testbed1 ou=??? CN=John Smith CN=Mario Rossi CN=John Smith Authentication Certificate Authentication Certificate Authentication Certificate CN=Franz Elmer CN=Franz Elmer mkgridmap ban list grid-mapfile local users grid-mapfile generation VODirectory “AuthorizationDirectory”

34. Authorization: the future • Virtual Organization Membership Service (VOMS) • Grants authorization data to users at VO level • Each VO has its own VOMS • Local Centre Authorization Service (LCAS) • Handles authorization requests to local fabric • Local Credential Mapping Service (LCMAPS) • Provides local credentials needed for jobs in fabric • Grid ACL (GACL) library • Provides DN based ACL’s

35. vomsd Authentication Request OK C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy AuthDB User’sattributes User’sattributes user VOMS Operations • Mutual authentication Client-Server • Client sends request to Server • Server checks correctness of request • Server sends back the required info, signed by itself • Client repeats process for other VOMS’s • Client creates a proxy certificate containing all the info received into a (non critical) extension

36. LCAS / LCMAPS • LCAS • Handles authorization requests to local fabric • Authorization decisions based on proxy user certificate and job specification • Supports gridmap-file mechanism • Plug-in framework (hooks for external authorization plug-ins) • LCMAPS • Provides local credentials needed for jobs in fabric • Accepts requests validated by LCAS • Returns, if any, local credentials already assigned to user or generates new ones. • Replaces gridmap(dir), but keeps functionality

37. EDG gatekeeper NOW EDG1.4, EDG2.x Gatekeeper Gatekeeper LCAS config TLS auth TLS auth ACL Id timeslot Yes/no LCAS (so) LCAS client gridmap LCMAPS clnt LCMAPS Id assist_gridmap config apply creds * credlist Jobmanager-* Jobmanager-* role2uid role2afs * And store in job repository By Martijn Steenbakkers (EDG WP4)

38. Further Information Grid • EDG CAs: http://marianne.in2p3.fr/datagrid/ca • EDG Security Requirements: http://edms.cern.ch/document/340234 • GGF Security Area: http://www.gridforum.org/security/ • Grid Security Infrastructure (GSI): http://www.globus.org/security/ Background • Bruce Schneier,AppliedCryptography: Protocols, Algorithms and Source Code in C, John Wiley& Sons. • Generic Security Services Application Programming Interface (GSSAPI): http://www.faqs.org/faqs/kerberos-faq/general/section-84.html • S. Tuecke et al., Internet X.509 Public Key Infrastructure Proxy Certificate Profile, draft-ietf-pkix-proxy-03.