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

[Torsten Lodderstedt <[e-mail]>]

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

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:*[e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Mike Jones
> *Sent:* Thursday, May 17, 2012 3:12 PM
> *To:* [e-mail]
> *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 [mailto:[e-mail]] 
> <mailto:[mailto:[e-mail]]>
> Sent: Monday, April 23, 2012 10:13 PM
> To: Mike Jones
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
>
> 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: [e-mail] <mailto:[e-mail]> On 
> Behalf Of Amos Jeffries
>
> > Sent: Monday, April 23, 2012 7:10 PM
>
> > To: [e-mail] <mailto:[e-mail]>
>
> > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
>
> >
>
> > On 24.04.2012 13:46, [e-mail] 
> <mailto:[e-mail]> 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
>
> > [e-mail] <mailto:[e-mail]>
>
> > https://www.ietf.org/mailman/listinfo/oauth
>
> >
>
> >
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth