Subject: Re: Last Call: Applicability Statement for HTTP State Management to BCP

From: Jacob Palme <[email-masked]>
Date: Mon, 16 Aug 1999 20:39:23 +0200

draft-iesg-http-cookies-00.txt says that cookies are allowed for 
maintaining sessions, but not in general for authentication. But 
there is no sharp border between maintaining sessions and 
authentication.

If a user makes a series of rapid interactions with the same server, 
this is clearly a session. If a user connects one week later to the 
same server, use of a cookie from the previous week is probably 
authentication. But what if a user visits some other web pages during 
a session. How long or what kind of break in a session means that 
cookies should not be used? Should the IESG proposal mean that 
cookies should be deleted whenever a user restarts his web browser or 
computer?

One way of handling this might be to ask the user which validity
time the user wants for the cookie. Depending on whether the
computer is used by more than one person, and how easy it is
to get into the room, and how secret the info is, and which
privacy requirements the user has, the user could select a
suitable Max-age.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Aug 1999 20:04:44 -0400

> there is no sharp border between maintaining sessions and 

I can try to clarify this on the next edit.  The idea is that
cookies are too weak a mechanism to be used for authentication
to protect anything of significant value.  If neither the server
nor the user to whom the cookie was originally issued will 
be harmed if the cookie is sniffed or replayed by an attacker,
it's probably not a problem.  But some sites are using cookies
as a means to control access to sensitive data about the user
(e.g. a user's account information, credit card number, 
purchasing history), and other sites are using cookies as a means 
to control access to information with significant value.
It needs to be clear that such uses are not consistent with the
intended purpose of the state management standard.

Keith

---

From: Jacob Palme <[email-masked]>
Date: Tue, 17 Aug 1999 02:34:15 +0200

>intended purpose of the state management standard.

When you say that cookies should not be allowed for authentication
purposes, does this mean that the users have to authenticate
themselves at every interaction? If not, what is the difference
between maintaining a session and doing authentication? If a cookie
is used to maintain sessions, so that users do not have to
authenticate at every step in the session, is this not a kind of
authentication? Or do you mean that only certain authenticaiton
methods are not allowed in cookies. For example that it is OK to
store a session id in a cookie, but not to store login name and
password? But the session id could also be misused.

One might make things a little more secure by disallowing cookies if
the user has changed IP number, such as when disconnecting and
connecting to a dynamic IP number service Internet provider.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Aug 1999 09:14:02 -0400

> themselves at every interaction? 

no.  

> If not, what is the difference
> between maintaining a session and doing authentication? 

just because each http transaction is authenticated doesn't
mean that the user has to type his password in each time a new
page is loaded.  if the browser already knows the user's 
password for that site, it doesn't have to ask again each time.
the point is that cookies are a poor *protocol* for doing
authentication, because they expose the authentication
credentials to eavesdropping attacks.

> If a cookie
> authentication? 

in a sense it is, but it's a really lousy way of doing authentication
that leaves users and/or information providers vulnerable to attack.

the purpose of cookies is not to identify users, but to identify
sessions.  even if you are using good authentication, you might
still need cookies to distinguish one session from another.

> Or do you mean that only certain authenticaiton

you certainly should not store a password in a cookie.  but if
you use any cookie - even a randomly generated cookie - as if it
were a password to protect something valuable, and that cookie
can be reused by an attacker to gain access to that resource -
you're misusing cookies.

> connecting to a dynamic IP number service Internet provider.

this breaks a number of legitimate uses of cookies, and provides
a dubious gain in security. source IP numbers can often be spoofed, 
and there are attacks which work 

Keith

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 17 Aug 1999 09:34:35 -0700

At 20.04 -0400 99-08-16, Keith Moore wrote:
>to protect anything of significant value.  

The concept of the cookie mechanism is that the client
will replay the cookie when hitting a particular page.
Thus there is no possibility of the client adding additional
information so as to prevent replay, i.e. an authenticator. 
This leaves the cookie mechanism vulnerable
to replay attacks. Were the cookie to include 
an authenticator as well as some kind of 
encrypted ticket (e.g. a kerberized cookie), 
then it could be argued that cookies could 
indeed provide authentication. 

>If neither the server
>it's probably not a problem.  

The replay problem arises due to lack of an authenticator,
which permits replay within an unlimited time window,
not merely due to the ability to sniff the cookie. It 
is possible for the web server to create cookies that 
can serve as encrypted tickets, although few sites 
make use of this. 

>themselves at every interaction? 

Yes, without some kind of ticketing mechanism, that would
be inevitable (and quite annoying!). 

>If not, what is the difference between maintaining a 
>session and doing authentication? 

There is no real distinction between these things. 

>connecting to a dynamic IP number service Internet provider.

I don't think this is a great idea because this could cause
breakage for users behind a NAT. Rather, in the spirit of
praising the light vs. cursing the darkness, it might make
sense to describe what would need to be done in order to
allow cookies to provide real security and contrast this
with what is actually done today.