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

Re: Issue LC90

From: David Hull <dmh@tibco.com>
Date: Mon, 27 Jun 2005 15:20:40 -0400
To: Francisco Curbera <curbera@us.ibm.com>
Cc: public-ws-addressing@w3.org
Message-id: <42C05188.9010509@tibco.com>

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:20:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT