- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Mon, 27 Jun 2005 16:07:42 -0400
- To: Prasad Yendluri <pyendluri@webmethods.com>
- Cc: David Hull <dmh@tibco.com>, Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
+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:08:07 UTC