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 16:20:09 -0400
To: Abbie Barbir <abbieb@nortel.com>
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, Prasad Yendluri <pyendluri@webmethods.com>, Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-id: <42C05F79.40605@tibco.com>
+1 as well :-)

I think we all agree now that, despite my mis-statement, the RM* ID will
also not change with a retransmission.

This doesn't change anything with respect to LC90.  The point is still
that the [message id] doesn't change with a retransmission (assuming
it's there at all), and therefore SHOULD NOT be used in detecting replays.

Re-reading the current text for the nth time, I think what it's trying
to say is that the /message/ should include a timestamp or other datum
that /does/ change with a retransmission, but that's not what it says.

Again, I'm perfectly fine with taking the current text out entirely and
leaving such discussion to the security-related specifications.  If it
does stay, though, it needs to be clearer.  It should either say more
clearly that a /message /should include a timestamp or whatever truly
unique (and securely signed) datum, or (my preference) just say clearly
that [message id] is not that datum and leave the rest to the security
specs.

Abbie Barbir wrote:

>
> +1
> abbie
>
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > Christopher B Ferris
> > Sent: Monday, June 27, 2005 4:08 PM
> > To: Prasad Yendluri
> > Cc: David Hull; Francisco Curbera;
> > public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> > Subject: Re: Issue LC90
> >
> >
> >
> > +1
> >
> > The retransmission will have the same
> > Sequence/Identifier+MessageNumber as
> > the original. It doesn't change.
> > I believe the same could be said of ws-reliability.
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> >
> > public-ws-addressing-request@w3.org wrote on 06/27/2005 03:50:20 PM:
> >
> > >
> > >
> > > David Hull wrote:
> > > 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.
> > > Actually my understanding is quite the opposite. The
> > sequence Id and
> > > the
> > messageNumber in sequence
> > > must remain the same for retransmissions. Where as no such
> > requirement
> > on timestamp. I don't
> > > believe retransmissions will have a separate sequence number. The
> > messageId stays the same. Given
> > > that I think it is useful to state this..
> > > 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 20:20:23 GMT

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