Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

From: [email-masked]
Date: Mon, 23 Apr 2012 18:46:00 -0700

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Apr 2012 14:10:05 +1200

On 24.04.2012 13:46, [email-masked] 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.
>

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Apr 2012 04:33:21 +0000

What specific language would you suggest be added to what section(s)?

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Amos Jeffries
Sent: Monday, April 23, 2012 7:10 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

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

AYJ

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Apr 2012 17:13:06 +1200

> What specific language would you suggest be added to what section(s)?

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

> From: [email-masked] On Behalf Of Amos Jeffries