[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] RE: Proposal for i029 "Remove dependency on WS-Security"
As well <gp/> > -----Original Message----- > From: Marc Goodner [mailto:email@example.com] > Sent: Wednesday, August 31, 2005 11:00 PM > To: Gilbert Pilz; firstname.lastname@example.org > Subject: RE: [ws-rx] RE: Proposal for i029 "Remove dependency > on WS-Security" > > Inline <mg/> > > -----Original Message----- > From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] > Sent: Wednesday, August 31, 2005 10:34 PM > To: email@example.com > Subject: [ws-rx] RE: Proposal for i029 "Remove dependency on > WS-Security" > > Sorry, but the working group decided that this is an issue. > Let's not spend time debating something we've already decided on. > > <mg>Just because the TC accepted it as an issue does not mean > that an issue is within the scope of the charter. Remember we > set a low bar for accepting issues. Indeed debate on > accepting this issue was cut short specifically so that we > could determine the charter scope issues later.</mg> > > Moving on to your excerpt from the charter; "Efficient > preservation of the integrity of reliable contexts by > composition with WS-Security or other SOAP security > mechanisms." The "preservation of the integrity of reliable > contexts" part hints at certain threat(s) against the WS-RM > sequence. To date I have not seen anyone other than myself > (http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/arch > ives/20050 > 8/msg00206.html) present any descriptions of these threats. > > <mg>Read section 5 of the RM specification, particularly > starting at line 807.</mg> <gp> This section provides a summary of common classes of attacks. All of these threats can be countered by using WSS (or other mechanisms) to sign or sign-and-encrypt the message body and the sequence header. None of these threats requires the authorization check that, according to the current draft, necessitates the inclusion of the STR in the CreateSequence message. I am interested in the specific attack that warrants the use of this authorization check. > I'm somewhat > baffled as to why the proponents of linking the WS-RM and > WS-Security specifications together via an STR in the > CreateSequence message haven't explained why this is > necessary (to be clear, when I say "explain" I mean show us > the threat model and describe to us how this counters the > threat). Given the current lack of information on this > subject, it appears that we are being asked to support a > burdensome feature for no real benefit. > > <mg>Burdensome? How is an optional element burdensome? If a > RMD and RMS don't each support WSS when one of them requires > it then they can't connect. I see no reason to go to lowest > common denominator and remove security especially when the > charter specifies that we address this.</mg> <gp>It is burdensome because it is "sender optional". This means that, in order to provide the widest range of interoperability, anyone implementing an RMD has to support this option. "Then they can't connect" isn't an acceptable answer to anybody's customer. Also, I can't honor your assertion that I am proposing to "remove security" when you haven't described the threat that this feature is supposed to secure us from. I would prefer to discuss the substantive, technical issues behind this feature but, so far, you have given me nothing to work with. > > The "composition with WS-Security or other SOAP security mechanisms" > phrase is interesting. Given that there is no clear > definition of what it means to "compose" one WS-* > specification with another this phrase could mean almost > anything. I take it to mean that we should provide exemplars > of how WS-Security should be used to bind the Sequence header > to the SOAP message body such that one cannot be separated > from another. > This measure counters a specific threat that I would be glad > to discuss with you. > > > <mg>Again, read section 5 of the RM spec where that is > covered explicitly.</mg> <gp>As I said, section 5 only lists a number of general security concerns. There is nothing in there that serves to motivate the described authorization check. > I certainly don't read this phrase to mean that WS-RM must > support a per-message authorization check against an STR that > is provided during sequence creation. > > <mg>You are proposing removing existing composability with > WSS, how is that consistent with the charter?</mg> <gp>We clearly disagree on what "composability with WSS" means. I don't view my proposal as being inconsistent with the charter. > > - g > > ________________________________ > > From: Marc Goodner [mailto:firstname.lastname@example.org] > Sent: Wednesday, August 31, 2005 5:51 PM > To: Gilbert Pilz; email@example.com > Subject: Proposal for i029 "Remove dependency on WS-Security" > > > > This is not an issue. There is no reason we should > remove the STR and the charter of this TC is clear that this > is in our scope. > > > > Proposal: > > The WS-RX TC charter is clear, "Efficient preservation > of the integrity of reliable contexts by composition with > WS-Security or other SOAP security mechanisms." The > specification currently provides such composition with WSS > via the inclusion of the SecurityTokenReference in the > CreateSequenceRequest as well as providing an extensibility > point for other mechanisms. Removing this would be in direct > conflict with the related scope statement in the charter, > therefore this issue should be closed with no action. > > > > >