Re: [ws-rx] New Issue: remove dependency on WS-Security

[Duane Nickull <dnickull@adobe.com>]

Gilbert:

Before I comment on this, I need to ensure we are both looking at the 
same document.  The *.doc version I downloaded from the website starts 
at line 517 and states it is "optional":

/wsrm:CreateSequence/wsse:SecurityTokenReference

This optional element uses the extensibility mechanism defined next to 
communicate an explicit reference to the security token to be used to 
authorize messages for the created outbound Sequence and if offered the 
inbound Sequence, using a <wsse:SecurityTokenReference> as documented in 
WS-Security [WSSecurity]. All subsequent messages in the outbound 
Sequence and if offered the inbound Sequence MUST demonstrate 
proof-of-possession of the referenced key. 

I looked at the PDF document and its' line numbers are skewed 
differently than the previous word doc and your reference to lines 
52-508 is correct:

http://www.oasis-open.org/committees/download.php/13493/WS-ReliableMessaging-v1.0-wd-01.pdf

It does state in the text that this is "optional", therefore I disagree 
with the assertion that the element creates any unnecessary dependency.

Duane


Gilbert Pilz wrote:

>Title: Remove dependency on WS-Security
>
>Description: The current draft of the WS-ReliableMessaging specification
>includes elements that are defined in WS-Security. This dependency is
>unnecessary and creates a number of problems for WS-RM implementations
>and the organizations that provide such implementations. It should
>therefore be removed.
>
>Justification: Lines 502-508 of WS-ReliableMessaging-v1.0-wd-01
>describes the inclusion of a <wsse:SecurityTokenReference> as a
>sub-element of the <wsrm:CreateSequence> element. The reason for
>including a SecurityTokenReference in the sequence creation request is
>to provide the information necessary to perform authorization checks
>upon the messages within the sequence. Such authorization checks are
>unnecessary as they only serve to defend against a denial-of-service
>attack (spoofed sequence identifiers) that can be better defended
>against by proper protection of the sequence identifier. In addition to
>this there are a large number of denial of service attacks that are not
>blocked by these authorization checks.
>
>If vendors that provide implementations of WS-RM are required to support
>the use of the SecurityTokenReference during sequence creation in order
>to be deemed "compliant" (as the current interopability scenarios
>indicate), then such vendors must supply an implementation of
>WS-Security along with their implementation of WS-ReliableMessaging.
>This despite the fact that 99% of their customers may not be interested
>in using anything more complicated than SSL to protect their web
>services traffic.
>
>Although the use of the SecurityTokenReference element is described as
>optional, the decision on whether or not to use this option lies with
>the RM Source. Since there is no RM-Policy Assertion that indicates
>whether or not the RM Destination can accept the use of this option,
>negotiating the use of this option requires manual, out of band
>communications between the operators of the two systems. This impacts
>the usability of the systems that use WS-RM.
>
>Related Issues: i007
>
>Origin: Gilbert Pilz
>
>Owner: Gilbert Pilz
>
>Proposal:
>* Delete lines 458-461 of WS-ReliableMessaging-v1.0-wd-01
>* Delete lines 502-508 of WS-ReliableMessaging-v1.0-wd-01
>  
>
>------------------------------------------------------------------------
>
><issue id="i000" status="unassigned" edstatus="unassigned">
><title>Remove dependency on WS-Security</title>
><description>The current draft of the WS-ReliableMessaging specification includes elements that are defined in WS-Security. This dependency is unnecessary and creates a number of problems for WS-RM implementations and the organizations that provide such implementations. It should therefore be removed.</description>
><target>core</target>
><type>design</type>
><origin href="">Gilbert Pilz</origin>
><owner href="mailto:gilbert.pilz@bea.com";>Gilbert Pilz</owner>
><justification>
>  <h:p>Lines 502-508 of WS-ReliableMessaging-v1.0-wd-01 describes the inclusion of a &lt;wsse:SecurityTokenReference&gt; as a sub-element of the &lt;wsrm:CreateSequence&gt; element. The reason for including a SecurityTokenReference in the sequence creation request is to provide the information necessary to perform authorization checks upon the messages within the sequence. Such authorization checks are unnecessary as they only serve to defend against a denial-of-service attack (spoofed sequence identifiers) that can be better defended against by proper protection of the sequence identifier. In addition to this there are a large number of denial of service attacks that are not blocked by these authorization checks.</h:p>
>  <h:p>If vendors that provide implementations of WS-RM are required to support the use of the SecurityTokenReference during sequence creation in order to be deemed compliant (as the current interopability scenarios indicate), then such vendors must supply an implementation of WS-Security along with their implementation of WS-ReliableMessaging. This despite the fact that 99% of their customers may not be interested in using anything more complicated than SSL/TLS to protect their web services traffic.</h:p>
>  <h:p>Although the use of the SecurityTokenReference element is described as optional, the decision on whether or not to use this option lies with the RM Source. Since there is no RM-Policy Assertion that indicates whether or not the RM Destination can accept the use of this option, negotiating the use of this option requires manual, out of band communications between the operators of the two systems. This impacts the usability of the systems that use WS-RM.
>  </h:p>
></justification>
><proposal date="2005-08-17">
>  <h:ul>
>	<h:li>
>      <h:p>Delete lines 458-461 of WS-ReliableMessaging-v1.0-wd-01</h:p>
>    </h:li>
>	<h:li>
>      <h:p>Delete lines 502-508 of WS-ReliableMessaging-v1.0-wd-01</h:p>
>    </h:li>
>  </h:ul>
></proposal>
><!-- resolution date="">[markup]</resolution -->
></issue>
>