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

Re: Issue LC90

From: David Hull <dmh@tibco.com>
Date: Mon, 27 Jun 2005 15:59:42 -0400
To: Prasad Yendluri <pyendluri@webmethods.com>
Cc: Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org
Message-id: <42C05AAE.9020200@tibco.com>
Prasad Yendluri wrote:

> 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..

Oops.  You're right, the RM id numbers don't change, so you can't use
them either.

>> 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
>>>"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
>>>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.
Received on Monday, 27 June 2005 19:59:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC