Grid Security

1. Grid Security The information in this presentation is based on GT4

2. Key Security Concepts • Main Goals of Security • Confidentiality • Only the two parties can understand the contents of the messages/transmissions • Authentication • Each party is able to prove their identity • Integrity • Each party is able to discover if any changes in a message has occurred

3. Public Key Cryptography • Alice has a public and private key for • Private operation D(x) • Public operation E(x) • Provides Confidentiality • Bob encrypts E(m) • Alice can decrypt D(E(m)) • Provides Authentication • Alice signs D(m) • Anyone verifies E(D(m)) ex. RSA

4. Public Key Encryption • Sender uses Receiver’s public key to encrypt the message • Sends E(m) Receiver applies private key/operation to E(m) m = D(E(m))

5. Public Key Digital Signatures • Sender & Receiver apply hash to the message to produce a digest • Sender encrypts the digest using his private key • Receiver decrypts the digest using the sender’s public key This is proves the identity of the sender because the receiver uses the “sender’s” public key. If someone were attempting to pose as the ‘sender’ they would not have the private key to perform the correct encryption of the message digest.

6. Public Key Infrastructure • Certificate Authority – trusted by everyone • CA signs user’s certificate that contains user’s identity and public verification & encryption key • Web of Trust (PGP) – users sign each other’s certificates http://xkcd.com/364

7. Basic Security: More Info • http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09.html • This tutorial is only a few ‘slides’ in length and provides a very good overview with nice images.

8. These security components are based on GSI The Globus Toolkit

9. Grid Security Infrastructure • Key motivations for GSI: • Need for secure communication • Need for support security across organizational boundaries • Need to support “single sign-on” • Uses public key (AKA: asymmetric) cryptography • Features: • Transport and Message level security • 3 schemes • Authentication through X.509 and proxy certificates • Multiple authorization schemes • Credential delegation & single sign-on • Security levels: container, service, resource

10. GSI: WS Security • Transport-level security • Message-level security • Quick SOAP reminder… • Simple Object Access Protocol • Allows programs to communicate via the internet • XML sent, usually, over HTTP • Abstraction layer on which others can be built

11. GSI: WS Security • Two message level security mechanisms • WS Security standard • Security for individual SOAP messages • IE, on a per message basis without any existing pretext between sender and receiver • WS Secure Conversation • Initial message exchange to establish security context • Subsequent messages require less overhead for security during the session

12. GSI: WS Security • Transport level VS Message levels

13. Authentication and Authorization The Globus Toolkit: GSI

14. Verification of the identity of an entity through the presentation of a token that can not be forged Important for: Access control Confidentiality User (organization) accountability Authentication

15. Anonymous Authentication Essentially means unauthenticated Examples: Using > 1 security scheme GSI Secure conversation (authenticated with X.509 cert.) and anonymous GSI transport Username & pass again with anonymous GSI transport Username and password Supports rudimentary WS apps No access to advanced features, such as… Delegation, confidentiality, integrity, replay prevention x.509 certificates Authentication

16. X.509 “… profiles the format and semantics of certificates and certificate revocation lists …” This defines the syntax of how a Certificate Authority can sign and authenticate who is whom in an asymmetric (public key) based crypto world Used by … who who and whom Authentication

17. X.509 Certificate Fields

18. X.509 Certificate Example Certificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com Validity: Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): (1024 bits of data … ) Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption (signature data … )

19. Determining what actions (tasks) are permitted for an entity Custom Ex. Creating authorization methods to interface GSI with an existing legacy system Server-side Client-side Authorization

20. Authorization • Server-side authorization modes: • None -> No authorization • Self -> Authorized if client identity==service identity • Gridmap -> Authorized user list (~ACL) • Identity Authorization -> Identity must match programmed identity • Host Authorization -> Only allow requests from a particular host specified in the given credential • SAML Callout Authorization -> Authorization decision delegated to OSGA Authorization-compliant authorization service.

21. Authorization • Client-side authorization • Allows the client to decide when a client is allowed to be invoked • Modes: • None -> No authorization • Self -> Authorized if client identity==service identity • Identity Authorization -> Identity must match programmed identity • Host -> Authorized if client has a host credential • Client must be able to resolve hostname address

22. Problem Not feasible to administer authorization information on a site by site basis Users normally administer only their own local site, not the sites of other entities Solution VOMS Authorization

23. Virtual Organization Membership Service “… system for managing authorization data within multi-institutional collaborations. VOMS provides a database of user roles and capabilities … to generate Grid credentials for users when needed.” – Globus Alliance Developed by European DataGrid Project VOMS

24. VOMS • Authorization based on policies and agreements between Virtual Organizations (VO) and Resource Providers (RP) • Users in a VO must present credentials to an RP in order to gain access to the resources • VOMS allows VO administrators to add users and their roles and capabilities to an authorization database

