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