- From: Tom Rutt <tom@coastin.com>
- Date: Mon, 27 Jun 2005 15:45:10 -0400
- To: Francisco Curbera <curbera@us.ibm.com>
- CC: David Hull <dmh@tibco.com>, public-ws-addressing@w3.org
Francisco Curbera wrote: >Again, my understanding is that you filter our replay attacks before you do >anything else, including RM. > > The retransmission in both ws-reliablity and ws-reliable messaging specs uses the same sequenceID message number pair as the original request, not a new one. The rm spec uses its own sequenceID, sequenceID pair because it needs to work even when ws addressing is not in use. Tom Rutt >Paco > > > > > David Hull > <dmh@tibco.com> To: Francisco Curbera/Watson/IBM@IBMUS > cc: public-ws-addressing@w3.org > 06/27/2005 03:20 Subject: Re: Issue LC90 > PM > > > > > >Francisco Curbera wrote: > > > >>This is a composability issue. My understanding is that typically the >>timestamp would protect the RM headers as well, so they will be different >>in a retransmission. >> >> >> >> >So, in this case, what should the security layer look at? > > > >>Paco >> >> >> >> >> >> >> > > > >> David Hull >> >> > > > >> <dmh@tibco.com> To: Francisco >> >> >Curbera/Watson/IBM@IBMUS > > >> cc: >> >> >public-ws-addressing@w3.org > > >> 06/27/2005 02:03 Subject: Re: Issue LC90 >> >> > > > >> PM >> >> > > > > > > >> >> >>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. >> >>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 >> >> >> >> >> >> >> >> >> >> >> > > > > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Monday, 27 June 2005 19:45:23 UTC