OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: security profiles and WS-SecurityPolicy (was RE: [ws-rx] N*w Issu*: security profiles)


Gil,
 
please see my <MR>replies</MR> inline ...
 
Cheers,
Martin


From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Samstag, 20. Mai 2006 03:12
To: Raepple, Martin; ws-rx@lists.oasis-open.org
Subject: security profiles and WS-SecurityPolicy (was RE: [ws-rx] N*w Issu*: security profiles)

Martin,
 
I've been thinking about this for a while and I have come to the conclusion that I don't agree with your basic premise. While I still agree that a single URI is not enough to cover all of the possible combinations of configuration for a WS-SecureConversation context, I don't agree that it is the job of the WS-RM security composition profiles to provide this information.
 
The point of the security composition profiles is to precisely describe how to use a specific security mechanism (TLS, WS-SX, etc.) to meet the requirements of section 5.5. The configuration and establishment of that security mechanism is outside the scope of the profiles.
 
For example, part of setting up a TLS session involves a determination of whether the client trusts the issuer of the server's certificate, but I don't think its the responsibility of the WS-RM security composition profile to provide a list of trusted CAs for that Sequence. Similarly there are TLS ciphersuites (NULL-MD5 and NULL-SHA) that do not satisfy the requirements of section 5.5 (they don't provide integrity) but I can't see a WS-RM sec-comp profile providing a list of acceptable TLS ciphersuites.
 
<MR>For the transport security profiles this approach could work since the protocols define their own policy format (e.g. cipher suite attributes) and metadata exchange protocol using the client hello / server hello messages (in SSL) as part of the initial handshake. Transport security based on these protocols always simplifies security setup for each application level protocol that sits on top.</MR>

Each profile pre-supposes that a particular security mechanism (TLS session or WS-SX context) will be "made available" for use by the RMS and the RMD. There are certain minimum levels of functionality and qualities of service required by these security mechanisms in order to meet the requirements of section 5.5 (and it seems that we need to do a better job at specifying these requirements on a per-technology level) but specifying the mechanism-specific configuration information necessary to meet those requirements is outside the scope of WS-RM.
 
<MR>This is what I ment with approach a) in my former mail. The security profiles (and in particular the message-level profiles) could specifiy all requirements AND configuration details (somehow in the way the WS-I profiles do but this must be even more restrictive). But the more specific and prescriptive the profiles are, the less flexibility they provide.
Let's take the following example: To establish a security context in WS-SC, the RMS must send an RequestSecurityToken (RST) to the RMD (assuming that the RMD actually can issue tokens and does not rely on a 3rd party STS). It is good practice to require some sort of authentication token in the RST to verify the request before the RMD sends the RequestSecurityTokenResponse (RTSR) to the RMS. Given the limitation that one cannot specify any configuration information in the WS-RM security policy assertions, the WS-SC profile in RM must specify *one* authentication mechanism, e.g. a UsernameToken. This is not a problem as long as the RMS is able to provide this specific token format. But if it could only provide a SAML token to the RMD, they would not be able to establish the security context. Or to say it in another way: If the RMD had a chance to tell the RMS that it would accept Username- and SAML Tokens for the RST (by using a richer policy language for the security in RM), interoperability based on this WS-RM profile would increase.</MR>
 
