RE: Issue LC90

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