25. VOMS • User and server authenticate each other using certificates via the standard globus API • User sends a signed request to VOMS server • VOMS server verifies user identity and sends back the VOMS “pseudo-certificate” or “attribute certificate” • User creates proxy certificate containing pseudo-certificate as a non-critical extension • The RP extracts the authorization information and makes a decision using the Local Credential Authorization Service (LCAS) Client VOMS Auth DB Proxy Certificate Request Authentication To RP pseudocert pseudocert

26. VOMS Database Security • Scenario – malicious user grants access rights to any service through compromised database • User can still not impersonate another user since the pseudo-certificate is embedded in a user-self-signed proxy certificate • Scenario – Denial of Service Proxy Certificate pseudocert

27. Delegation and single sign-on The Globus Toolkit: GSI

28. x.509 proxy certificates Based on WS-Trust specification Delegation

29. Community Authorization Service The Globus Toolkit: GSI

30. Community Authorization Service (CAS) • A service that allows resource providers to specify access policies to a community as a whole • Fine-grained access controlled by the community itself • How CAS works ……………………….. 

31. Community Authorization Service (CAS) • How it works… • CAS server initiated for a community • Community rep acquires a GSI credential (1) for the whole community • Same rep runs the CAS server using the received GSI credential

32. Community Authorization Service (CAS) • How it works… • Resource providersgrant privileges to the community • Each resource provider verifies… • Credential holder represents the community • Community policies are compatible with its own • Trust relationship established • Rights granted to the community identity

33. Community Authorization Service (CAS) • How it works… • Community rep(s) use CAS to manage community's trust relationships and grant access to resources • Users and resource providers can be enrolled into the community • Privileged community members can administrate the community • Ex. Add new members, manage groups, grant permissions

34. Community Authorization Service (CAS) • How it works… • When a user wants access to CAS served resources… • The user makes a request to the CAS server • CAS server verifies that the user has the appropriate privileges by checking its DB • CAS server issues the user a GSI restricted proxy credential • Credential contains policy giving user rights to perform the requested actions

35. Community Authorization Service (CAS) • How it works… • User may then use the issued credential to access the resource using any Globus tool • Resource applies its local policies to determine access available to the community • Resource further restricts a users access IF the credentials given to the user by the CAS dictate

36. Problem Grid Portals do not integrate cleanly with existing Grid security systems, such as GSI Reason: Lack of delegation capabilities in Web security mechanisms Possible solution MyProxy GSI: Credential Management

37. MyProxy • Cover MyProxy here?

38. OpenID • “An open, decentralized, free framework for user-centric digital identity” • Who uses OpenID • AOL, Blogger, Flockr, WordPress, Yahoo(beta), …

39. OpenID • Two Architectural Implementations • Address-based Identity • Public or private digital address dereferenced to discover/invoke identity services • Could be either… • OpenID-enabled URL • XRI i-name (Ex.: xri//=example.user) • Persistent, protocol-independent, privacy-protected • Supports cross-reference authority for P2P addressing • Card-based Identity • Digital token containing references to attributes identifies the user • Contains information necessary to accomplish identity based transaction • Neither are exclusive • Ex.: Card could reference address or Address could reference card

40. OpenID: Protocol Flow

41. Novotny, J., Tuecke, S., & Welch, V. (2001). An Online Credential Repository for the Grid: MyProxy. Paper presented at the Proceedings of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), IEEE. Alfieri, R., Cecchini, R., Ciaschini, V., Frohner, Á., Gianoli, A., Lőrentey, K., & Spataro, F. (2003). An Authorization System for Virtual Organizations. Paper presented at the In Proceedings of the 1st European Across Grids Conference, Santiago de Compostela. Sotomayor, B. The Globus Toolkit 4 Programmer's Tutorial: Chapter 10. GSI: Grid Security Infrastructure. Welch, V., Siebenlist, F., Foster, I., Bresnahan, J., Czajkowski, K., & Gawor, J., et al. (2003). Security for Grid services. High Performance Distributed Computing, 2003. Proceedings. 12th IEEE International Symposium on, 48-57. Zhao, S., Aggarwal, A., & Kent, R. D. (2007). PKI-Based Authentication Mechanisms in Grid Systems. Networking, Architecture, and Storage, 2007. NAS 2007. International Conference on, 83-90. Welch, V., Siebenlist, F., Foster, I., Gawor, J., Kesselman, C., & Meder, S., et al. (2004). X.509 Proxy Certificates for Dynamic Delegation. 3rd Annual PKI R&D Workshop. References

42. References (cont.) • Welch, V. Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective 2005 • Inproceedings (1179532)Recordon, D. & Reed, D.OpenID 2.0: a platform for user-centric identity managementDIM '06: Proceedings of the second ACM workshop on Digital identity management, ACM, 2006, 11-16