RE: Issue LC90

Even so, a replay attack is going to be kinda futile (yes, except for a DoS) - the usual point of a replay attack is to cause something to happen again, and it won't - whoever gets the repeated message will assume it's a retransmission. It's not like multiple replays will cause the system to issue multiple airline tickets (or whatever).
 
Tony

	-----Original Message----- 
	From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
	Sent: Tue 28-Jun-05 11:32 
	To: Rogers, Tony 
	Cc: David Hull; Abbie Barbir; Christopher B Ferris; Prasad Yendluri; Francisco Curbera; public-ws-addressing@w3.org; public-ws-addressing-request@w3.org 
	Subject: Re: Issue LC90
	
	

	Rogers, Tony wrote:
	> Surely the whole point of reliable messaging is that there WON'T BE a
	> replay - reliable messaging will take all messages with the same
	> identifier (in whatever form that is) and will only present one copy of
	> the message to the layer above.
	> 
	
	This is true only if the QoS of the reliability layer is at-most-once or
	once-and-only-once; false if it is at-least-once (in which case, very
	likely multiple deliveries don't matter -- from the application
	semantics POV, but may matter from a DoS POV).
	
	-Anish
	--
	
	> Bit hard to replay-attack such a system, wouldn't you agree? Your
	> replays will be absolutely pointless; well, they might help the
	> reliability :-)
	> 
	> Tony
	>
	>     -----Original Message-----
	>     *From:* public-ws-addressing-request@w3.org on behalf of David Hull
	>     *Sent:* Tue 28-Jun-05 6:20
	>     *To:* Abbie Barbir
	>     *Cc:* Christopher B Ferris; Prasad Yendluri; Francisco Curbera;
	>     public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
	>     *Subject:* Re: Issue LC90
	>
	>     +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
	>>     > >
	>>     >
	>>     >
	>>     >
	>>
	>