W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2006

RE: Caching authentication state

From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Date: Sun, 12 Mar 2006 02:03:29 +0100
Message-ID: <B9833546B2643B43A56C4E962E13174607D53B@nehemiah.joris2k.local>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>

>-----Original Message-----
>From: Mark Nottingham [mailto:mnot@mnot.net] 
>Sent: zaterdag, 11 maart 2006 19:11
>To: Joris Dobbelsteen
>Cc: HTTP Working Group
>Subject: Re: Caching authentication state
>On 2006/03/11, at 9:27 AM, Joris Dobbelsteen wrote:
>>> a) Is the intent of the first SHOULD to allow credential caching 
>>> (e.g., similar to [1]) in intermediaries?
>> No, I do not believe it should be done. I believe an immedediary 
>> should never touch authentication (only detect its presence for 
>> caching reasons).
>> This restriction looks for the 'server-side' only. IF authentication 
>> for the same realm is requested, this means the same authentication 
>> authority is used. This unless the authentication method decides 
>> otherwise.
>> No behaviour for the client or intermediate seems to be required.
>Well, it's ambiguous. You can read that it's only server-side, 
>but that's not explicit.

I believe I understood your question differently from what you intended.
It seems that you mean that the intermediate directly responds to the
user agent, depending if the authentication match what is previously
My initial interpretation was the other way arround (the intermediate
forwarding the requests, but now adding the authentication).

      A user agent that wishes to authenticate itself with a server--
      usually, but not necessarily, after receiving a 401 response--does
      so by including an Authorization request-header field with the
      request.  The Authorization field value consists of credentials
      containing the authentication information of the user agent for
      the realm of the resource being requested.

This says that a resource that requires authentication belongs to a
realm. The realm is probably a (administrative) domain where
authentication can be performed (google define:realm). The question
raised here is:
(1) Can the intermediate perform authentication on behalf of the realm?
If it can, can it perform authorization?
(2) Can a party not belonging to the realm perform the authentication
and authorization?

For question 1 I'm sure the RFC will not provide an answer.
I believe the second question is answered by no, because the 'realm' is
the only party to decide on the issue of both authentication and

>>> b) Are the requirements regarding s-maxage predicated on the 
>>> credentials being seen before? Or, does s-maxage allow subsequent 
>>> requests to be served without credentials at all, or different 
>>> credentials?
>> The intermediate simply CANNOT verify the authentication[2]. It 
>> therefore seems completely unlogic to expect an immediate to 
>do so in 
>> any way. It cannot even check if the digest credentials 
>match those of 
>> the previous request (provided e.g. the nonce).
>The text above alludes to the fact that some auth schemes have 
>this limitation, but not all do (e.g., Basic, or a token-based 
>scheme, should such a thing ever appear).

No, that is not true (though it usually is). All have this limitation.
There are no rules anywhere in the HTTP RFC saying how authentication is
validated. There is no rule anywhere that says that authentication
requires you to accept the same username and password on every request.

The RFC strictly points out that when s-maxage is present, the normal
behaviour that is defined for s-maxage should be used. That means it is
cachable by a shared cache.

   For reasons of security and privacy, it is necessary to make a
   distinction between "shared" and "non-shared" caches. A non-shared
   cache is one that is accessible only to a single user. Accessibility
   in this case SHOULD be enforced by appropriate security mechanisms.
   All other caches are considered to be "shared."

So shared caches are accessible by multiple users (not only a single

>>> c) Specifying this behaviour ("When a shared cache...") in terms of 
>>> requests containing an Authorization field effectively allows the 
>>> client to control the cacheability of the response. 
>However, clients 
>>> often send the Authentication header pre-emptively to 
>resources that 
>>> don't need it, which may lead to sites being unnecessarily less 
>>> cacheable.
>> Indeed, therefore, if a response contains s-maxage or 
>public, it most 
>> likely doesn't need authentication anyways. Therefore, if you see 
>> explicit indications that it is publicly cacheable, it will probably 
>> have a good reason.
>> The client can also use the cache-control in the response, which is 
>> probably much more effective anyways.
>This requires servers to send cache-control on all content 
>that might be authenticated, or clients to divine when to send 
>c-c request headers. Considering how little deployment both 
>see, it's not a very practical approach.

So it seems. I believe the tendency is to favor security over

The last line was to indicate that if a client desired to behave badly
with respect to caching, doing so is very easy. I don't believe a client
can make a shared cache do caching when the server doesn't want this.

For authenticated requests there are no good mechanisms to store the
information in a shared cache.

>>> 1. 
>> 2. I cannot determinate if immediates acting on behalf of a origin 
>> server (reverse proxy) are not considered in the RFC. Therefore I 
>> asume they are not.
>Sure they are;
>> gateway
>> A server which acts as an intermediary for some other server.  
>> Unlike a proxy, a gateway receives requests as if it were the origin 
>> server for the requested resource; the requesting client may not be 
>> aware that it is communicating with a gateway.
I should have known that. Again, it is too easy to miss the obvious...

Hopefully this helps us forward,

- Joris
Received on Sunday, 12 March 2006 01:03:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:39 UTC