Subject: [core] Stuffing state in tokens

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2010 23:39:58 -0800

As a general matter if you're going to have a token that has state in it
that would be advantageous to someone who has the token to modify
then you need to protect the token. So, the question then becomes
how difficult it is for an attacker to generate a new, valid token with
a different state.

The classic way to generate these tokens (see for instance,
http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01) is to
have some payload plus an integrity check (MAC). So you have
a token composed of:

P || M

Where P is the payload and M is the MAC.

Say that the attacker generates an arbitrary payload P' and then generates
a random MAC M', the chance that the MAC is valid is 2^{-m} where m is the
length of the MAC. In most cases, a forgery probability of 2^{-64} is
considered
the minimum acceptable limit with 2^{-80} being preferred. This implies a
MAC
of at least 8-10 bytes. Now, perhaps there is some argument that in this
case
the risk of forgery is lower, but I don't see how it's going to be
acceptable
at less than a 4 byte (2^{-32} probability) MAC and we only accepted that
for SRTP because there was an argument that a single forged media sample
was a low risk. I don't see that that applies here.

-Ekr

---

From: Peter Bigot <[email-masked]>
Date: Mon, 8 Nov 2010 12:12:50 -0600

When introduced in draft-bormann-coap-misc-05, Token was specifically an
opaque transaction-layer header introduced to eliminate the need to perform
complex comparisons on URI fields to correlate an asynchronous response with
a request.

What is the motivation for extending this simple concept of a
transaction-layer key interpretable only on the client into a back-door
mechanism to convey meaningful state from client to server outside the
message body, or to transport it to and from the server rather than retain
it on the client?

If it serves only this correlation role, is there a security aspect that
needs to be addressed (that isn't naturally addressed by protecting the
entire message)?

Peter

On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2010 10:15:10 -0800

> message body, or to transport it to and from the server rather than retain

I didn't say there was. This was raised in the meeting and I'm attempting
to discuss the security issues.

> needs to be addressed (that isn't naturally addressed by protecting the

Well, in general if tokens are short and guessable, then there are some
potential attacks.

-ekr

---

From: Peter Bigot <[email-masked]>
Date: Mon, 8 Nov 2010 12:30:51 -0600

On Mon, Nov 8, 2010 at 12:15 PM, Eric Rescorla <[email-masked]> wrote:

> On Mon, Nov 8, 2010 at 10:12 AM, Peter Bigot <[email-masked]>wrote:
>

My hope was that understanding what sort of state somebody wants to put in
there and why would help illuminate what, if any, security issues are
present.  If the state is not advantageous to anybody except the client,
then from what you wrote it may not be necessary to protect it.

> Well, in general if tokens are short and guessable, then there are some

Yes.  I would hope that using whole-message encryption would eliminate that
potential.  I suppose somebody might conceive of a practice where a client
encrypted a token in an otherwise clear message, and the server responded by
re-encrypting it as a form of authenticating the response.  Perhaps that's a
case we need to account for in the threat model.  Otherwise there's really
no need to guess the token: an adversary can just extract it from a snooped
request, and return it in a spoofed response.

Peter

---

From: Robert Quattlebaum <[email-masked]>
Date: Mon, 8 Nov 2010 11:46:46 -0800

Hello Peter!

On Nov 8, 2010, at 10:12 AM, Peter Bigot wrote:

> When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate an asynchronous response with a request.
> 
> What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body, or to transport it to and from the server rather than retain it on the client?

Those are two distinct scenarios, the first of which effectively breaks the current assumptions about the Token header being opaque. I believe the second scenario is what is interesting here.

Here are some example cases:

The token header could be used to implement a stateless sliced/blocked POST upload. The token would be used to contain the state of what has been sent so far and what else needs to be sent. If the upload consists of discrete records, the token could be used to describe the next record to send, and perhaps an integer describing an offset into the record for cases where the last record was truncated and needs to be continued in the next transaction. The client simply starts the ball rolling by sending the first packet. After that, the upload would drive itself with no state.

For sliced/blocked GET requests, imagine a case where a constrained device does a GET request for records from a database. It performs a specific action on each record retrieved, as they are retrieved. In cases where the responses contain partial records, the token parameter could be used to help the client fill-in-the-blanks when a record is split across a packet boundary. Otherwise the client would need to keep state of the last partial record received in order to make sense of the second half of the record in the next response.

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

---

From: Robert Quattlebaum <[email-masked]>
Date: Mon, 8 Nov 2010 11:57:01 -0800

Hello Peter!

On Nov 8, 2010, at 10:30 AM, Peter Bigot wrote:

> My hope was that understanding what sort of state somebody wants to put in there and why would help illuminate what, if any, security issues are present.  If the state is not advantageous to anybody except the client, then from what you wrote it may not be necessary to protect it.

Lets say you wanted to implement a stateless sliced POST upload of some resource from memory for some reason. You could use the token to store a pointer to the next byte of data and an integer describing how much more data needs to be transferred. This would work great, and you would get a fully automatic stateless POST upload, but it has serious security issues: if an attacker knows what you are storing in the token and the client doesn't do any sanity checks then the attacker could effectively dump all of RAM. Ouch.

While the token's contents are only useful to the client from a protocol perspective, that doesn't mean that the client can trust that it was always the one who generated the incoming token. If we allow arbitrary data to be kept in the Token option, then we should encourage implementors to not assume that token in a response has not been tampered with.

__________________
Robert Quattlebaum

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2010 12:04:51 -0800

On Mon, Nov 8, 2010 at 11:57 AM, Robert Quattlebaum <[email-masked]>wrote:

> > My hope was that understanding what sort of state somebody wants to put
> in there and why would help illuminate what, if any, security issues are
> Lets say you wanted to implement a stateless sliced POST upload of some
> resource from memory for some reason. You could use the token to store a
> pointer to the next byte of data and an integer describing how much more
> data needs to be transferred. This would work great, and you would get a
> fully automatic stateless POST upload, but it has serious security issues:
> if an attacker knows what you are storing in the token and the client
> doesn't do any sanity checks then the attacker could effectively dump all of
> RAM. Ouch.
>

Exactly. This is a pretty well-known tyoe of attack on state tokens.

> While the token's contents are only useful to the client from a protocol
> perspective, that doesn't mean that the client can trust that it was always
> the one who generated the incoming token. If we allow arbitrary data to be
> kept in the Token option, then we should encourage implementors to not
> assume that token in a response has not been tampered with.

I disagree with this. Rather, the tokens should be cryptographically
protected so that they cannot be
tampered.

-Ekr

---

From: Robert Quattlebaum <[email-masked]>
Date: Mon, 8 Nov 2010 12:26:33 -0800

Hello Eric!

On Nov 8, 2010, at 12:04 PM, Eric Rescorla wrote:

> On Mon, Nov 8, 2010 at 11:57 AM, Robert Quattlebaum <[email-masked]> wrote:
> I disagree with this. Rather, the tokens should be cryptographically protected so that they cannot be
> tampered.

I think that cryptographically protecting a state payload contained in a token is a strategy for dealing with the fact that you cannot trust that the token has not been tampered with.

I believe that this should ultimately be an implementation decision (albeit highly recommended).

For example, imagine a case where we use a token to contain the index of the next record to put in the following request. If this value is range-checked by the client (and the client always uploads all records) then there is no need to cryptographically protect the token, IMHO.

__________________
Robert Quattlebaum

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 06:54:26 +0800

> When introduced in draft-bormann-coap-misc-05, Token was specifically an opaque transaction-layer header introduced to eliminate the need to perform complex comparisons on URI fields to correlate a…

(Actually, that was not the original reason, but this is indeed one use.)

> What is the motivation for extending this simple concept of a transaction-layer key interpretable only on the client into a back-door mechanism to convey meaningful state from client to server outside the message body,

No.  The token is the client's data and entirely opaque to the server.  I'm not aware of anybody trying to change that.
(In some followup messages there is a reference to the continuation options of my thought experiment http://tools.ietf.org/html/draft-bormann-core-coap-block-01.  These are completely different, as they are the server's data and opaque to the client, but they do raise exactly the same security considerations.)

> or to transport it to and from the server rather than retain it on the client?
> 
> If it serves only this correlation role, is there a security aspect that needs to be addressed (that isn't naturally addressed by protecting the entire message)?

The entire discussion was about providing enough space in the token so that a client that does want to put information in a token that needs to be protected can do that.  8 bytes is borderline for that purpose, but may be good enough.

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 09 Nov 2010 02:55:25 +0000

Hi Peter,

The point is that it is just an opaque chunk of data returned to the 
client. I think too many assumptions are being made about what is being 
carried in that data. If it is simply classified as opaque, it could be 
anything

On that basis, protecting the client to/from server messages isn't 
sufficient. That will give:

    * the server data origin integrity of the client data
    * the client data origin integrity of the server data

but it won't give is:

    * the client data origin integrity of the client data it itself produced

So applying the MAC seems like a good idea to me in certain situations, 
although given the opacity of the data, it is integral to the data 
itself and therefore may only need to be recommended in the 
specification, so the extended length of the field should suffice.

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/>

On 08/11/2010 6:12 PM, Peter Bigot wrote:
> When introduced in draft-bormann-coap-misc-05, Token was specifically 
> an opaque transaction-layer header introduced to eliminate the need to 
> perform complex comparisons on URI fields to correlate an asynchronous 
> response with a request.
>
> transaction-layer key interpretable only on the client into a 
> back-door mechanism to convey meaningful state from client to server 
> outside the message body, or to transport it to and from the server 
> rather than retain it on the client?
>
> If it serves only this correlation role, is there a security aspect 
> that needs to be addressed (that isn't naturally addressed by 
> protecting the entire message)?
>
> Peter
>
> On Mon, Nov 8, 2010 at 1:39 AM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     length of the MAC. In most cases, a forgery probability of 2^{-64}
>     is considered
>     the minimum acceptable limit with 2^{-80} being preferred. This
>     implies a MAC
>     of at least 8-10 bytes. Now, perhaps there is some argument that
>     in this case
>     [email-masked] <mailto:[email-masked]>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 9 Nov 2010 13:29:24 +0800

On Nov 9, 2010, at 10:55 AM, Robert Cragie wrote:

> So applying the MAC seems like a good idea to me in certain situations, although given the opacity of the data, it is integral to the data itself and therefore may only need to be recommended in the specification, so the extended length of the field should suffice.

I totally agree. So now we need to decide what that length should be. If we need an 8-10 byte MAC, I guess a Token Option length up to 16 bytes would suffice?

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

---

From: Tobias Heer <[email-masked]>
Date: Tue, 09 Nov 2010 14:27:35 +0800

Hi,

Am 09.11.2010 um 10:55 schrieb Robert Cragie:

> Hi Peter,
> 
> The point is that it is just an opaque chunk of data returned to the client. I think too many assumptions are being made about what is being carried in that data. If it is simply classified as opaque, it could be anything
> 
> On that basis, protecting the client to/from server messages isn't sufficient. That will give:
> the server data origin integrity of the client data
> the client data origin integrity of the server data
> but it won't give is:
> the client data origin integrity of the client data it itself produced
In addition to adding a MAC, one should also think about replay protection. Otherwise, it may be possible to reset a client to a state that corresponds to a previous (valid and authenticated) token. Staying completely stateless may not allow for such replay protection in all cases.

I agree that the exact use of the token should not be fully specified in the document but should be left to implementors. However, it might help to give implementors some guidance in designing it properly (in the form of recommendations).

Tobias

> http://www.gridmerge.com
>> length of the MAC. In most cases, a forgery probability of 2^{-64} is considered
>> the minimum acceptable limit with 2^{-80} being preferred. This implies a MAC
>> of at least 8-10 bytes. Now, perhaps there is some argument that in this case
>> the risk of forgery is lower, but I don't see how it's going to be acceptable

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

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

Alright, I'm completely confused.

I'm pretty sure neither Carsten nor darco were saying that Token is now
supposed to incorporate a MAC for the entire message, which sounds like what
you (Robert Cragie) are describing.  Great idea to support a message-level
MAC, but it should be a different option.

>From the original description:

   In addition to the context provided by including the URI again in
   delayed responses, we propose adding a "Token" option, which can be
   included in GET, PUT, POST, DELETE messages, and is echoed back in
   exactly those cases where the URI is echoed back.  The Token allows a
   recipient of an asynchronous message to relate back to an earlier
   request and thus can be used as the long-term equivalent of what TID
   is for a single transaction.  The Token option value is a sequence of
   bytes, which is opaque to the server.

we now want to use Token to drag client data on a round trip to the server
so that clients doing things like multi-part post don't need to keep track
of what they're doing?  Furthermore, we want to turn that single header
value into a nano-message complete with its own internal MAC so it can be
protected independently of the whole message?

I swear, I have no idea what we're trying to accomplish here, but Rube
Goldberg would be jealous.

Peter

On Mon, Nov 8, 2010 at 8:55 PM, Robert Cragie
<[email-masked]>wrote:

>    - the server data origin integrity of the client data
>     - the client data origin integrity of the server data
>
> but it won't give is:
>
>    - the client data origin integrity of the client data it itself
>    produced
>
> although given the opacity of the data, it is integral to the data itself
> and therefore may only need to be recommended in the specification, so the
> extended length of the field should suffice.
>
> Robert
>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>

---

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

> MAC, but it should be a different option.

OK, sorry, misread---that's not what you were saying.

The rest of my point stands.

Peter

---

From: Robert Cragie <[email-masked]>
Date: Tue, 09 Nov 2010 10:53:40 +0000

Hi Peter,

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

Robert

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

On 09/11/2010 8:07 AM, Peter Bigot wrote:
> I'm pretty sure neither Carsten nor darco were saying that Token is 
> now supposed to incorporate a MAC for the entire message, which sounds 
> like what you (Robert Cragie) are describing.  Great idea to support a 
> message-level MAC, but it should be a different option.
<RCC>That's not what I was describing but you realise that in your later 
e-mail.</RCC>
> we now want to use Token to drag client data on a round trip to the 
> server so that clients doing things like multi-part post don't need to 
> keep track of what they're doing?  Furthermore, we want to turn that 
> single header value into a nano-message complete with its own internal 
> MAC so it can be protected independently of the whole message?
<RCC>But that's what a token is. If it is an opaque sequence of bytes, 
it could carry my pet dog's name, for all the server cares. If the 
client has short term partial memory loss, it would ike to know that 
what the server echoes back is indeed what it sent out in the first 
place. The point is securing the original client message and the 
returning server message individually does not achieve that. I am not 
saying that you must add a MAC but that it is recommended in certain 
cases and therefore the length should be able to accommodate it. I don't 
see many changes to the draft arising from this.</RCC>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Peter,
>
>     The point is that it is just an opaque chunk of data returned to
>     the client. I think too many assumptions are being made about what
>     is being carried in that data. If it is simply classified as
>     opaque, it could be anything
>
>     So applying the MAC seems like a good idea to me in certain
>     situations, although given the opacity of the data, it is integral
>     to the data itself and therefore may only need to be recommended
>     in the specification, so the extended length of the field should
>     suffice.
>
>     Robert
>
>>     When introduced in draft-bormann-coap-misc-05, Token was
>>     specifically an opaque transaction-layer header introduced to
>>     eliminate the need to perform complex comparisons on URI fields
>>     to correlate an asynchronous response with a request.
>>
>>     back-door mechanism to convey meaningful state from client to
>>     server outside the message body, or to transport it to and from
>>     the server rather than retain it on the client?
>>
>>     If it serves only this correlation role, is there a security
>>     aspect that needs to be addressed (that isn't naturally addressed
>>     by protecting the entire message)?
>>
>>     Peter
>>