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>
…
<!-- This policy attachment applies to all actions on this endpoint -->
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsp:URI>urn:soapaction:*</wsp:URI>
</wsp:AppliesTo>
<!-- Collection of policy alternatives -->
<wsp:Policy>
<wsp:ExactlyOne>
<!-- Alternative 1: Server-auth TLS + Username-token -->
<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”>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate />
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
</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”>
<sp:TransportBinding>
<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:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
</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>
…
Mutually-Authenticated X.509 Policy
…
(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>
Mutually-Authenticated X.509 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
Top Related