OGSA Security Profile 2.0 (a.k.a. Express Authentication Profile) DUANE MERRILL October 18, 2007.
-
Upload
ethan-holland -
Category
Documents
-
view
218 -
download
0
Transcript of OGSA Security Profile 2.0 (a.k.a. Express Authentication Profile) DUANE MERRILL October 18, 2007.
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