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