Subject: Caching authentication state

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Mar 2006 15:08:52 -0800

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
[email-masked]

---

From: "Robert Sayre" <[email-masked]>
Date: Sat, 11 Mar 2006 12:12:13 -0500

On 3/10/06, Mark Nottingham <[email-masked]> wrote:
> >       be valid for all other requests within this realm
>

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 11 Mar 2006 10:31:39 -0800

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

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

---

From: "Robert Sayre" <[email-masked]>
Date: Sat, 11 Mar 2006 13:39:42 -0500

On 3/11/06, Mark Nottingham <[email-masked]> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 11 Mar 2006 11:28:38 -0800

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Mar 2006 10:31:25 -0800

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!

--
Mark Nottingham
[email-masked]