- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Mon, 27 Jun 2005 15:26:33 -0400
- To: David Hull <dmh@tibco.com>
- Cc: public-ws-addressing@w3.org
Again, my understanding is that you filter our replay attacks before you do
anything else, including RM.
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
>
>
>
>
>
>
>
>
>
Received on Monday, 27 June 2005 19:26:38 UTC