Security considerations

1. Security considerations In Large Scale Computing Infrastructures Andres Aeschlimann Andres.aeschlimann@switch.ch Zurich, 26.10.2011

2. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary Special thanks to Ake Edlund (KTH), Heinz Stockinger (SIB) and Christoph Witzig (SWITCH) for re-using some of their slides

3. Introduction • Starting point: • Distributed infrastructure • Problem: • How do you manage users? • Solution: Authentication and Authorization Infrastructure (AAI) • Definition of authentication and authorization • Authentication: Process of ensuring a credential is valid and belongs to the individual that presents it. • Authorization:Process of checking that a person has the rights to perform an operation. Authorization can be issued based on several criteria, such as, for example, • the identity of the person or • attributes provided about the person by a trusted third party.

4. AAI: Authentication and Authorization Infrastructure AAI solve the old problem of access control to resources There are various technologies in use - their usefulness depends on the underlying infrastructure Crusader Castle League of Nations Federated Identity

5. Crusader Castle • Appropriate for few, non-mobile users

6. Crusader Castle • Tedious user registration at all resources • Unreliable and outdated user data at resources • Different login processes • Many different passwords • Many resources not protected due to difficulties • Often IP-based authorization • Costly implementation of inter-institutional access University A Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

7. League of Nations Standardized Credentials (International Conference on Passports 1920) University A X.509 credentials Student Admin • User registration process with CA • User has one credential to present to resources • authN and authZ at resource • User has to manage credential • Standard use in grids (IGTF) • Delegation mechanism Web Mail e-Learning Passport Issuer (CA) University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

8. Federated Identity Management • No user registration and user data maintenance at resource needed • Single login process for the users • Many new resources available for the users • Enlarged user communities for resources • Efficient implementation of inter-institutional access University A Federated Identity Management Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

9. Federated Identity Management • Shibboleth • open source • internet2 • SAML • Web-based Single Sign-on • authN at Identity Provider • authZ at Service Provider • based on user’s attributes • as provided by IdP • Privacy University A Federated Identity Management Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Credentials

10. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary

11. Core Problem of Grid Security The purpose of the Grid is to enable “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations across administrative domains.” Adapted from The Anatomy of the Grid • So Grid Security is security to enable VOs • What is needed in terms of security for a VO?

12. V i r t u a l C o m m u n i t y C P e r s o n E ( R e s e a r c h e r ) P e r s o n B F i l e s e r v e r F 1 ( A d m i n i s t r a t o r ) ( d i s k A ) C o m p u t e S e r v e r C 1 ' P e r s o n A P e r s o n D ( P r i n c i p a l I n v e s t i g a t o r ) ( R e s e a r c h e r ) P e r s o n B P e r s o n E ( S t a f f ) F i l e s e r v e r F 1 P e r s o n D ( F a c u l t y ) ( d i s k s A a n d B ) C o m p u t e S e r v e r C 2 C o m p u t e S e r v e r C 1 ( S t a f f ) P e r s o n A P e r s o n F ( F a c u l t y ) ( F a c u l t y ) P e r s o n C C o m p u t e S e r v e r C 3 ( S t u d e n t ) O r g a n i z a t i o n A O r g a n i z a t i o n B Virtual vs. Institutional Organization

13. Virtual Organizations (VO’s) • “A VO is a group of researchers with similar interests and requirements, who are able to work collaboratively with other members and/or share resources (e.g. data, software, expertise, CPU, storage space) regardless of geographical location.” • Grid Users always act as members of a VO • VO may also add information, eg. to proxies • Group memberships • Roles • De-facto Standard: VOMS • Virtual organization membership service • One VOMS instance per VO

14. Essentials on Grid Security • Access to shared services • cross-domain authentication, authorization, accounting, billing • Support multi-user collaboration • organized in one or more ‘Virtual Organisations’ • may contain individuals acting alone – their home organization administration need not necessarily know about all activities • Leave resource owner always in control

15. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary

16. Security fundamentals &#/€(?%... Privacy - only invited to understand conversation (use encryption) abc.. abc.. Bob Alice &#/€(?%... ? Privacy - A secure conversation should be private. In other words, only the sender and the receiver should be able to understand the conversation. If someone eavesdrops on the communication, the eavesdropper should be unable to make any sense out of it. (This is generally achieved by encryption/decryption algorithms.)

17. Security fundamentals &#/€(?%... Privacy - only invited to understand conversation (use encryption) abc.. abc.. Alice Bob Private key Private key &#/€(?%... ? Public key Public key Bob’s Public key Alice Public key Privacy - A secure conversation should be private. In other words, only the sender and the receiver should be able to understand the conversation. If someone eavesdrops on the communication, the eavesdropper should be unable to make any sense out of it. (This is generally achieved by encryption/decryption algorithms.)

18. Security Fundamentals • Encryption: • Alice uses Bob’s public key to encrypt the message Bob uses Bob’s private key to decrypt the message • Effect: only Bob can read it • Signing: • Alice uses Alice’s private key to encrypt the message Bob uses Alice’s public key to decrypt the message • Effect: Bob knows that Alice has sent the message

19. Security Fundamentals • Question: • Do the keys of Alice and Bob have to be the same? • Answer: Both are possible • Symmetric cryptography: same key • Asymmetric cryptography: different keys

20. Security Fundamentals • Problem: management of other people’s public keys • Solution: give them a name, e.g. • Bob’s public key = “public key of Bob Jones from IT department of CERN in Geneva, Switzerland” • X.509 certificate := public key plus a name (and a few other things) • Problem: • How do you know that this is really Bob’s public key? • Answer: someone you trust must tell you that this is indeed the case! • Certificate Authority: CA

21. CA CA - Certification Authority • The role of the CA is manage the certificate life cycle: create, store, renew, revoke TrustedThird Party Alice? Yes! Bob? Yes! Bob Alice &#/€(?%... Alice Bob

22. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary

23. How do I get a certificate? • Create a key pair (using some algorithm) • Send the public key to a Certificate Authority • CA must obtain also personal information • CA must perform an identity vetting • CA issues certificate with a given lifetime • Note: • CA may revoke your certificate (in case of abuse) • Certificate must be renewed once it expires • and ???? • YOU MUST PROTECT YOUR PRIVATE KEY

24. X.509 alias ISO/IEC/ITU 9594-9 • X.509 is ITU Standard: • ITU-T Recommendation X.509 (1997 E). Information technology - Open Systems Interconnection - The Directory: Authentication Framework • Defines a certificate format • Latest standard: X.509 version 3 certificate format • X.509 certificate includes: • User identification (someone’s subject name) • Public key • Validity period • A “signature” from a Certificate Authority (CA) that: • Proves that the certificate came from the CA. • Vouches for the subject name • Vouches for the binding of the public key to the subject

25. DEMO: openssl commands • Where do I find more information on how to handle certificates?http://www.switch.ch/grid/certificates/openssl/

26. X.509 Certificate Example (1) • openssl x509 –in ~/.globus/usercert.pem –text Certificate: Data: Version: 3 (0x2)X509.3 – with extensions Serial Number: 199 (0xc7) Signature Algorithm: md5WithRSAEncryption Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CAIssuer CA Validity Not Before: Sep 25 10:33:05 2008 GMT long term certificate Not After :Sep 24 10:33:05 2009 GMT Subject: O=Grid, O=CERN, OU=cern.ch, CN=Joe Useruser identification Subject Public Key Info: Public Key Algorithm: rsaEncryption public key RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d6:6a:f3:ad:e3:b2:2e:98:32:7f:dd:44:89:38: […]

27. X.509 Certificate Example (2) X509v3 extensions: X509v3 Basic Constraints: critical Certificate extensions CA:FALSE X509v3 Subject Key Identifier: 71:BC:FC:29:4E:E9:4E:7C:C9:E4:F9:A2:6C:77:4A:E4:55:82:86:53 X509v3 CRL Distribution Points: Certificate Revocation List URI:http://service-grid-ca.web.cern.ch/service-grid-ca/cgi-bin/getCRL X509v3 Issuer Alternative Name: email:service-grid-ca@cern.ch X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.96.10.1.2.1 Netscape Cert Type: SSL Client, S/MIME, Object Signingclient/user Certificate Netscape Base Url: http://service-grid-ca.web.cern.ch/service-grid-ca/ Signature Algorithm: md5WithRSAEncryption 54:8b:66:e8:dc:60:cd:e3:dc:43:a7:c9:3a:12:2c:73:05:13: [...] Signature on the information

28. Trusting the CAs • Nothing hinders you to set up your own CA and issue certificates • Getting others to trust you is the hard problem! • Trust anchors: the CAs that we more or less trust unconditionally • Granularity: 1 CA per country • Primarily used in production grids for research purposes • See www.gridpma.org The Grid's Policy Management Authority Working to Establish World Wide Trust for Grids

29. Where are those certificates ? • User certificates: • $HOME/.globus • usercert.pem, userkey.pem • Server certificates: • /etc/grid-security/ • hostcert.pem, hostkey.pem • certificates # IGTF bundle, many small files • Scripts: • IGTF as part of the grid software # e.g. rpm, YAIM • fetch-crl # updates the CRLs

30. How to protect your private key ? • File permissions on the private key • Only readable by owner • Choose a “good” passphrase • Many characters (>14) • Not only letters, but also numbers and #@_&%$ • Keep track on which hosts you have put your private key • Don’t import it into browsers that you don’t use all the time • Remember: Anybody with access to your private key can impersonate you

31. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary

32. Single sign-on and delegation • Jobs require access to multiple resources • To authenticate with your certificate directly you would have to type a passphrase every time • Need to automate access to other resources: Authenticate Once • Important for complex applications that need to use Grid resources • Enables easy coordination of varied resources • Enables automation of process • Allows remote processes and resources to act on user’s behalf - also known as delegation • In the Grid Security Infrastructure today, this is solved by ‘proxy certificates’ • A temporary key pair • In a temporary certificate signed by your ‘long term’ private key • Valid for a limited time (default: 12 hours)

33. Delegation Note: private key never leaves the host

34. Proxy Certificates

35. Delegation and limited proxy • Delegation = remote creation of a (second level) proxy credential • Agents and brokers act on behalf of users • with a (subset of) their rights • This leads to a push model with proxies • you don’t know beforehand where your task will end up • Allows remote process to authenticate on behalf of the user • Remote process “impersonates” the user • The client can elect to delegate a “limited proxy” • Each service decides whether it will allow authentication with a limited proxy

36. Proxy renewal • Proxy has limited lifetime (default is 12 h) • Bad idea to have longer proxy • However, a grid task might need to use a proxy for a much longer time • Grid jobs in HEP Data Challenges on LCG last up to 2 days • A dedicated service can renew automatically the proxy

37. But • Something is missing……

38. VO information • Remember: user acts as member of a VO • VO may also add information • Group memberships • Roles • Example: VO PlatypusLovers • Groups: HavePlatypus, BeenInAustralia • Role: FinancialOfficer, PlatypusCaretaker • De-facto Standard: VOMS • Virtual organization membership service • One VOMS instance per VO

39. VO Information in VOMS • Groups and role information is issued as an Attribute Certificate (AC) that is put as an extension into the user’s proxy certificate • All groups are listed, ordering matters • Role information is present only if the users requests it • AC contains list of “fully qualified attribute names “ FQAN • Example: • /vo_name/group1/Role=administrator • /vo_name/group2 • /vo_name/group2/subgroup2 • First FQAN is primary FQAN  special role in job handling

40. Demo • voms-proxy-init –voms <vo_name> • Creates key pair for proxy certificate • Contacts VOMS server for VO <vo_name> to obtain AC • Creates proxy certificate with VOMS AC and signs it using the user’s private key • Example: • voms-proxy-init –voms switch  /tmp/x509up_u964 • voms-proxy-info –all

41. Grid Security At Work • Get certificate from relevant CA • Join virtual organization • Generate proxy as needed • Run clients • Authenticate • Authorize • Delegate as required

42. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary

43. Problems of Certificates • Certificates have their drawbacks: • Provisioning certificates to the user is cumbersome • Certificates require a lot of knowledge from the user • Private keys must be properly secured • Easiest is to hide the certificates from the user ! • Conclusion from a usability point of view:

44. SWITCHaai: Authentication and Authorization Infrastructure of Switzerland • SWITCHaai: AAI of Switzerland: provides every user of the Swiss academic community an identity that is backed by the user’s home organization (i.e. his/her university) • Today, over 400 services use AAI to authenticate and authorize users • Every university of Switzerland is member of AAI

45. SWITCHaai Federation Spring 2011 # Home Organizations #AAI enabled accounts #Resources 97% coverage inhigher education AAI Status Update - May 2011

46. Issuing Certificates based on AAI • Idea: As every student of Switzerland already has an AAI credential, issue certificates based on AAI identity vetting is already been done by the university • Consequence: user friendly way to obtain certificate • No special identity vetting needed • Certificates simply expire once they are no longer used • Short-lived credential service: issues Grid certificates to a member of SWITCHaai based upon successful authentication at his/her home organization

47. Demo

48. Easy grid access: SLCS Certificates • Online CA issuing short-lived X.509 certificates based upon authentication at Shibboleth Identity Provider • Shibboleth attributes used in DN • In production andaccredited by EuGridPMA

49. SLCS Certificates based on AAI • Certificate lifetime < 1 mio sec (~ 11 days) • Easy generation from the command line based on authentication to AAI • Certificates simply expire after 11 days and can reissued many times  easy to use for the user • SLCS service is operated by SWITCH - seehttp://www.switch.ch/grid/slcs

50. Outline • Introduction • Virtual Organizations • A sloppy introduction into cryptography • X.509 certificates • Use of X.509 certificates in Grid technology • AAI and Grids • Summary