Subject: [Cfrg] SCS draft

From: thomas fossati <[email-masked]>
Date: Fri, 29 Sep 2006 20:33:55 +0200

We have quite recently developed a technique that allows for cookie 
based HTTP sessions even on zero-storage devices (this is mainly 
intended for the embedded world).

Basically all the "session" cookies - i.e. cookies which hold a given 
session state - are transformed into untamperable tokens (via an 
authenticated encryption scheme) and pushed to the client which 
transparently stores them.  When a new client-server exchange takes 
place, the cookies are sent back to the server where they are unpacked 
and examined.  If they are still "good", the state is updated and the 
session goes on, otherwise it is dropped.

Anyway, all the details are found at the following URL:
     http://www.ietf.org/internet-drafts/draft-barbato-scs-00.txt

If any of you would like to review and comment on it, that would be 
very appreciated (the spec is quite compact, and should be quick to 
read).

TIA, t.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: [email-masked] (David Wagner)
Date: Fri, 29 Sep 2006 20:18:45 +0000 (UTC)

>intended for the embedded world).

FYI, this is not a new idea; the idea of forcing the client to store
your state for you, by giving them an encrypted form of the state to
store as a cookie, is an old old idea.  For instance, it was used in
the SYN-cookies defense.  But it seems useful to document concretely
how to do this right.

Comments on your draft:

- The protocol doesn't address replay of old cookie values.  There
  is nothing that guarantees that the client returns the most recent
  version of the cookie; clients could easily replay old stale
  values.  The application protocol that uses these PDUs has to
  be designed so that the client can't get any advantage by replaying
  old cookies.  I think this needs to be discussed in the draft.

- It doesn't address deletion of cookies.  A client can always
  delete its cookie and return nothing.  The protocol has to be
  designed so there is no incentive to do so.  For instance, it is
  safe for the cookie to represent some kind of positive capability
  (possession of which increases the client's powers).  It is not
  safe to use the cookie to represent negative capabilities (where
  possession reduces the client's powers) or for revocation.  This
  needs discussion, too.

- It doesn't prevent sharing of cookies between multiple clients.
  Nothing prevents client Carol from sharing the cookie she recieved
  from the server with client Chuck, and then having Chuck return that
  cookie to the server.  Some applications may need to include the
  identity of the client in the encrypted data, to prevent this threat.
  This needs discussion, too.

- I don't think the discussion fully acknowledges the risks of cookie
  theft.  It is not true that inserting a nonce prevents an attacker
  from stealing a cookie and then using it in some other session.  (It
  may prevent replay, but if the attacker uses it before the legitimate
  client gets a chance to, then the attack still succeeds.)  Moreover,
  you haven't stated how a nonce would help prevent replays; since you're
  assuming that the server doesn't want to keep any state, I don't see
  to use a nonce to prevent replays.  I think the mis-statement in
  Section 5.1 needs to be corrected.

- I couldn't tell whether it was safe to let || denote plain
  concatenation.  Do you ever apply || to variable-length data?
  If so, you need to make sure that the concatenated data can be
  uniquely parsed.  For instance, "f"||"oo" = "fo"||"o", so if x
  and y are both variable-length, then x||y is not uniquely
  decodable, and this introduces potential security vulnerabilities.
  If you're concatenating two pieces of variable-length data, then
  I suggest using a pairing operator like <x,y> = len(x)||x||y.
  One place where this arises is in Section 3.2.4.  I can't tell
  whether the iv, atime, and tid are fixed-length or not; if they
  are fixed-length everything is ok, but otherwise it's problematic.

- Section 4 says "the key", but there are two keys (the encryption
  key and the HMAC key).  These recommendations should apply to
  both keys.

---

From: thomas fossati <[email-masked]>
Date: Sat, 30 Sep 2006 08:05:41 +0200

David,

thanks for the ready and rich feedback.

> the SYN-cookies defense.  But it seems useful to document concretely

Yes we know :-) and we are in good company: e.g. RFC4507 too belongs to 
the same family.  Anyway there was no documented reference for the HTTP 
use case (which is our primary and sole target at present) and we've 
been forced to rephrase it.
Also, it looked sensible to let the HTTP server do the work once, 
instead of doing it in multiple, different (and possibly wrong) ways by 
the web applications.

>   old cookies.  I think this needs to be discussed in the draft.

OK.

>   possession reduces the client's powers) or for revocation.  This

Agreed.  By "protocol" you mean the upper layer which uses the SCS 
facility (i.e. the application which sets the SCS_DATA contents), right 
?

>   This needs discussion, too.

I can't see a way to prevent this threat: SCS cookies are tickets that 
can be spent by their holder at any time inside a validity period (the 
'session_max_age' configuration attribute).  If Carol gives her ticket 
to Chuck and Chuck presents it to the server within the validity 
period, he will be admitted in.  Including Carol's identity into her 
ticket is vain, unless we force Chuck to provide a separate credential 
that matches the ticket's identity.  But Carol could pass also this 
credential to Chuck and we'd be over again :-)

>   Section 5.1 needs to be corrected.

Right.

>   are fixed-length everything is ok, but otherwise it's problematic.

Another good catch.

>   key and the HMAC key).  These recommendations should apply to

Right.

Thank you again.
t.

---

From: [email-masked] (David Wagner)
Date: Sat, 30 Sep 2006 16:59:55 +0000 (UTC)

thomas fossati  wrote:
>>   designed so there is no incentive to do so.
>
>facility (i.e. the application which sets the SCS_DATA contents), right?

Right.  Sorry; maybe I should have written "application" instead
of "protocol".  I'll try to remember to do so from here on in.

>credential to Chuck and we'd be over again :-)

You're right, and I was wrong.  I wasn't thinking straight.  In theory,
SSL with client certs would deal with this, but no one uses that, so
never mind.

I still think the risk should be explained in the document, so
applications don't get taken by surprise, but I don't see any way to
prevent this, either.

Anyway, good job on the Internet-draft.

---

From: "Ben Laurie" <[email-masked]>
Date: Sat, 30 Sep 2006 10:13:34 -0700

> SSL with client certs would deal with this, but no one uses that, so

No it wouldn't. Client certs are just as shareable as cookies.

---

From: thomas fossati <[email-masked]>
Date: Sat, 30 Sep 2006 21:37:22 +0200

David,

On Sep 30, 2006, at 6:59 PM, David Wagner wrote:
> applications don't get taken by surprise

Ok.

I think that -01 will have a separate subsection inside the "Security 
Consideration" block, one for each threat (replay, deletion, sharing, 
etc.) so that it can be easily looked up.  And makes it a much cleaner 
text too.

t.