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: 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.
 
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.
 
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)? 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?
 
- 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]