Subject: HTTP/1.1 Protocol: Help Needed

From: Gaurav Vaish <[email-masked]>
Date: Mon, 9 May 2005 13:32:23 +0530

Hi,

  I have a situation where the clients do not have cookies enabled and
I have to authenticate through forms.

  Is it possible with current HTTP/1.1 specification?

 As far as I've read it will not be possible. Corerct me if I am wrong.

-- 
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------

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

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 May 2005 13:39:53 +0200

> I have to authenticate through forms.

"Authentication through forms" is not the way that HTTP authentication
works. If you would be doing HTTP authentication*
You do need cookies then or you can use a special 'session id' option in
the tag.

You might want to read eg http://ch2.php.net/session as an example.
PHP uses PHPSESSID=<id> in every url, which is the big disadvantage,
unless you have something to include it when you output to the user
again.

Greets,
 Jeroen

---

From: Gaurav Vaish <[email-masked]>
Date: Mon, 9 May 2005 17:49:30 +0530

> You do need cookies then or you can use a special 'session id' option in

I understand that and know how the HTTP Authentication works.

All I was interested in was... whether there's some way, other than
cookie or "session-ID" option (ugly parameter to URL) through which I
can track the session.

It seems there's no other way out.

Actually, I am looking at present day scenarios where some large
corporations, I know of, have strict policies on Cookies (at least
they've issued guidelines and some even have their proxy servers not
letting in / out any cookies; at least in India).

It seems there's no otherway out...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 May 2005 16:53:37 +0200

On Mon, May 09, 2005 at 05:49:30PM +0530,
 Gaurav Vaish <[email-masked]> wrote 

> I understand that and know how the HTTP Authentication works.

And you understand that authentication and session tracking are two
different things?
 
> cookie or "session-ID" option (ugly parameter to URL)

The session ID can be a hidden form parameter.

http://www.w3.org/TR/REC-html40/interact/forms.html

hidden controls
    Authors may create controls that are not rendered but whose values are submitted with a form. Authors generally use this control type to store information between client/server exchanges that would otherwise be lost due to the stateless nature of HTTP (see [RFC2616]). The INPUT element is used to create a hidden control.

---

From: Gaurav Vaish <[email-masked]>
Date: Tue, 10 May 2005 10:27:05 +0530

> And you understand that authentication and session tracking are two

  Definitely I do. But it's also true that both of them are closely
related. A session without a user may be termed as anonymous session
while one with authentication performed may be a named-session.

  They are dfiferent, but closely related.

  Anyway... I may sound Mr Beans but I have some situations (a
combination of these) as given below:

1. Cookies banned. Even if you enable cookies on your machine, the
proxy does not allow the "Cookie" / "Set-Cookie" header to be passed
on.

2. I am viewing a simple html page. I agree, I can have home hidden
fields to look for the sticky session-ID in form parameter. Granted a
relieve.

3. I am viewing a secret page, say, Secret.PDF => I cannot have a
hidden field in my PDF. Or I have secret movie -
CIA-Secret-Mission.mpg
   How do I track the session in this case - without a cookie!

  Is there any option current available?

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 May 2005 20:46:59 +0200

> cookie or "session-ID" option (ugly parameter to URL) through which I

You could put the session ID in the domain name, but this is a bad
idea for various reasons.

---

From: David Morris <[email-masked]>
Date: Wed, 11 May 2005 13:50:25 -0700 (PDT)

Simple answer ... there is no easy reliable alternative to:
 a.  cookie
 b.  Stick it in the request URL and/or data ... many alternatives in the
details
Basically, the session id must be sent from the client to the server with
every request. If you use HTTP Authentication, the concept of a session is
orthoginal to authentication as the authentication process is repeated
under the covers with each request ... in most cases as long as the
browser process remains active. If you implement authentication as part
of your application (e.g., HTML forms based) then you can choose to
associate successful authentication with some form of session OR you can
mimic the HTTP authentication and resend the credentials with each
request.

Your choices may be limited by your choice of server, client, etc.

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 May 2005 18:46:02 -0400

>  b.  Stick it in the request URL and/or data ... many alternatives in the

...neither of which are good places to store authentication tokens if exposure
of such tokens would compromise either the resource being accessed
or the user's identity.  neither cookies nor URLs are typically well-protected 
against accidental exposure.  they were not designed to be used for 
authentication.

see RFC 2964 for more on use of cookies.

Keith

---

From: Gaurav Vaish <[email-masked]>
Date: Thu, 12 May 2005 12:34:18 +0530

Hi Keith,

Thanks for your response.

You mean to suggest that we should store the session details in form data?

Well... how do I, then, validate whether a valid session
(authenticated session) exists or not if I have to access resources
other than forms - like movie file, pdf, doc etc!

As you say, cookies are sometimes disabled (and for good reasons), how
do I track the session for non-form resources/files?

And it also means that I cannot simply move from one page to another -
if I'm putting validation data as form data, each link must be a
form-submit link with some option.

How far can this be justified?

