Caching authentication state

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Caching authentication state

Mark Nottingham-4

RFC 2616 section 14.8 says:

>       If a request is
>       authenticated and a realm specified, the same credentials SHOULD
>       be valid for all other requests within this realm (assuming that
>       the authentication scheme itself does not require otherwise,  
> such
>       as credentials that vary according to a challenge value or using
>       synchronized clocks).
>       When a shared cache (see section 13.7) receives a request
>       containing an Authorization field, it MUST NOT return the
>       corresponding response as a reply to any other request,  
> unless one
>       of the following specific exceptions holds:
>       1. If the response includes the "s-maxage" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But (if the specified maximum age has
>          passed) a proxy cache MUST first revalidate it with the  
> origin
>          server, using the request-headers from the new request to  
> allow
>          the origin server to authenticate the new request. (This  
> is the
>          defined behavior for s-maxage.) If the response includes "s-
>          maxage=0", the proxy MUST always revalidate it before re-
> using
>          it.
>       2. If the response includes the "must-revalidate" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But if the response is stale, all caches
>          MUST first revalidate it with the origin server, using the
>          request-headers from the new request to allow the origin  
> server
>          to authenticate the new request.
>       3. If the response includes the "public" cache-control  
> directive,
>          it MAY be returned in reply to any subsequent request.

This section is confusing, so a few questions;

a) Is the intent of the first SHOULD to allow credential caching  
(e.g., similar to [1]) in intermediaries?

If so, it's pretty well hidden; so much so that I wrote a duplicative  
I-D after the fact ;)  This is a useful feature that AFAIK is not  
implemented by anyone; however, it has implications for  
authentication realms (i.e., they must be homogenous) that people may  
not realise.

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?

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.

I haven't looked at the core caching stuff in a while; am I missing  
something here?


1. http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt


Thanks,

--
Mark Nottingham
[hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state

Rob Sayre-2

On 3/10/06, Mark Nottingham <[hidden email]> wrote:
>
> RFC 2616 section 14.8 says:
>
> >       If a request is
> >       authenticated and a realm specified, the same credentials SHOULD
> >       be valid for all other requests within this realm
>
> a) Is the intent of the first SHOULD to allow credential caching
> (e.g., similar to [1]) in intermediaries?

My guess would be no. I think it means that the same username/password
combination should be valid throughout the the realm. For example,
Digest clients can send cnonce and nonce-count values, so the actual
data sent changes with each request.

--

Robert Sayre

Reply | Threaded
Open this post in threaded view
|

RE: Caching authentication state

Joris Dobbelsteen
In reply to this post by Mark Nottingham-4

Mark,

See inline. This is my interpretation of the text and answer to your
questions.

- Joris

>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Mark Nottingham
>Sent: zaterdag, 11 maart 2006 0:09
>To: [hidden email]
>Subject: Caching authentication state
>
>
>RFC 2616 section 14.8 says:
>
>>       If a request is
>>       authenticated and a realm specified, the same
>credentials SHOULD
>>       be valid for all other requests within this realm
>(assuming that
>>       the authentication scheme itself does not require otherwise,
>> such
>>       as credentials that vary according to a challenge
>value or using
>>       synchronized clocks).
>>       When a shared cache (see section 13.7) receives a request
>>       containing an Authorization field, it MUST NOT return the
>>       corresponding response as a reply to any other request, unless
>> one
>>       of the following specific exceptions holds:
>>       1. If the response includes the "s-maxage" cache-control
>>          directive, the cache MAY use that response in replying to a
>>          subsequent request. But (if the specified maximum age has
>>          passed) a proxy cache MUST first revalidate it with the
>> origin
>>          server, using the request-headers from the new request to
>> allow
>>          the origin server to authenticate the new request. (This is
>> the
>>          defined behavior for s-maxage.) If the response includes "s-
>>          maxage=0", the proxy MUST always revalidate it before re-
>> using
>>          it.
>>       2. If the response includes the "must-revalidate" cache-control
>>          directive, the cache MAY use that response in replying to a
>>          subsequent request. But if the response is stale, all caches
>>          MUST first revalidate it with the origin server, using the
>>          request-headers from the new request to allow the origin
>> server
>>          to authenticate the new request.
>>       3. If the response includes the "public" cache-control
>> directive,
>>          it MAY be returned in reply to any subsequent request.
>
>This section is confusing, so a few questions;
>
>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.

[snip]
>
>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).
It is also impossible to determinate if a connection is from a single
user, not using IP address (another intermediate), not using the same
connection (another intermediate), not even using proxy credentials.
Therefore I believe the desired behaviour should be that, if s-maxage is
added to a request, an intermediate is always allowed to cache the
response for anyone. Otherwise there should not be a marking that a
shared cache may cache it.
You MUST NOT return the cached information when it is expired. However,
it seems to be perfectly acceptable to try to revalidate if the content
did change (e.g. if-modified-since).

Also, the sentence before the numbered list gives an indication that we
are talking about NOT returning it to any request, UNLESS.

>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.

>I haven't looked at the core caching stuff in a while; am I
>missing something here?

Probably, your last 'statement' already gives the answers to the other
questions, implicitly.
Clients send their authentication prematurely (to prevent likely
additionals round trips) and therefore caching directives from the
server override the (weak) indication of the client that the content
probably requires authentication.

>1. http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt
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.

My EUR .02,

- Joris

Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state

Mark Nottingham-2


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.

>> 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).

> It is also impossible to determinate if a connection is from a single
> user, not using IP address (another intermediate), not using the same
> connection (another intermediate), not even using proxy credentials.

Not sure how this is relevant.

>> 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.

>> 1. http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt
> 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.

Cheers,

--
Mark Nottingham     http://www.mnot.net/


Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state

Mark Nottingham-2
In reply to this post by Rob Sayre-2

Sometimes specs are ambiguous because what seemed obvious at the time  
is interpreted differently; other times, they're purposefully  
ambiguous, so as to not disallow future use cases or extensions. I  
was hoping that one of the original authors would give their take on  
which it was...

On 2006/03/11, at 9:12 AM, Robert Sayre wrote:

>
> On 3/10/06, Mark Nottingham <[hidden email]> wrote:
>>
>> RFC 2616 section 14.8 says:
>>
>>>       If a request is
>>>       authenticated and a realm specified, the same credentials  
>>> SHOULD
>>>       be valid for all other requests within this realm
>>
>> a) Is the intent of the first SHOULD to allow credential caching
>> (e.g., similar to [1]) in intermediaries?
>
> My guess would be no. I think it means that the same username/password
> combination should be valid throughout the the realm. For example,
> Digest clients can send cnonce and nonce-count values, so the actual
> data sent changes with each request.
>
> --
>
> Robert Sayre
>
>


--
Mark Nottingham     http://www.mnot.net/


Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state

Rob Sayre-2

On 3/11/06, Mark Nottingham <[hidden email]> wrote:
> I was hoping that one of the original authors would give their take on
> which it was...

Point taken. And my conjecture is wrong, since I now see that 2616
goes on to discuss the exact situation I was talking about.

--

Robert Sayre

Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state

Roy T. Fielding
In reply to this post by Mark Nottingham-4

On Mar 10, 2006, at 3:08 PM, Mark Nottingham wrote:
> a) Is the intent of the first SHOULD to allow credential caching  
> (e.g., similar to [1]) in intermediaries?

No, the intent is to allow credential caching in user agents (the only
creatures to whom Authorization applies).

The rest of the section you quoted is irrelevant overspecification of
the simple fact that responses to a request containing Authorization
are not shared-cacheable unless explicitly made so by the origin server
header fields (that are more than adequately defined elsewhere, making
those additions here confusing).

....Roy


Reply | Threaded
Open this post in threaded view
|

RE: Caching authentication state

Joris Dobbelsteen
In reply to this post by Mark Nottingham-4

>-----Original Message-----
>From: Mark Nottingham [mailto:[hidden email]]
>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
seen.
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
authorization.

>>> 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
user).

[snip]

>
>>> 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
cachability.

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.
>http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Caching authentication state [giving too much control to clients?]

Mark Nottingham-4
In reply to this post by Roy T. Fielding

OK, thanks. It sounds like if I want credential caching, it does need  
to be defined by an extension. My use case is for gateways (reverse  
proxies/surrogates/etc.), but I could see inside-the-firewall cases  
where the origin server would also want to allow proxies to do it  
(explicitly).

As an aside, the text as specified seems to allow a message like this:

GET /foo HTTP/1.1
Host: www.example.com
Cache-Control: no-cache
Authentication Basic base64(what:ever)

to force an intermediary to revalidate a representation upon each  
request, until the representation actually changes.

This is because the requirement effectively gives control of the  
representation's cacheability to the client, *beyond* the scope of  
the interaction it is part of. When the cache goes to validate future  
requests, the origin server will happily respond with 304 Not  
Modified, and any freshness information it includes will be ignored.  
Only when the origin server replaces the cached representation (e.g.,  
with a 200 OK) will the state about authentication be removed, thus  
allowing it to avoid refresh.

Do others see this vulnerability?

In any case, I don't see it as a huge problem*; I guess theoretically  
it could be used to craft an attack that reduces cache efficiency --  
if implementations conform to this requirement. I just think it's odd  
to give this kind of control to the client.

Cheers,

* Though I am tempted to go out and put CC: public on pages where I  
really care about cacheability!


On 2006/03/11, at 11:28 AM, Roy T. Fielding wrote:

> On Mar 10, 2006, at 3:08 PM, Mark Nottingham wrote:
>> a) Is the intent of the first SHOULD to allow credential caching  
>> (e.g., similar to [1]) in intermediaries?
>
> No, the intent is to allow credential caching in user agents (the only
> creatures to whom Authorization applies).
>
> The rest of the section you quoted is irrelevant overspecification of
> the simple fact that responses to a request containing Authorization
> are not shared-cacheable unless explicitly made so by the origin  
> server
> header fields (that are more than adequately defined elsewhere, making
> those additions here confusing).
>
> ....Roy

--
Mark Nottingham
[hidden email]