- From: David Hull <dmh@tibco.com>
- Date: Mon, 27 Jun 2005 16:20:09 -0400
- To: Abbie Barbir <abbieb@nortel.com>
- Cc: Christopher B Ferris <chrisfer@us.ibm.com>, Prasad Yendluri <pyendluri@webmethods.com>, Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
- Message-id: <42C05F79.40605@tibco.com>
+1 as well :-) I think we all agree now that, despite my mis-statement, the RM* ID will also not change with a retransmission. This doesn't change anything with respect to LC90. The point is still that the [message id] doesn't change with a retransmission (assuming it's there at all), and therefore SHOULD NOT be used in detecting replays. Re-reading the current text for the nth time, I think what it's trying to say is that the /message/ should include a timestamp or other datum that /does/ change with a retransmission, but that's not what it says. Again, I'm perfectly fine with taking the current text out entirely and leaving such discussion to the security-related specifications. If it does stay, though, it needs to be clearer. It should either say more clearly that a /message /should include a timestamp or whatever truly unique (and securely signed) datum, or (my preference) just say clearly that [message id] is not that datum and leave the rest to the security specs. Abbie Barbir wrote: > > +1 > abbie > > > -----Original Message----- > > From: public-ws-addressing-request@w3.org > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > Christopher B Ferris > > Sent: Monday, June 27, 2005 4:08 PM > > To: Prasad Yendluri > > Cc: David Hull; Francisco Curbera; > > public-ws-addressing@w3.org; public-ws-addressing-request@w3.org > > Subject: Re: Issue LC90 > > > > > > > > +1 > > > > The retransmission will have the same > > Sequence/Identifier+MessageNumber as > > the original. It doesn't change. > > I believe the same could be said of ws-reliability. > > > > Cheers, > > > > Christopher Ferris > > STSM, Emerging e-business Industry Architecture > > email: chrisfer@us.ibm.com > > blog: http://webpages.charter.net/chrisfer/blog.html > > phone: +1 508 377 9295 > > > > public-ws-addressing-request@w3.org wrote on 06/27/2005 03:50:20 PM: > > > > > > > > > > > David Hull wrote: > > > If a message is retransmitted for reliability purposes, the payload > > (that is, the message the > > > reliability layer thinks it's sending) will be > > retransmitted verbatim. > > The [message id] is part > > > of this, so it will be the same in both versions, just as the other > > > WSA > > headers will be, and the > > > body for that matter. There will be no part of the message payload > > > that > > could be used to tell if > > > the message is a replay or a retransmission. This is why the > > reliability layer uses its own > > > sequence number. The retransmission will have a separate sequence > > number. The security layer can > > > use this information to distinguish retransmissions from > > replays. It > > can't use anything in the payload. > > > Actually my understanding is quite the opposite. The > > sequence Id and > > > the > > messageNumber in sequence > > > must remain the same for retransmissions. Where as no such > > requirement > > on timestamp. I don't > > > believe retransmissions will have a separate sequence number. The > > messageId stays the same. Given > > > that I think it is useful to state this.. > > > The current text says that the security layer should take care to > > consider information that will > > > not change when trying to see if anything has changed. The new text > > points out that the [message > > > id] will not change with a retransmission and looking at it won't > > > help. > > Further, it uses a SHOULD > > > NOT, instead of a MUST NOT, so that anyone who really wants > > to fold in > > redundant information is > > > free to do so. > > > > > > Francisco Curbera wrote: > > > Issue LC90 proposes changing the following paragraph in the security > > > section, > > > > > > "Some processors may use message identifiers ([message id]) > > as part of > > > a uniqueness metric in order to detect replays of messages. Care > > > should be taken to ensure that for purposes of replay > > detection, the > > > message identifier is combined with other data, such as a > > timestamp, > > > so that a legitimate retransmission of the message is not confused > > > with a replay attack." > > > > > > to the alternate text, > > > > > > "For purposes of reliability and security, the [message id] property > > SHOULD > > > regarded simply as another part of the message payload. It > > SHOULD NOT > > be > > > used as part of a uniqueness metric in order to detect replays of > > messages, > > > as a message with a given [message id] may be legitimately > > re-sent for > > > purposes of reliable transmission." > > > > > > We think that there is no justification to say that you one > > cannot use > > > messageID as part of an uniqueness criterion for security > > purposes, so > > the > > > "SHOULD NOT" in the proposed text is unjustified. The > > original text is > > more > > > balanced, recognizing that message_if may be used and > > giving the right > > > advice if one chooses to do so. > > > > > > I propose we close with no change. > > > > > > Paco > > > > > > > > > >
Received on Monday, 27 June 2005 20:20:23 UTC