Look at it another way: Suppose I had a consumer and a provider that wanted to use WS-SX to protect their messages. How would they come to agreement on the issues you mentioned (third-party token services, derived key support, etc)?
<MR>They would use the assertions in WS-SP that cover the configuration issues of all the SX and WSS protocols/tokens (WSS, WS-SC & WS-Trust). An assertion that routes the RMS to a 3rd party STS (e.g. at http://sts.rmd.org/sts) to get an SCT using derived keys looks like this:
...
<sp:SecureConversationToken sp:IncludeToken="always">            
    <sp:Issuer>
        <wsa:EndpointReference>
            <wsa:Address>http://sts.rmd.org/sts</wsa:Address>
        </wsa:EndpointReference>
    </sp:Issuer>
    <wsp:Policy>            
        <sp:RequireDerivedKeys ... /> 
        ...
    </wsp:Policy>
  ...
</sp:SecureConversationToken>
 
The policy of the STS then tells the RMS what authentication token it requires for the RST.
</MR>
 
 Why does adding reliable messaging to this scenario shift this agreement/configuration burden to WS-RM? Suppose we *did* use WS-RM sec-comp profiles to specify this information, what would happen if we decided that we no longer wanted to use reliable messaging?
 
<MR>I agree and therefore WS-RM should *NOT* reinvent the wheel by specifying a new large set of policy assertions for the security profiles. But I see a problem with the current policy assertions in the proposal because they are very simple (which is generally preferable!) but deal with very complex (message level) security protocols. This simply doesn't work together very well and I see two ways to solve this issue: Specify *one* standard configuration scenario and attribute set (limits interoperability but works with current set of RM security policy assertions) or use a richer set of policy assertions as defined by WS-SecurityPolicy (improves interoperability and obsoletes the use of RM security policy assertions which will also affect the runtime agreement protocol).</MR>
 
- gp


From: Raepple, Martin [mailto:martin.raepple@sap.com]
Sent: Sunday, May 14, 2006 6:20 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] New Issue: security profiles

Gil,
 
I want to share some initial thoughts when I read through the new security proposals. From my understanding, the motivation for the profile approach is its simplicity when it comes to the determination of supported profiles at runtime (as described in [2]) and endpoint metadata description (as described in [3]) by simply referring to the profile URI that uniquely identifies the supported security composition profile.
 
Based on the security profile descriptions defined in [1] and the mechanisms provided in [2] and [3], I doubt that they can guarantee interoperability between the RMS and RMD, because the profile URI on its own won't provide sufficient information to automate the security configuration of the messages. Even though this approach might work for the transport security profiles (due to the automated metadata exchange in the SSL/TLS handshake protocol), for example the security bootstrap described in step 1 of the WS-SecureConversation (WS-SC) Profile [1] requires more information for the RMS than currently provided by the policy assertion or the <SecurityComposition> element.
 
As an example, the RMD might not be able to issue Security Context Tokens for WS-SC and thus depends on a third party token issuer which needs to be advertised to the RMS. Or, the RMS might not support the use of derived keys in WS-SC which needs to be stated somewhere. One can extend this list with a number of other configuration settings which are not yet defined either in the profile description or configurable via the policy assertions.
 
I could think of two ways to approach this issue:
 
a) The profiles (in particular the message security / WS-SC profile) provide more details in terms of algorithm suites, token properties, token issuing etc. However, it would be impossible to generalize all potential configurations. Therefore, the intention of this approach can only be a recommendation in terms of 'best practices' and not a guarantee for interoperability
 
b) Instead of defining RM-specific security policy assertions, the security profiles are translated to the corresponding assertions in WS SecurityPolicy (SP) 1.2 (e.g. with a recommendation provided by the specification in terms of SP assertions, e.g. the SecureConversationToken assertion for the WS-SC Profile and TransportBinding assertion for the SSL/TLS profiles). Compared to a), this approach at least will cover (hopefully!) all possible configurations for the profiles and thus better supports automated configuration and interoperability. Indeed, this means that the use of the profile URI in the profile agreement at runtime would be obsolete.
 
Cheers,
Martin
 
[1] security profiles, http://lists.oasis-open.org/archives/ws-rx/200605/msg00097.html
[2] security profile agreement, http://lists.oasis-open.org/archives/ws-rx/200605/msg00098.html
[3] security composition policy, http://lists.oasis-open.org/archives/ws-rx/200605/msg00099.html
 
 
Martin Raepple
Platform Ecosystem Industry Standards
SAP AG
mailto: martin.raepple@sap.com
 

From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Dienstag, 9. Mai 2006 23:42
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] New Issue: security profiles

The WS-RX TC Charter requires that WS-RM support the “efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms”. The charter also states that “While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.” This proposal attempts to satisfy these two requirements by defining a set of non-normative profiles for composing WS-RM with commonly used web services security mechanisms. The purpose is to aid in the implementation and deployment of interoperable services and applications that utilize secure, reliable SOAP messaging systems.
 
Proposal: Add the attached text as a new chapter to the WS-RM specification following Chapter 5 (Security Threats and Requirements)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]