Subject: RE: Authentication/Session tracking question [was: HTTP/1.1Protocol: Help Needed

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 May 2005 14:30:50 -0700

Something of the sort could be done. But to do so would require the HTTP
WG to be re-opened and there are many other proposals that would also
have to be considered.

I proposed a session-id in 1995 that was similar to Dave Raggets 1992
proposal but with some crypto in it that prevented session ids being
correlated across domains.

Before any change is made to the HTTP protocol there has to be a
strategy for deployment of a new version of the HTTP protocol. None of
the IETF protocols have provided a satisfactory answer to the question
of how to upgrade after a protocol has become widely used. Version
numbers have not proved as useful as some hoped. OSI solved this problem
by being a hopeless failure, Web Services might have found an answer
with WS-Policy or this might turn out to work no better than earlier
proposals.

I can't see much point to your proposal if we have to wait ten years
before it can be used, particularly when a scheme already exists that
gives similar functionality.

The deployment strategy has to come first, how can this address a pain
point that is recognized by the user? What incentives ar there for Web
sites and browser providers?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gaurav Vaish
> Sent: Thursday, May 12, 2005 3:41 AM
> To: Florian Weimer
> Cc: David Morris; Keith Moore; [email-masked]
> Subject: Re: Authentication/Session tracking question [was: 
> HTTP/1.1Protocol: Help Needed
> 
> 
> Hi Florian,
> 
>    Thanks for the finding.
> 
> > Your proposal does not address one of the problems raised 
> in Section 
> > 2.2.2 of RFC 2964:
> > 
> > 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.
> 
>   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... :-)
> 
> 
> -- 
> Cheers,
> Gaurav Vaish
> http://www.mastergaurav.org
> http://mastergaurav.blogspot.com
> --------------------------------
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 May 2005 20:12:23 -0400

> WG to be re-opened and there are many other proposals that would also

At least from a process point-of-view, it would just require a 4 week last call.
Even if a WG were formed, it could have a narrow scope.  it would not need
to consider every proposal for a change or extension to HTTP.

> strategy for deployment of a new version of the HTTP protocol.

Seems like HTTP has been haphazardly modified so many times that it
is beyond the point where a 'strategy' could help.  Nor is it immediately
clear that a new version of the protocol would be needed or even useful
in helping to add a negotiate kind of authentication scheme.

Both of these arguments read like symptoms of second-system effect.

Keith

---

From: Gaurav Vaish <[email-masked]>
Date: Fri, 13 May 2005 09:26:59 +0530

> The deployment strategy has to come first, how can this address a pain

   Deployment strategy from whose perspective? The developer -- who's
writing server-side code? Or the update in client?

  In both the cases, I think, it's trivial to have a small patch. MS
already gives automatic updates for IE. Task for Mozilla is trivial.
Safari -- Apple as also has automatic updates feature.

  From developer's perspective -- most servers, specially J2EE and
.Net based - used a central authentication / tracking system. So do
most of the popular systems in PHP and Perl/CGI.

  IMHO, there's no deployment problem. If there needs to be a
demonstration by writing a piece of code, I can patch up Mozilla and
my server-side code. :-)

> sites and browser providers?

  Websites no longer have to rely on cookie. Several times, as one of
my friends in Yahoo says, users report that they are unable to login
only to find that cookies have been disabled by the proxy server
(transparent or otherwise) in their organizations.

  For browsers -- cookies can be disabled by default. For now, cookies
are enabled in "safe" mode. From now on, default configuration can be
even more restrictive (read: secure).

  Not sure if I have been able to convince you.... but I think, I
should have succeeded. :D

  btw, can you provide details of your proposal that you gave 1995?
And what was Dave's proposal in 1992?

  Remember, again, that the ID expires immediately. And there's a
provision to unset. The former addresses Section 2.2.2 of RFC 2964
(pointed out by Florian). The latter addresses what current HTTP
Authentication fails to do -- logout without killing the process /
browser instance.

---

From: Gaurav Vaish <[email-masked]>
Date: Fri, 13 May 2005 09:37:26 +0530

Hi Keith,

  Thanks for the response.  Please see my comments inline.

> to consider every proposal for a change or extension to HTTP.

   At this point of time, I have not idea of what it takes to make a
WG, a proposal and get it approved.

   However, as you mention about  "a narrow scope" - I would like to
just give an example supporting this. RFC 821 details SMTP. RFC 2554
is entitled "SMTP Service Extension for Authentication". A very small
extension to 821.

  Similarly, we may like to follow up similarly. However, since the
