Subject: [core] Symmetry, or Stuffing state in etag

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 04:43:22 -0600

Let's try it this way:

Token is an opaque sequence introduced by a client to correlate a response
with a previous request.

Etag is an opaque sequence introduced by a server to correlate a request
with (the content in) a previous response.

A client may choose to embed information in a request Token, and extract
that information when a response Token is received.  To accommodate this
use, Token must be large enough to hold this embedded information as well as
a MAC to ensure the information is valid.

Use case: the client is transferring a large block of memory to a server.
It uses the Token to encode the address of the next block to transfer.  When
it receives the response, it decodes the Token value to determine how much
data to send from what address.

A server may choose to embed information in a response Etag, and extract
that information when a subsequent request provides an Etag.  To accommodate
this use, Etag must be large enough to hold this embedded information as
well as a MAC to ensure the information is valid.

Use case: the server wishes to track how information it provides is
distributed.  Upon a request with no Etag, the server creates a data
structure holding information about the client.  It embeds the address of
this data structure in the Etag.  When it receives a request with an Etag,
it dereferences the pointer to see whether this client is in the list of
"friends" who have shared data with the original requester.

Either use case could be easily accommodated by using the value as a small
opaque key to identify locally stored (protected) information that never
goes out in a message, avoiding the whole problem, but that's not the point
here.  The situations are symmetric, and should be handled the same way.
That historically the draft says an end-point (including the server?) MUST
make no assumptions about the format of an Etag value, but did not use the
same language for Token, is an uncompelling reason to treat them
differently.

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Nov 2010 06:57:40 -0800

I don't think this is a very useful analogy. We're deliberately
contemplating the use of tokens as a
form of state transfer from one side to another. If we're doing so, we need
to address the security
issue. By contrast, Etags are intended purely as a check for whether two
versions of a resource
match and are not intended to be interpreted. If someone *did* decide to use
them the way you
suggest, then they of course would need to add security features. However,
since this is not
the intended use of etags, the situation is different.

-Ekr

On Tue, Nov 9, 2010 at 2:43 AM, Peter Bigot <[email-masked]> wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 09:44:07 -0600

Well, no.  We're deliberately contemplating the use of tokens as a form of
state transfer from a node back to itself.   While exposing the state to
modification by hopping it through a series of other nodes.  As opposed to
keeping the state at the client and using Token as a key to match the
response to a specific request and its locally-retained state.

I don't believe anybody's claimed that an end-point other than the
originating client is entitled to extract information from the Token, so
there's no intent to support state transfer from one side to another via
content in Token.  Has somebody suggested this use, and I've missed it?

I am unconvinced that supporting interpretation of a response on a node that
doesn't remember the original request is worth this level of effort.  The
whole problem goes away if we simply treat Etag and Token as the same sort
of thing, and accept that a client that doesn't remember the request for
which it receives a response should reply with a RST like the draft
suggests.

Peter

On Tue, Nov 9, 2010 at 8:57 AM, Eric Rescorla <[email-masked]> wrote:

> match and are not intended to be interpreted. If someone *did* decide to
> use them the way you

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Nov 2010 08:01:23 -0800

On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot <[email-masked]> wrote:

> state transfer from a node back to itself.

Yes, that's what creates the security issue, because the node which is
transiting the state is untrusted.

> I am unconvinced that supporting interpretation of a response on a node
> that doesn't remember the original request is worth this level of effort.
> The whole problem goes away if we simply treat Etag and Token as the same
> sort of thing, and accept that a client that doesn't remember the request
> for which it receives a response should reply with a RST like the draft
> suggests

I don't understand what point you're making.

If the Token is relied upon in any way such that modification of the token
would cause the processing
side to do anything other than fail the connection than it must be
protected.

-Ekr

---

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 10:07:14 -0600

Is there a security issue if a node simply generates a random N-byte value
(pick your N, I'd say 4), uses that as Token, and when it gets a response
sees whether it has an outstanding request associated with that value?

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Nov 2010 08:13:28 -0800

Quite possibly, unless it also checks that the responder is associated with
that Token.

-Ekr

On Tue, Nov 9, 2010 at 8:07 AM, Peter Bigot <[email-masked]> wrote:

>> On Tue, Nov 9, 2010 at 7:44 AM, Peter Bigot <[email-masked]>wrote:
>>
>>> Well, no.  We're deliberately contemplating the use of tokens as a form
>>> of state transfer from a node back to itself.
>>
>>

---

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 11:05:52 -0600

Then a client should follow that procedure (including checking the responder
against the target of the original request) and there's no need to suggest
that implementations are entitled to put other information in the Token but
should add a MAC if they do so.  Security risk eliminated, message size
decreased, concept of what Token is for simplified.

What I'm saying is that the intended use of Token was like Etag, and
extending it to a purpose that requires addition of a MAC to be secure
should be rejected as it is proposed only for use cases that are neither
common nor compelling.

Peter

On Tue, Nov 9, 2010 at 10:13 AM, Eric Rescorla <[email-masked]> wrote:

>>> If the Token is relied upon in any way such that modification of the
>>> token would cause the processing

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Nov 2010 10:09:25 -0800

On Tue, Nov 9, 2010 at 9:05 AM, Peter Bigot <[email-masked]> wrote:

> Then a client should follow that procedure (including checking the
> responder against the target of the original request) and there's no need to
> suggest that implementations are entitled to put other information in the
> Token but should add a MAC if they do so.  Security risk eliminated, message
> size decreased, concept of what Token is for simplified.
>

Once again, there has been a discussion of putting other data into the
token, at which point there
are other issues. I'm not addressing the wisdom of that proposal, but merely
the security
measures which must be taken if it is to be implemneted.

-Ekr

---

From: Robert Quattlebaum <[email-masked]>
Date: Tue, 9 Nov 2010 14:13:54 -0800

On Nov 9, 2010, at 9:05 AM, Peter Bigot wrote:

> What I'm saying is that the intended use of Token was like Etag, and extending it to a purpose that requires addition of a MAC to be secure should be rejected as it is proposed only for use cases that are neither common nor compelling.

From what I have gathered, there is only one proposal that has any significant impact on the CoAP spec: To increase the valid size of the value of a Token option from 2 bytes to a larger TBD size. I've seen a size of 16 thrown around, which seems reasonable to me.

I'm not sure why increasing the valid size of the value that this option may carry to 16 would cause any significant additional implementation complications, even for constrained devices. Doing so would increase the flexibility of client implementations.

One point about etags is that they are intended to be used by the client for performing comparisons to determine if a resource has changed or not. A server which uses the etag in such a way that would break this behavior (which your use case seems to do) would be out-of-spec.

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/

---

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 16:38:21 -0600

OK, valid point.  Comes from trying to get tricky.  Still, based on what
Eric's explained, servers won't be able to securely interpret what they see
in an Etag either unless CoAP increases the size of Etag to accommodate a
MAC.  I could probably contrive a conforming situation, but it's not really
relevant at this point.  I just thought to reduce the number of concepts
involved by treating Etag and Token as duals.

I certainly have no standing to object when other folks try to use CoAP in
unintended ways, except of course that the way I want to use it has been
ruled out by the pending decision not to support redirection to another
end-point and/or protocol.  Pity; that capability is certainly useful in the
real world of web services, even if it can be a security risk if not done
properly.  (Kinda like embedding state in tokens.)

Peter

On Tue, Nov 9, 2010 at 4:13 PM, Robert Quattlebaum <[email-masked]>wrote:

> One point about etags is that they are intended to be used by the client
> for performing comparisons to determine if a resource has changed or not. A
> server which uses the etag in such a way that would break this behavior
> (which your use case seems to do) would be out-of-spec.
>
> __________________
> Robert Quattlebaum

---

From: Robert Quattlebaum <[email-masked]>
Date: Tue, 9 Nov 2010 15:35:17 -0800

On Nov 9, 2010, at 2:38 PM, Peter Bigot wrote:

> OK, valid point.  Comes from trying to get tricky.  Still, based on what Eric's explained, servers won't be able to securely interpret what they see in an Etag either unless CoAP increases the size of Etag to accommodate a MAC.  I could probably contrive a conforming situation, but it's not really relevant at this point.  I just thought to reduce the number of concepts involved by treating Etag and Token as duals.

Actually, after reviewing the spec, I see no explicit language which indicates that a client can derive any useful information by comparing etags for equality. In fact the existing language appears to imply the contrary, so strictly speaking your example still stands---at least as far as coap-03 is concerned. I could argue that perhaps the language in coap-03 regarding etags should be modified a bit, but I'll leave that for a different discussion.

I think a significant distinction between etags and tokens is that tokens are used to aide the interpretation of responses received by the client. Etags serve no such purpose for the server, and exist solely to determine if a resource has changed since the last time you accessed it. These are considerably different purposes, so I don't think there is any technical (or even aesthetic) benefits to making their definitions symmetric in ways which are not supported by reasonable use cases.

I think the most significant concern for increasing the Token size is what sort of impact such a change would have on CoAP server implementations, IMHO.

__________________
Robert Quattlebaum

---

From: Robert Cragie <[email-masked]>
Date: Wed, 10 Nov 2010 01:48:17 +0000

Comments below, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

>> OK, valid point.  Comes from trying to get tricky.  Still, based on what Eric's explained, servers won't be able to securely interpret what they see in an Etag either unless CoAP increases the siz…
<RCC>So are we agreed that an etag and a token are not the same? Clearly 
if you abstract both concepts there are commonalities but as they stand 
with their specific definitions they are not the same.</RCC>
> I think a significant distinction between etags and tokens is that tokens are used to aide the interpretation of responses received by the client. Etags serve no such purpose for the server, and ex…
<RCC>
Actually that is one property which is the same in an etag and a token. 
If you consider a server response and a subsequent client request for an 
etag as analagous to the client request and subsequent response for a 
token, the returned etag is used for matching like a token. However for 
an etag there is implied subsequent processing regarding what will then 
go into the acoompanying payload; this does not exist with a token.

If we really want this sort of symmetry (and I'm not sure we do) then we 
would probably need to have a token which is only oprionally returned. 
That could then hold an etag.
</RCC>

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Nov 2010 09:51:37 +0800

On 11/10/10 9:48 AM, Robert Cragie wrote:
> So are we agreed that an etag and a token are not the same?

Yes, they're very different things. The etag is selected by the server, 
is opaque to the client, and corresponds to the current state of the 
resource. The token is selected by the client, is opaque to the server, 
and corresponds to a CoAP request.

/a

---

From: Robert Cragie <[email-masked]>
Date: Wed, 10 Nov 2010 01:55:55 +0000

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 09/11/2010 10:38 PM, Peter Bigot wrote:
> OK, valid point.  Comes from trying to get tricky.  Still, based on 
> what Eric's explained, servers won't be able to securely interpret 
> what they see in an Etag either unless CoAP increases the size of Etag 
> to accommodate a MAC.  I could probably contrive a conforming 
> situation, but it's not really relevant at this point.  I just thought 
> to reduce the number of concepts involved by treating Etag and Token 
> as duals.
<RCC>That's true but the use of etags (well, formal use at least) does 
not require it. There would be point in applying a MAC to the etag as 
the server has no subsequent use for it beyond determining what it puts 
in a corresponding response. All a 'malicious' client is going to do is 
revert to the worst case re. caching, i.e. return the resource 
representation every time. Ironically, etags are being used as tokens 
for sneaky cookies based on browsers always caching.</RCC>
>
> I certainly have no standing to object when other folks try to use 
> CoAP in unintended ways, except of course that the way I want to use 
> it has been ruled out by the pending decision not to support 
> redirection to another end-point and/or protocol.  Pity; that 
> capability is certainly useful in the real world of web services, even 
> if it can be a security risk if not done properly.  (Kinda like 
> embedding state in tokens.)
>
> Peter
>
> On Tue, Nov 9, 2010 at 4:13 PM, Robert Quattlebaum <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     One point about etags is that they are intended to be used by the
>     client for performing comparisons to determine if a resource has
>     changed or not. A server which uses the etag in such a way that
>     would break this behavior (which your use case seems to do) would
>     be out-of-spec.
>
>     __________________
>     Robert Quattlebaum
>     Jabber: [email-masked] <mailto:[email-masked]>
>     eMail: [email-masked] <mailto:[email-masked]>

---

From: Kepeng Li <[email-masked]>
Date: Wed, 10 Nov 2010 10:16:10 +0800

Hi,

In the COAP draft, we use "Subscription-lifetime" as the Option name, but in
the Observe draft, we use "lifetime". This should be consistent.

Thanks

Cheers

Kepeng

---

From: Zach Shelby <[email-masked]>
Date: Wed, 10 Nov 2010 10:37:45 +0800

On Nov 10, 2010, at 10:16 AM, Kepeng Li wrote:

> In the COAP draft, we use “Subscription-lifetime” as the Option name, but in the Observe draft, we use “lifetime”. This should be consistent.

Yes, we will do that. In ticket #33 the naming will be changed to Observation-lifetime throughout the documents. We will stop using "subscription/subscribe" all together. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297