On 5/12/05, Keith Moore <[email-masked]> wrote:
> it's not appropriate to use cookies for authentication anyway.  they weren't
> designed to be authentication tokens and (at least as typically used) they're
> not suitably protected from exposure.  and as you point out, cookies are
> sometimes disabled (and for good reasons).
> 
> for similar reasons, using part of a URL as an authentication token isn't
> a good idea either.
> 
> form data may be somewhat better protected.
> 
> Keith
>

---

From: Gaurav Vaish <[email-masked]>
Date: Thu, 12 May 2005 12:42:23 +0530

Hi,

   In the light of the discussions we had so far - on various modes of
authentication and session tracking: cookie, cookieless, form-data,
URL-parameter etc etc etc, may I suggest an improvement in HTTP/1.1 -
which, again, is open to discussion.

  Currently, associated with HTTP-Authentication are two (or three) headers:

1. WWW-Authenticate
2. Authorize
3. Optionall, Auth-Info

   Can we have a header called Auth-ID which may perform the task of a
session-ID. Instead of putting in form-data or part-of-URL (which
leads to a must-form-on-every-request) or as cookies (sometimes
disabled, for good reasons as mentioned in thread), we can have it as
a separate header.

   A small flow can be something like this:

1. Server requets authentication (HTTP-Authentication or simply form based)
2. Client Authenicates
3. Server validates authentication and sets a header (Set-Auth-ID:
<some-id>, path='/some/path')
4. Client, when requesting any URL from the server under '/some/path',
a header is passed (Auth-ID: <some-id>).

5. Server makes use of this header to dis/allow any protected content.

Ok... another extension in HTTP/1.1 may not be on cards... but do we
have any other option? Or just live with Cookies? :-(

---

From: Florian Weimer <[email-masked]>
Date: Thu, 12 May 2005 09:32:20 +0200

> disabled, for good reasons as mentioned in thread), we can have it as

Your proposal does not address one of the problems raised in Section
2.2.2 of RFC 2964:

   Similarly, HTTP State Management SHOULD NOT be used to authenticate
   user requests if unauthorized requests might have undesirable side-
   effects for the user, unless the user is aware of the potential for
   such side-effects and explicitly consents to such use.  For example,
   a service which allowed a user to order merchandise with a single
   "click", based entirely on the user's stored "cookies", could
   inconvenience the user by requiring her to dispute charges to her
   credit card, and/or return the unwanted merchandise, in the event
   that the cookies were exposed to third parties.

Nowadays, this is called "Cross-Site Request Forgery", or "Session
Riding".  Standardizing some cookie-lookalike which doesn't address
this problem seems rather pointless to me.

---

From: Gaurav Vaish <[email-masked]>
Date: Thu, 12 May 2005 13:11:23 +0530

Hi Florian,

   Thanks for the finding.

> this problem seems rather pointless to me.

  Cookies can be persisted. This header should not be.

  This header does not have any expiry associated with it - it expires
immediately after the browser is closed (or may be an extension of my
original recommendation - "Set-Auth-ID: unset". Unset may be reserved
auth-ID for logout).

  It's similar to what Authorize header but with an exception that the
value of the header is set by the server and not by the client. And
also, it can be unset.

  I mean, if u look at how present browsers work is that once
authentication happens (thru NTML/Basic/Digest et al), they'd continue
to send these headers and they don't know when to stop. The only way
to logout is to close that instance.

  This problem deepens with clients that insist to have only one
application instance running (for example Mozilla/Firefox). It may be
argued that it's the problem with application and not protocol - but
the problem IS with protocol that is does not tell WHEN to logout /
unset / not send the header.

  Critics / comments appreciated... :-)

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 May 2005 09:26:02 -0400

> You mean to suggest that we should store the session details in  

I mean to suggest that trying to do good authentication with cookies  
or URL frobs is a difficult, ugly problem.  Though I have seen one  
approach that essentially encoded Kerberos tickets in cookies that  
seemed to me to have potential, but that still wouldn't solve the  
problem for sites/proxies that thwart cookies.  I think putting such  
frobs in URLs would make the URLs too long.

> How far can this be justified?

Just because http exists does not mean it is a good tool for  
everything you might want to do over a network.

Keith

---

From: "Tommy M. McGuire" <[email-masked]>
Date: Fri, 13 May 2005 10:21:25 -0500

> 5. Server makes use of this header to dis/allow any protected content.

Ok, I may be dumb as a sack of hammers, but I am not seeing how this is
different from a cookie, except that

(a) Your Auth-ID cannot be persistent across browser executions, where
cookies can be (but don't have to be, as specified by the server).  (Of
course, the server does not know when the browser is terminated, so
non-persistence only marginally addresses privacy issues.)

(b) The Auth-ID is not currently blocked by existing anti-cookie
approaches.  (Call me cynical, but....)

Now, if you were to insert a step 3.5, where the client applies a
suitable cryptographic function to compute a some-id' and returned that
to the server in step 4, and the server generated a new some-id every
time around, you might have an interesting idea.

Of course, that still doesn't address sections 2.2.1 and section 3
(especially 3.2) of RFC2964.  And unless you can address those, your
pseudo-cookies will be blocked shortly.

-- 
Tommy McGuire