protocol demands strict mention of the version in the following format

     HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

   we'd need to call it HTTP/1.2 (cannot have 1.1.1).

> is beyond the point where a 'strategy' could help.  Nor is it immediately

   I think it's not a matter of choice of having a strategy but the
way things have evolved. 0.9 -> 1.0 -> 1.1. The updates have been
based upon what has been prevelant in market and what the need arose.

  Anyway.. let me not digress from the main agenda of the thread.

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 May 2005 00:55:16 -0400

> is entitled "SMTP Service Extension for Authentication". A very small

That's not what I meant by "narrow scope".  By "narrow scope" I meant  
that a WG could be chartered for only the purpose of developing a  
better authentication method for HTTP, and forbidden to develop any  
extensions for HTTP that were not needed to provide better  
authentication.  (IMHO, creating a new HTTP extensions WG would be to  
open Pandora's box)

Regarding your SMTP analogy, I don't think it is the case that adding  
another authentication flavor to HTTP is as simple as it was to add  
authentication to SMTP - first, because HTTP is much more complex  
than SMTP (especially in how it negotiates protocol options); second,  
because SMTP has a much cleaner extension model than HTTP (thank you  
mtr); third, because the relationships between principals tend to be  
different for HTTP than for SMTP; and fourth, because in the case of  
HTTP servers there is a significant investment in existing  
authentication databases and the types of credentials they support  
which did not exist for SMTP when authentication was added to it.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 13 May 2005 10:26:11 -0400

Hi Keith,

--On May 13, 2005 12:55:16 AM -0400 Keith Moore <[email-masked]> wrote:

> authentication to SMTP - first, because HTTP is much more complex  than
> SMTP (especially in how it negotiates protocol options); second,  because
> SMTP has a much cleaner extension model than HTTP (thank you  mtr);
> third, because the relationships between principals tend to be  different
> for HTTP than for SMTP; and fourth, because in the case of  HTTP servers
> there is a significant investment in existing  authentication databases
> and the types of credentials they support  which did not exist for SMTP
> when authentication was added to it.

Its worth noting that the current CalDAV effort 
<http://www.ietf.org/internet-drafts/draft-dusseault-caldav-05.txt> (which 
is attempting to use WebDAV as the basis for a calendaring and scheduling 
protocol) would benefit from sharing an authentication database with other 
related services - email (IMAP, POP, SMTP etc) being the best example. 
Those existing protocols now typically use SASL for the authentication 
exchange so it would seem natural to want SASL in HTTP too so that CalDAV 
could be easily integrated into such environments. Unfortunately the HTTP 
SASL draft 
<http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-12.txt> 
proposing such a scheme has been stalled for quite a while, so progress on 
this front is limited. Also, I don't think it would help with the session 
tracking issue either.

-- 
Cyrus Daboo

---

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

> Safari -- Apple as also has automatic updates feature.

In the first place, it's not a small patch.  (Well, OK, renaming the
cookie headers is a small patch.  But somebody eventually would see
through that; to get more than 6-12 months out of this idea would
require more work than that.)

In the second place, not all HTTP clients come from the set {IE,
Mozilla, Safari}.  In fact, if you look simply at the number of clients
(as opposed to weighting the number by the popularity), those are
probably a very small minority.  And there are still archaic versions of
those three floating around.

> most of the popular systems in PHP and Perl/CGI.

(I reiterate my second point above.)

> (transparent or otherwise) in their organizations.

Frequently, I suspect Yahoo is swimming upstream.  There are good
reasons why cookies are blocked; relying on them is probably not the
best idea.

> And what was Dave's proposal in 1992?

Uh, me, too.

> (pointed out by Florian).

Does it?  The Auth-ID is still transmitted in the clear, exposing it to
everything between the server and the client.  And expiration wouldn't
automatically fix the problem of the client leaking the token.

-- 
Tommy McGuire

---

From: Gaurav Vaish <[email-masked]>
Date: Sat, 14 May 2005 14:25:59 +0530

> everything between the server and the client.  And expiration wouldn't

   See the content of Auth-ID in light of the proposal given earlier
(see above) where this ID :

1. may be encoded / encrypted (as required)
2. has an algorithm for generation - which may include IP addresses of
both the parties etc
3. obviously, has some data that is specific to the server (that does
session management). This is the private part of the ID which, again,
may be en-coded/crypted.