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: [ws-rx] proposal for i122, i123, and i124


I thought it was clear that both transport or tokens could be used. If not that should be corrected. I do think SP is the right place to define transport security requirements though, not RM.

 

From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Thursday, June 08, 2006 12:09 PM
To: Marc Goodner; Raepple, Martin; chrisfer@us.ibm.com; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] proposal for i122, i123, and i124

 

I think Martin is pointing out that there are several techniques for securing the sequence

such as, for example, transport-level security.  Why standardize on certificates?

 

This issue reminds me of similar language thet we used to have in the spec but decided

to remove as it, too, talked about a specific security mechanism.

All the best, Ashok

 

 


From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Thursday, June 08, 2006 10:43 AM
To: Raepple, Martin; chrisfer@us.ibm.com; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] proposal for i122, i123, and i124

Martin, thanks for the quick review of this proposal. I’ve tried to answer your questions below.

 

From: Raepple, Martin [mailto:martin.raepple@sap.com]
Sent: Thursday, June 08, 2006 10:15 AM
To: chrisfer@us.ibm.com; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] proposal for i122, i123, and i124

 

A few comments / questions on the proposal:

 

- The usage of transport layer security protocols to secure a sequence is not mentioned in the proposal at all. Is that intentional? Since it refers to WS-SecurityPolicy (WS-SP), there are certainly ways to support this scenario, even without the requirement to use any of the additional elements introduced by this proposal

MG: Yes. Please see issue 75 in the SX TC where additional sub-assertions are proposed for sp:HttpsToken that would introduce additional authentication modes similar to part of the original proposal for 122. This would allow these additional authentication modes for HTTPS to compose with RM or without it.

http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i075

 

(one might even recommend to mutually exclude the use of the <wsrmp:SequenceSTR> in conjunction with the <sp:TransportBinding> assertion in RM?) Shouldn't this be included in the proposal as well?

MG: We hadn’t considered excluding it, I’m not sure that is necessary. I could see the possibility of a transport binding that would have an associated token that could be expressed here. I think this needs further discussion to determine the correct answer here.

 

- The STR (and its RM policy assertion) does not provide any information about the actual token type and the security protocol used (e.g. an Security Context Token in the case of WS-SC). Again, I assume that the intension is to use WS-SP for this purpose.

MG: Yes.

But shouldn't the proposal/spec be more precise on that?

MG: Good suggestion.

How would the actual policy composition of the (new) RM Security- and SP-Assertions look like?

MG: I can try to get some examples together. I might not be able to do so before early next week.

What SP-Assertions can be nested as child elements of the <SequenceSTR> to further qualify the behavior and compatibility semantics of that new assertion?

MG: We hadn’t considered nesting inside SequenceSTR.  You’ll notice in this proposal that the assertion does not have extensibility that would allow that. We were looking at this from the perspective of defining the token with SP on the same binding where the RM assertion and the SequenceSTR assertion appear. So as I say we hadn’t discussed this, it is worth exploring.

 

- The above question leads to another issue: The <wsrm:UsesSequenceSTR> SOAP header does not include sufficient information to actually ensure interoperability between an RMS and RMD. Even if the RMD understands and implements the STR, it might not be able to process the actual token referenced by the STR inside the CreateSequence element. 

MG: It is up to clients to conform to the security requirements of the service right?

As an example, the RMS could use a Security Context Token with a derived key but the RMD does not support the particular key derivation algorithm.

MG: The RMS must conform to the security requirements of the RMD. It could find those out either through SP or some out of band mechanism.

Given that, doesn't that mean that the RMD must also take the (token qualifying) SP assertions into consideration when deciding whether or not to return a soap:MustUnderstand fault?

MG: I need to think about this some more. My initial reaction is that in the scenario you are describing, which to me sounds like incorrect behavior on the part of the RMS, that a security fault would be returned and not a soap:mustUnderstand fault. I’ll need to look at this a little deeper.

 

-- Martin

 

Martin Raepple
Platform Ecosystem Industry Standards
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf, Germany
T  +49/6227/7-60365
F  +49/6227/78-44724
mailto: martin.raepple@sap.com
http://www.sap.com

 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Donnerstag, 8. Juni 2006 13:28
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] proposal for i122, i123, and i124


All,

IBM and Microsoft would like to submit the following proposal for issues i122, i123 and i124 that defines
the mechanism that MAY be used to secure an RM Sequence, the means by which the RMS can be assured
that the RMD will correctly process the extension, and the means by which the RMD can advertise support for the
extension.



Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email:
chrisfer@us.ibm.com
blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295



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