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:18:44 -0400
To: David Hull <dmh@tibco.com>
Cc: public-ws-addressing@w3.org
Message-ID: <OF0D242F27.F2A9ABE0-ON8525702D.0068B272-8525702D.006A163F@us.ibm.com>

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.

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

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