W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: Issue LC90

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
Message-ID: <OFB1515369.C5396AD2-ON8525702D.006AB5C3-8525702D.006ACD36@us.ibm.com>

Again, my understanding is that you filter our replay attacks before you do
anything else, including RM.


                      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                                                            

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?


>                      David Hull

>                      <dmh@tibco.com>          To:       Francisco
>                                               cc:
>                      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.
>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
>      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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC