Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method

Amos Jeffries <squid3@treenet.co.nz> Mon, 11 June 2012 22:39 UTC

Return-Path: <squid3@treenet.co.nz>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E921F853D for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 15:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.662
X-Spam-Level:
X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sjVYwv54n3V for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 15:39:57 -0700 (PDT)
Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70AD721F853C for <oauth@ietf.org>; Mon, 11 Jun 2012 15:39:57 -0700 (PDT)
Received: by treenet.co.nz (Postfix, from userid 33) id 64B42E6F2D; Tue, 12 Jun 2012 10:39:53 +1200 (NZST)
To: oauth@ietf.org
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 12 Jun 2012 10:39:53 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
In-Reply-To: <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com>
References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com>
Message-ID: <fbc284f460ed3f9015dc44ce104a0ecd@treenet.co.nz>
X-Sender: squid3@treenet.co.nz
User-Agent: Roundcube Webmail/0.7.2
Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2012 22:39:59 -0000

On 12.06.2012 07:23, Phil Hunt wrote:
> Private also seems inappropriate since no operation should be cached
> for oauth as even when the same requestor.
>
> Phil
>

There is a difference in HTTP use-case between what the Bearer and core 
specs are covering.

The core spec appears to be covering the request/response messages 
transferring credentials in the response entity. These mandate 
"no-store", which adds strict erasure requirements for any middleware 
and browser caches handling the response. Even single-user caches like a 
browser are not allowed to store the HTTP copy of the credentials 
response.

Bearer is requiring "private" only in the specific HTTP case where the 
token is in query params and response is some data object (ie images or 
HTML page). Such that trusted proxies and other third-parties who do not 
implement OAuth but do relay HTTP treat the request and reply securely. 
With uses of Bearer via HTTP authentication framework this "private" is 
implicit.
   In these cases the response MAY be cached by a private browser cache, 
but not by third-party proxies. no-store is overkill and wastes 
bandwidth in this case.


I hope this clarifies.


AYJ


> On 2012-06-11, at 12:17, Torsten Lodderstedt wrote:
>
>> Hi all,
>>
>> I noticed a difference in usage of cache control headers between 
>> bearer and core spec.
>>
>> core -27 states:
>>
>>   " The authorization server MUST include the HTTP "Cache-Control"
>>    response header field [RFC2616] with a value of "no-store" in any
>>    response containing tokens, credentials, or other sensitive
>>    information, as well as the "Pragma" response header field 
>> [RFC2616]
>>    with a value of "no-cache"."
>>
>> So a "Pragma" response header field is required instead of the 
>> "Cache-Control" header "private".

Not instead of. *As well as*.  Pragma "no-cache" only tells the 
third-party to revalidate before using the response, it does not prevent 
storage and thus potential data leakage.


