On 19/06/2012 12:54 p.m., Mike Jones wrote:
Could the experts on this thread please summarize the outcome of this thread?
Was the conclusion that no changes were required to either Core or Bearer? Or
if you believe that changes are required to one or both drafts, could you
please propose exact wording changes for review by the working group?
IMHO they are correct as-is. No changes need be made to either.
AYJ
Thanks,
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Torsten Lodderstedt
Sent: Monday, June 11, 2012 11:07 PM
To: Phil Hunt
Cc: [email protected]
Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter
method
thanks a lot
Am 12.06.2012 01:03, schrieb Phil Hunt:
Thanks. That makes sense.
Phil
On 2012-06-11, at 15:39, Amos Jeffries<[email protected]> wrote:
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: [email protected] 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: [email protected] On Behalf Of Amos Jeffries
On 24.04.2012 13:46, [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-1
9.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]
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
_______________________________________________
OAuth mailing list
[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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
