RE: Issue LC90

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