>>
>> As far as I understand, both specs are nearly but not fully 
>> equivalent. Do we need to align both?
>>
>> regards,
>> Torsten.
>>
>> Am 09.06.2012 00:20, schrieb Mike Jones:
>>>
>>> Hi Amos,
>>>
>>> The OAuth Bearer specification now includes the Cache-Control 
>>> language we’d discussed.
>>>
>>> See the fifth paragraph of 
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3.
>>>
>>>                                                             Thanks 
>>> again,
>>>                                                             -- Mike
>>>
>>>
>>> From: oauth-bounces@ietf.org On Behalf Of Mike Jones
>>> Sent: Thursday, May 17, 2012 3:12 PM
>>> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query 
>>> Parameter method
>>>
>>> Dear working group members:
>>>
>>> I'm going through the remaining open issues that have been raised 
>>> about the Bearer spec so as to be ready to publish an updated draft 
>>> once the outstanding consensus call issues are resolved.
>>>
>>> Amos Jeffries had cited this requirement in the HTTPbis spec ( 
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1):
>>>
>>>    o  The credentials carried in an Authorization header field are
>>>       specific to the User Agent, and therefore have the same 
>>> effect on
>>>       HTTP caches as the "private" Cache-Control response 
>>> directive,
>>>       within the scope of the request they appear in.
>>>
>>>       Therefore, new authentication schemes which choose not to 
>>> carry
>>>       credentials in the Authorization header (e.g., using a newly
>>>       defined header) will need to explicitly disallow caching, by
>>>       mandating the use of either Cache-Control request directives
>>>       (e.g., "no-store") or response directives (e.g., "private").
>>>
>>> I propose to add the following text in order to satisfy this 
>>> requirement.  I have changed Amos' MUSTs to SHOULDs because, in 
>>> practice, applications that have no option but to use the URI Query 
>>> Parameter method are likely to also not have control over the 
>>> request's Cache-Control directives (just as they do not have the 
>>> ability to use an "Authorization: Bearer" header value):
>>>
>>>     Clients using the URI Query Parameter method SHOULD also send a
>>>     Cache-Control header containing the "no-store" option.  Server 
>>> success
>>>     (2XX status) responses to these requests SHOULD contain a 
>>> Cache-Control
>>>     header with the "private" option.
>>>
>>> Comments?
>>>
>>>                                                                 -- 
>>> Mike
>>>
>>> -----Original Message-----
>>> From: Amos Jeffries
>>>
>>> On 24/04/2012 4:33 p.m., Mike Jones wrote:
>>> > What specific language would you suggest be added to what 
>>> section(s)?
>>> >
>>> >                                                             --    
>>>       Mike
>>>
>>>
>>> Perhapse the last paragraph appended:
>>> "
>>>
>>>     Because of the security weaknesses associated with the URI 
>>> method
>>>     (see Section 5), including the high likelihood that the URL
>>>     containing the access token will be logged, it SHOULD NOT be 
>>> used
>>>     unless it is impossible to transport the access token in the
>>>     "Authorization" request header field or the HTTP request 
>>> entity-body.
>>>     Resource servers compliant with this specification MAY support 
>>> this
>>>     method.
>>>
>>>     Clients requesting URL containing the access token MUST also 
>>> send a
>>>     Cache-Control header containing the "no-store" option. Server 
>>> success
>>>     (2xx status) responses to these requests MUST contain a 
>>> Cache-Control
>>>     header with the "private" option.
>>>
>>> "
>>>
>>> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph 
>>> likely should be a MUST NOT to further discourage needless use.
>>>
>>>
>>> AYJ
>>>
>>>
>>> >
>>> > -----Original Message-----
>>> > From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries
>>> >
>>> > On 24.04.2012 13:46, internet-drafts@ietf.org wrote:
>>> >> A New Internet-Draft is available from the on-line 
>>> Internet-Drafts
>>> >> directories. This draft is a work item of the Web Authorization
>>> >> Protocol Working Group of the IETF.
>>> >>
>>> >>           Title           : The OAuth 2.0 Authorization 
>>> Protocol: Bearer
>>> >> Tokens
>>> >>           Author(s)       : Michael B. Jones
>>> >>                            Dick Hardt
>>> >>                            David Recordon
>>> >>           Filename        : draft-ietf-oauth-v2-bearer-19.txt
>>> >>           Pages           : 24
>>> >>           Date            : 2012-04-23
>>> >>
>>> >>     This specification describes how to use bearer tokens in 
>>> HTTP
>>> >>     requests to access OAuth 2.0 protected resources.  Any party 
>>> in
>>> >>     possession of a bearer token (a "bearer") can use it to get
>>> >> access to
>>> >>     the associated resources (without demonstrating possession 
>>> of a
>>> >>     cryptographic key).  To prevent misuse, bearer tokens need 
>>> to be
>>> >>     protected from disclosure in storage and in transport.
>>> >>
>>> >>
>>> >> A URL for this Internet-Draft is:
>>> >> 
>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt
>>> >
>>> >
>>> > The section 2.3 (URL Query Parameter) text is still lacking 
>>> explicit and specific security requirements. The overarching TLS 
>>> requirement is good in general, but insufficient in the presence of 
>>> HTTP intermediaries on the TLS connection path as is becoming a 
>>> common practice.
>>> >
>>> > The upcoming HTTPbis specs document this issue as a requirement 
>>> for new auth schemes such as Bearer:
>>> >
>>> > 
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1
>>> > "
>>> >         Therefore, new authentication schemes which choose not to 
>>> carry
>>> >         credentials in the Authorization header (e.g., using a 
>>> newly
>>> >         defined header) will need to explicitly disallow caching, 
>>> by
>>> >         mandating the use of either Cache-Control request 
>>> directives
>>> >         (e.g., "no-store") or response directives (e.g., 
>>> "private").
>>> > "
>>> >
>>> >
>>> > AYJ
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth