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

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

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)

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

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

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

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

Why another mechanism for security requirement discovery? Attachment of WS-SecurityPolicy requirements to WSDL and UDDI WS-I Conformance Claim Attachment Mechanism to WSDL " Issues: WSDL not always fine-grained enough WSDL not always published Non-standardized conventions for locating WSDL Scope limited to interface/application

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: :ClientTLS:SAMLV2 Not as expressive as WS-SecurityPolicy No means to communicate individual integrity/confidentiality requirements

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

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

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

… urn:soapaction:* …

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:

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

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

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

<wsse:Reference URI='#RecipientTransportIdentity' ValueType=" /> Server-authenticated TLS w/ Server Cert Policy

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

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

(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

… (23) (24) (25) (26) (27) (28) (29) <wsse:Reference URI='#RecipientMessageIdentity ValueType=" (30) (31) (32) (33) (34) (35) … Mutually-Authenticated X.509 Policy

… (74) (75) (76) (77) (78) (79) (80) (81) (82) (83) (84) (85) (86) (87) (88) (89) (90) (91) (92) Mutually-Authenticated X.509 Policy

Specifying Additional Protection Policy...

Questions