W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: Issue LC90

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
Message-ID: <OF5DBF7322.DAA047B0-ON8525702D.006E2556-8525702D.006E9187@us.ibm.com>

+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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT