[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] New Issue: remove dependency on WS-Security
Duane, The question is "optional for whom"? As I read the current draft it seems like it is optional for the RMS. This means that, as a compliant RMD, I have to be prepared to accept it. For what its worth, the current interop scenarios seem to treat this "option" as mandatory . . . Additionally, even if the STR *were* completely optional and auto-negotiable by both the RMS and RMD, its still unnecessary. In general I am against unnecessary features, regardless of how optional they may be. - g > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Wednesday, August 17, 2005 2:48 PM > To: Gilbert Pilz > Cc: ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] New Issue: remove dependency on WS-Security > > 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-Rel > iableMessaging-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 <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.</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> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]