Subject: Re: [Sip] Cookies or State

From: [email-masked]
Date: Wed, 17 Apr 2002 19:21:12 EDT

In a message dated 4/17/02 3:32:15 PM Eastern Daylight Time, 
[email-masked] writes:

> There are two drafts that define how to save state in a UA for subsequent
> use by a Proxy Server - State and Cookies.
> 
> State is part of the DCS work.  Cookies arose when IP assertions were 
> made against State.  Cookies attempted to get around the IP issues
> by defining it as exactly like HTTP cookies.  To our consternation,
> the same IP claims were then made against Cookies!
> 
> We need to get this capability.  The question is, should we
> base it on State or Cookies?
> 
> In my personal (biased) opinion we are better off with Cookies.
> If anyone did want to fight the IP claim, you would clearly
> be better off with 75% same language as HTTP cookies.
> 

I presume the reference for "Cookies" is still draft-willis-sip-cookies-00 of 
July 2001. I haven't seen any further discussion on this draft or responses 
to the comments I submitted Nov 19. From that draft, it appears there are 
significant security concerns with the use of "Cookies" in a fashion similar 
to HTTP as proposed in this draft.

State would appear to have fewer security concerns if it is simply a value 
stored in the UA for the beniefit of the proxy to fetch and use later. It is 
presumed that the lack of a standard definition of this state value would 
preclude its use by a different proxy than the one which stored it (at least 
by a proxy of a different design).

It continues to escape me why it would not be better for the proxy to simply 
stored this "state" in its own storage, rather than using every UA as a 
distributed storage device. This concept seems to go back to the days when 
memory was limited (the first telephone switch I was involved in designing 
had 64k bytes of memory!) When one can buy 512M bytes of memory for less than 
$100, this should no longer be an issue. The "state" draft seems to indicate 
that the only reason for doing this is so that "proxy servers can remain 
stateless for the duration of the call", but I have never heard a reason why 
this is desirable. (Note that bis-09 defines the term "call-stateful proxy".) 
Why don't we just admit that it is required in some cases to keep the call 
state in the proxy and stop trying to invent ways around this, all of which 
have security and performance problems?

Mike

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 Apr 2002 19:00:13 -0500

----- Original Message ----- 
  From: [email-masked] 
  I presume the reference for "Cookies" is still draft-willis-sip-cookies-00 of July 2001. I haven't seen any further discussion on this draft or responses to the comments I submitted Nov 19. From that draft, it appears there are significant security concerns with the use of "Cookies" in a fashion similar to HTTP as proposed in this draft. 

  State would appear to have fewer security concerns if it is simply a value stored in the UA for the beniefit of the proxy to fetch and use later. It is presumed that the lack of a standard definition of this state value would preclude its use by a different proxy than the one which stored it (at least by a proxy of a different design). 

  It continues to escape me why it would not be better for the proxy to simply stored this "state" in its own storage, rather than using every UA as a distributed storage device. This concept seems to go back to the days when memory was limited (the first telephone switch I was involved in designing had 64k bytes of memory!) When one can buy 512M bytes of memory for less than $100, this should no longer be an issue. The "state" draft seems to indicate that the only reason for doing this is so that "proxy servers can remain stateless for the duration of the call", but I have never heard a reason why this is desirable. (Note that bis-09 defines the term "call-stateful proxy".) Why don't we just admit that it is required in some cases to keep the call state in the proxy and stop trying to invent ways around this, all of which have security and performance problems? 
That is the correct reference, although Brian actually edited the draft based on my rough notes . . .

I believe the security concerns are roughly equal -- in both cases, the UA is given a hunk of stuff that it has to regurgigate on future messages in this dialog.

Both approaches leave the format of the "hunk" open -- it could be cryptographically protected, just a hash value matching a table stored on the proxy, or almost anything else.

I also believe the security concern is SLIGHTLY less urgent than in HTTP. As I understand it, both state and cookie drafts indicate a substantially shorter lifetime for the token. In the case of state, the lifetime is the duration of the current dialog. In the case of cookie, it's the current dialog plus any dialog resulting from redirection or referral of the original dialog. 

HTTP cookies, on the other hand, persist relatively indefiitely and may be extracted by any server in the domain of the cookie during any HTTP interaction with said server for the duraction of the cookie.

Now it is certainly true that one COULD put sensitive information in plain text into a state or cookie token such that other nodes might gain access to that information. The cookies draft does mention that this is not a good idea.

--
dean