1. OGSA Security Profile 2.0 (a.k.a. Express Authentication Profile) DUANE MERRILL October 18, 2007

2. Presentation Overview 1.Goals & non-goals of the OGSA-SP 2.0 2.Motivation 3.Secure Addressing 4.Secure Transport 5.Secure SOAP 6.Questions

3. OGSA Security Profile 2.0 (A.K.A Express Authentication Profile) GOALS 1.Profile how to convey secure-communication requirements within EPRs 2.Define well-known, composable security policies for common security mechanisms 3.Provide minor mechanism clarifications and refinements as security mechanisms are adapted to Grid 4.Establish trustworthiness of EPRs (e.g., tamper- resistance via digital signature)

4. Intent IS TO: Enable discovery of common security mechanisms Or cleanly identify when interoperability is not possible Easily be extended to accommodate new mechanisms, credentials, etc. IS NOT TO: Impose common security mechanisms Invent new security mechanisms Invent new languages for describing security mechanisms

5. Motivation SECURITY: A systems ability to protect its assets Disclosure or theft of resources Modification (including destruction) of resources Resource service interruption Crucial for OGSA/Grid adoption Participants require protection from undue risk Participants must meet legal requirements

6. First Steps: Protocol Interoperability SOA Philosophy Presume nothing regarding service implementation Message format and endpoints are public knowledge Security mechanisms affect message format What do I have to do to my messages to communicate? Message payloads defined by well-known, static service interfaces Diverse (and possibly dynamic) security action requirements for messages

7. Diverse Security Requirements Credential requirements Users & resources tied to existing credential infrastructures (e.g., Kerberos, X.509 PKI, SAML, etc.) No lowest common denominator OGSA security model tasked with integration of these trust and security domains Security action requirements Grid applications created via service composition Application-specific security requirements imposed on component services E.g., ByteIO resources may have confidentiality requirements in some cases, not others

8. Why another mechanism for security requirement discovery? Attachment of WS-SecurityPolicy requirements to WSDL and UDDI WS-I Conformance Claim Attachment Mechanism to WSDL "http://ogf.org/profiles/hpc-basic/1.0/username-token" Issues: WSDL not always fine-grained enough WSDL not always published Non-standardized conventions for locating WSDL Scope limited to interface/application

9. Why another mechanism for security requirement discovery? (Continued) CaGrid exposes requirements through reflective service operations getSecurityMetadata() Chicken-before-egg problem Extra communication required Liberty exposes requirements within EPRs urn:liberty:security:2006-08:ClientTLS:SAMLV2 Not as expressive as WS-SecurityPolicy No means to communicate individual integrity/confidentiality requirements

10. Why EPRs? Grid utility is derived from the composition (often dynamic) of services EPRs extensively incorporated into core service interfaces, e.g.: Notification (WS-Eventing) Execution management (BES activity creation) Directory services (RNS) EPRs are how services refer and address each other EPRs serve as invocation contexts: Everything one needs to know to for communication

11. OGSA SP 2.0 Document Architecture Multiple documents composed in a hierarchical, extensible fashion. OGSA-BSP Secure Addressing Defines the general WS-SecurityPolicy attachment mechanism to EPRs Profile EPR digital signature OGSA-SP Secure Transport Defines well-known policies for de-facto transport-level secure communication configurations. OGSA-SP Secure SOAP Messaging Defines analogous policies for de-facto message-level security mechanisms

12. Secure Addressing Idea : Apply WS-SecurityPolicy to the extensible portion of the EPR WS-SecurityPolicy : Extension to WS-Policy framework New OASIS standard Grammar for asserting token types, cryptographic algorithms and mechanisms, including using transport level security

13. … urn:soapaction:* http://…#CertifiedServerTLS http://...#UsernameToken …

14. Secure Addressing Cont (Optional) Digital signing of EPRs: Extend WS-Addressing to profile a element as a child of the document Such a signature MUST cover the following elements:

15. Secure Transport Defines secure transport bindings to be referenced by name: Server-authenticated TLS w/ Server Certificate Server-authenticated TLS w/o Server Certificate Mutually-authenticated TLS w/ Sever Certificate Mutually-authenticated TLS w/o Sever Certificate If the Server Certificate is present, the Profile mandates hostname verification as per RFC 2818 – HTTP over TLS TLS/SSL algorithm suites are restricted to those listed in WS-SecurityPolicy

16. TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_AES_256_CBC_SHA Server-authenticated TLS w/o Server Cert Policy Mutually-authenticated TLS w/o Server Cert Policy

17. Back to Secure Addressing EPRs may also need to perform key distribution: Extra hostname-verification at the transport-level Message-level encryption Want to embed tokens directly into the EPR, yet WS- SecurityPolicy does not provide for this Token assertions may contain a element to indicate the EPR of a location from which to obtain a token Solution: extend WS-SecPols token assertions to optionally contain an alternative We can put embedded tokens in tags within the document

18. <wsse:Reference URI='#RecipientTransportIdentity' ValueType="http://docs.oasis-open.org/...#X509v3" /> Server-authenticated TLS w/ Server Cert Policy

19. Secure SOAP Defines common secure message-level bindings to be referenced by name: Username-token (simple) Password-digest username-token (digest of password, timestamp, and nonce) X.509 Mutual authentication

20. <wsp:Policy wsu:Id=PasswordDigest <wsp:Policy wsu:Id=UsernameToken Username-Token PolicyPassword-Digest Policy

21. (01) (02) (03) (04) (05) (06) (07) (08) (09) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) … Mutually-Authenticated X.509 Policy

22. … (23) (24) (25) (26) (27) (28) (29) <wsse:Reference URI='#RecipientMessageIdentity ValueType="http://...wss-x509-token-profile-1.0#X509v3"/> (30) (31) (32) (33) (34) (35) … Mutually-Authenticated X.509 Policy

23. … (74) (75) (76) (77) (78) (79) (80) (81) /Envelope/Header/*[@isReferenceParameter="true"]' (82) (83) (84) (85) (86) (87) (88) (89) (90) (91) (92) Mutually-Authenticated X.509 Policy

24. Specifying Additional Protection Policy... http://www.ggf.org/ogsa/2007/05/sp-secure-soap#MutualX509...

25. Questions