OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile)

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 2.0

2. 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 system’s 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 • "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

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

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

<wsa:Metadata> 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

<wsa:Metadata>

…



<wsp:PolicyAttachment>

<wsp:AppliesTo>

<wsp:URI>urn:soapaction:*</wsp:URI>

</wsp:AppliesTo>



<wsp:Policy>

<wsp:ExactlyOne>



<wsp:All>

<wsp:PolicyReference>http://…#CertifiedServerTLS</wsp:PolicyReference>

<wsp:PolicyReference>http://...#UsernameToken</wsp:PolicyReference>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsp:PolicyAttachment>

…

<wsa:Metadata>

Secure Addressing Con’t

(Optional) Digital signing of EPRs:

• Extend WS-Addressing to profile a <ds:Signature> element as a child of the <wsa:EndpointReference> document

• Such a signature MUST cover the following elements:• <wsa:Address>• <wsa:ReferenceParameters>• <wsa:Metadata>

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

<wsp:Policy wsu:Id=”ServerTLS”>

<sp:TransportBinding>

<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken />

</wsp:Policy>

</sp:TransportToken>

<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic256 />

</wsp:Policy>

</sp:AlgorithmSuite>

</wsp:Policy>

</sp:TransportBinding>

</wsp:Policy>

TLS_RSA_WITH_AES_256_CBC_SHA

SSL_RSA_WITH_AES_256_CBC_SHA

<wsp:Policy wsu:Id=”MutualTLS”>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken>

<wsp:Policy>

<sp:RequireClientCertificate />

</wsp:Policy>

</sp:HttpsToken>

</wsp:Policy>


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic256 />

</wsp:Policy>


</wsp:Policy>


</wsp:Policy>

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 <wsp:issuer> element to indicate the EPR of a location from which to obtain a token

• Solution: extend WS-SecPol’s token assertions to optionally contain an alternative <wsse:SecurityTokenReference>

• We can put embedded tokens in <wsse:SecurityTokenReference> tags within the <wsa:Metadata> document

<wsp:Policy wsu:Id=”ServerTLS”>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken>

<wsse:SecurityTokenReference>

<wsse:Reference URI='#RecipientTransportIdentity'

ValueType="http://docs.oasis-open.org/...#X509v3" />

</wsse:SecurityTokenReference>

</sp:HttpsToken>

</wsp:Policy>


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic256 />

</wsp:Policy>


</wsp:Policy>


</wsp:Policy>

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”

<sp:SupportingTokens>

<wsp:Policy>

<sp:UsernameToken>

<wsp:Policy>

<sp:HashPassword/>

</wsp:Policy>

</sp:UsernameToken>

</wsp:Policy>

</sp:SupportingTokens>

</wsp:Policy>

<wsp:Policy wsu:Id=”UsernameToken”

<sp:SupportingTokens>

<wsp:Policy>

<sp:UsernameToken/>

</wsp:Policy>

</sp:SupportingTokens>

</wsp:Policy>

Username-Token Policy Password-Digest Policy

(01)<wsp:Policy wsu:Id=”MutualX509”>

(02) <sp:AsymmetricBinding>

(03) <wsp:Policy>

(04) <sp:InitiatorToken>

(05) <wsp:Policy>

(06) <sp:X509Token sp:IncludeToken="http://.../AlwaysToRecipient">

(07) <wsp:Policy>

(08) <wsp:ExactlyOne>

(09) <wsp:All>

(10) <sp:WssX509V3Token11/>

(11) </wsp:All>

(12) <wsp:All>

(13) <sp:WssX509PkiPathV1Token11/>

(14) </wsp:All>

(15) <wsp:All>

(16) <sp:WssX509Pkcs7Token11/>

(17) </wsp:All>

(18) </wsp:ExactlyOne>

(19) </wsp:Policy>

(20) </sp:X509Token>

(21) </wsp:Policy>

(22) </sp:InitiatorToken>

…

Mutually-Authenticated X.509 Policy

…

(23) <sp:RecipientToken>

(24) <wsp:Policy>

(25) <wsp:ExactlyOne>

(26) <wsp:All>

(27) <sp:X509Token sp:IncludeToken="http://.../IncludeToken/Never>

(28) <wsse:SecurityTokenReference>

(29) <wsse:Reference

URI='#RecipientMessageIdentity‘

ValueType="http://...wss-x509-token-profile-1.0#X509v3"/>

(30) </wsse:SecurityTokenReference>

(31) <wsp:Policy>

(32) <sp:WssX509V3Token11/>

(33) </wsp:Policy>

(34) </sp:X509Token>

(35) </wsp:All>

…


…

(74) <wsp:Policy wsu:Id=”RequestPolicy”>

(75) <sp:SignedParts>

(76) <sp:Body/>

(77) <Header namespace="http://www.w3.org/2005/08/addressing"/>

(78) </sp:SignedParts>

(79) <sp:SignedElements>

(80) <sp:XPath/>

(81) /Envelope/Header/*[@isReferenceParameter="true"]'

(82) </sp:XPath>

(83) </sp:SignedElements>

(84) </wsp:Policy>

(85)

(86) <wsp:Policy wsu:Id=”ResponsePolicy”>

(87) <sp:SignedParts>

(88) <sp:Body/>

(89) </sp:SignedParts>

(90) </wsp:Policy>

(91)

(92) </wsp:Policy>


Specifying Additional Protection Policy ...

<wsp:Policy>

<wsp:All>

<wsp:PolicyReference>

http://www.ggf.org/ogsa/2007/05/sp-secure-soap#MutualX509

</wsp:PolicyReference>

<wsp:Policy wsu:Id=”SupplementalInputPolicy”>

<sp:EncryptedParts>

<sp:Body/>

</sp:EncryptedParts>

</wsp:Policy>

<wsp:Policy wsu:Id=”SupplementalOutputPolicy”>

<sp:EncryptedParts>

<sp:Body/>

</sp:EncryptedParts>

</wsp:Policy>

</wsp:All>

</wsp:Policy>

• ...

Questions

OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile)

Documents

Transcript of OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile)