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



The proposal does not require that the RMD implement any new functionality. the proposed extension
is truely OPTIONAL in the RFC2119 sense. That is why we introduced the SOAP header which can be
marked mU=true to force the processor that does not understand/implement the extension to fault
with existing SOAP processing rules.

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


"Patil, Sanjay" <sanjay.patil@sap.com> wrote on 06/08/2006 03:50:08 PM:

>  

> I think in the past when we discussed one of the security issues (I
> guess - i029), the specs (back then) required certain security
> technologies to be supported in order to be compliant with the RM
> specs. If I remember it correctly, the specific issue was that the
> wsse:STR element was optional from an RMS's standpoint,  but there
> was no option for the RMD to ignore/fault upon receiving it. I would
> expect that any new proposals should attempt to not regress in this
> regard, that is, implementing RM should not require support for any
> specific security technologies.  This is not to say that I see this
> concern applicable to any of the current proposals!

>  
> -- Sanjay
>
> From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> Sent: Thursday, Jun 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 thisproposal

> 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]