Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2011 09:32:05 +0200

This is a Last Call for comments on 

http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt

Please have your comments in no later than March 16.

Do remember to send a note in if you have read the document and have no 
other comments other than "its ready to go" - we need those as much as we need "I found a problem".

Thanks!
Hannes & Blaine

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Mar 2011 13:13:22 -0700

Ready to go.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, March 01, 2011 11:32 PM
> To: OAuth WG
> Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Mar 2011 13:18:55 -0700

The title of the message might have been misleading ('cause it had 12
in it) but http://www.ietf.org/mail-archive/web/oauth/current/msg05551.html
applies to -13 and, while it's minor, I'd like to see it addressed in
future drafts.  Thanks.

---

From: Francisco Corella <[email-masked]>
Date: Tue, 8 Mar 2011 14:29:51 -0800 (PST)

In my opinion the protocol has serious problems.

The authorization code is a credential that provides access to
protected resources via the client, as well as user authentication
when OAuth is used for social login.  If an attacker observes or
intercepts the authorization code, the attacker can present the code
to the client, use the client to gain access to the user's protected
resources, and log in to the client impersonating the user.  Therefore
the authorization code cannot be sent to the client without TLS
protection.  The protocol must require the redirect_uri to use the
https scheme.  The redirect_uri is shown as an https URI in the
examples, but examples are not enough.  If TLS is not required,
implementations may use http.  At this time the Facebook developer
documentation shows http rather than https in its examples, and
implementations seem to use http, as can be seen by searching the Web
for "oauth redirect_uri".

The protocol has the same well-known vulnerability to phishing attacks
as OpenID.  The attack on OpenID described by Ben Laurie in
http://www.links.org/?p=187 is equally applicable to this protocol.
The protocol should require the use of TLS at the authorization
endpoint; without it, the user is defenseless against the attack.  The
protocol should also require the user to be already logged in at the
authorization server, so that the server will not ask for credentials.

If implementors take no precautions, the protocol is vulnerable to
Login CSRF attacks.  Adam Barth confirmed this in a message to the
IETF websec mailing list:

> Last time I looked into Login CSRF issues with
> OAuth, the protocol had a large problem and every implementation I
> experimented with was trivially vulnerable.

A countermeasure against Login CSRF must be provided in the security
considerations section.  The security considerations section should
also suggest countermeasures against DOS attacks.  But the section is
not written yet.  I would think that the absence of a security
considerations section in and of itself means that the protocol is not
ready.

I also must point out the danger to the Web posed by a protocol that
is used for social login and requires registration.  Millions of Web
applications already use Facebook for social login.  If social login
becomes a de facto standard for user authentication, Web applications
will have to support login with Facebook just to be able to
authenticate their users.  If that requires registration, then
Facebook will have the power to disable any Web application by
revoking its registration.  That would be bad for all parties
involved, including Facebook, which would then face regulation by the
governments of many countries.

Francisco

--- On Wed, 3/2/11, Hannes Tschofenig <[email-masked]> wrote:

From: Hannes Tschofenig <[email-masked]>
Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "OAuth WG" <[email-masked]>
Date: Wednesday, March 2, 2011, 7:32 AM

Thanks!
Hannes & Blaine

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Mar 2011 23:51:08 +0100

Overall, I'm very happy with this draft. Excellent work, Eran!

A couple of comments though:

section 1.4: "An authorization grant is a general term used to describe the
intermediate credentials ..."

Since passwords represent authorization grants as well, I would suggest 
to adjust the wording to „intermediate or permanent“

section 1.4.3: "Unlike
the HTTP Basic authentication scheme defined in [RFC2617], this grant
type eliminates the need for the client to store the resource-owner
credentials for future use"

I would suggest to add "if used in combination with refresh tokens."

section 1.4.4:

"The client credentials can be used as an authorization grant ..., or to 
protected resources previously arranged
with the authorization server."

Does this mean, the client is not the resource owner but gets access 
because of an existing authorization? How does this differ from an 
implicit grant?

"Client credentials are used as an
authorization grant typically when the client is acting on its own
behalf (the client is also the resource owner)."

What are the alternatives? I would suggest to remove „typically“.

section 2.1:

4. paragraph: "If the response does not include an access token, the 
authorization server SHOULD
require TLS 1.2 and any additional transport-layer mechanism meeting its 
security requirements."

Why only „SHOULD“ and not "MUST"? Otherwise, alternative means for 
preventing abuse of the response parameters MUST be required, e.g. 
client authentication for authorization code exchange.

Moreover, this is about the redirect_uri, isn't it? What about the 
endpoint's security itself, i.e. requests to this endpoint?

section 2.1.1:

3. paragraph: "The authorization server SHOULD require the client to 
pre-register
their redirection URI or at least certain components such as the
scheme, host, port and path."

Pre-registered redirect_uri facilitate client authentication while tying 
a client to a certain deployment. Although this is typical practice 
nowdays I expect this to change if OAuth really gains traction for 
standard client software, such as mail clients.
Proposal: Should by MAY in my opinion + some explanation on the purpose 
of redirect_uri registration.

section 2.2:

4. paragraph: "The token endpoint requires client authentication as 
described in Section 3."

That's to restrictive, probably client identification but not 
authentication. Otherwise, this endpoint cannot be used for most native 
apps.

section 3:
"Client credentials are used to identify and authenticate the client."

I think it would be helpful for the reader to explain the purposes 
client identitification and authentication serve in OAuth. I see the 
following use cases (more text can be found in 
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-00#section-3.8):

In the context of delegated authorization, client identity is used to:
- Establish trust to the client and display relevant registration 
information to a user when requesting consent for authorization
- Authorize clients for certain authorization server features
- Collate associated request to the same originator (e.g. a particular 
end-user authorization process and the corresponding request on the 
tokens endpoint to exchange the authorization code for tokens)

Moreover, client credentials can also be used to authenticate the client 
as a resource owner (see client credentials grant type)

Requirements regarding the client security policy and the data 
associated with the client identity may vary among the purposes.

"The authorization server SHOULD NOT issue client credentials to clients 
incapable of keeping
their secrets confidential."

I would suggest to add some explanation here. Proposal "For example, the 
same client credentials should not be used for multiple installations of 
the same software, e.g. all instances of the same native app running on 
different PCs or smartphones."

section 3.2:
"In addition, the
authorization server MAY allow unauthenticated access token requests
when the client identity does not matter (e.g. anonymous client) or
when the client identity is established via other means."

I would suggest to move this sentence after the BASIC authentication 
example.

section 4.1:

In my opinion, the introduction of this section over-emphasizes the 
aspect of client secrets & authentication while neglecting the other 
properties of the authorization code flow. Moreover, it encourages the 
impression this flow can only be used by clients equipped with a secret. 
This is wrong as this flow should be usable by clients w/o client 
secrets as well because it offers unique properties beside its aibility 
to support client authentication. In my opinion these are:

- user identity and credentials are not exposed to client (in contrast 
to resource owner password grant)
- user authentication and consent controlled by authorization server (in 
contrast to resource owner password grant)
- flow is especially suited for clients which are web applications (in 
contrast to implicit grant)
- refresh token issuance (in contrast to implicit grant)
- client credentials and tokens are sent over protected, direct 
communication channels between client and authorization server (no 
browser caches and HTTP referers involved)
- aibility to authenticate clients (for completeness)

The introduction should explain all properties of the flow and offer 
some guidance when and how to use the flow.

section 4.1.3:
Why is the name of the response type „code“ whereas the name of the 
grant type is „authorization_code“?

"redirect_uri" should only be required if it was an input parameter to 
the corresponding authz request.

last paragraph: "Validate the client credentials and ensure they match 
the authorization code." should be "Validate the client credentials (if 
present) and ensure they match the
authorization code." (see also: 
http://www.mail-archive.com/[email-masked]/msg04540.html)

section 4.1.4:

"If the request failed due to failed client authentication or is 
invalid" - Some words missing here?

example response: The JSON document contains a field 
"example_parameter":"example-value". Some copy and paste remainings? - 
The same holds true for other example JSON documents.

section 4.2.:

I'm struggeling with the name "implicit grant". Why not just stick with 
"User Agent Flow"? It has been designed for that kind of app.

As already mentioned for section 4.1., also this introduction puts to 
much emphasize on the client secret story. I don't think this was the 
original driver of its development. I would expect the intro to focus on 
the functional properties of the flow:

As I understand, it has been designed with JavaScript clients in mind, 
which due to the same origin policy, are unable to send requests 
directly to an authorization server outside of its origin. So instead of 
obtaining tokens through a POST request (via authz code), the access 
token is delivered directly via the redirect URI. In order to reduce the 
exposure of the token (and because it is sufficient), the access token 
is sent via the fragment. As a consequence of the design this flow does 
not support client authentication via secrets. The client's identity can 
nevertheless be validated using pre-registered redirect_uri's.

This flow cannot be used with web applications. And as long as the flow 
does not support refresh tokens, the same holds true for native apps 
(see also http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01). 
So please remove "or native applications" from the text (see 
http://www.ietf.org/mail-archive/web/oauth/current/msg05551.html).

section 4.3:

2. paragraph: I suggest to add "It is even possible to migrate from 
stored credentials to stored refresh tokens. Leakage of the later would 
have less impact."

Figure 5/ Step C) I suggest to add ", and optionally a refresh token."

section 4.3.3

"If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh
token as described in Section 5.1."

How is determined and by whom whether a refresh token is being issued? 
Since this is not an interactive flow, the authorization server cannot 
ask the resource owner.

section 6:
"The authorization server MUST validate the client credentials, ..." 
should be "The authorization server MUST validate the client credentials 
(if present), ..."

regards,
Torsten.

Am 02.03.2011 08:32, schrieb Hannes Tschofenig:
> Hannes&  Blaine
> https://www.ietf.org/mailman/listinfo/oaut

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Mar 2011 00:39:58 -0700

2 more days. Please reserve some time to read the entire document and provide detailed feedback.

EHL

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 14 Mar 2011 18:10:17 -0700

Draft looks good - readability is up considerably from previous drafts.    Getting pretty close IMO

Comments:

1) I'd vote for dropping the following from 1.4.2.   In turn I'd discuss some of the security considerations, such as difficulty of protecting a client_secret in almost all use-cases of this profile.

    "Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since it reduces the number of round trips required to obtain an
   access token."

2) Section 2.1, we should MUST TLS even for Authorization Code.

3) Section 4.1.3 - not clear to me why redirect_uri is REQUIRED since in 4.1.1 it's "REQUIRED unless"

4) Section 4.2.2 - when did we drop refresh_token?     I assume this goes back to disagreement on how best to handle native clients. I'd prefer it to simply reference 5.1 and leave what is issued up to the security profile of the particular deployment as to what is issued.

...and of course section 9.

-cmort

On 3/1/11 11:32 PM, "Hannes Tschofenig" <[email-masked]> wrote:

Thanks!
Hannes & Blaine

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Mar 2011 19:05:10 -0400

Many of my comments have probably been covered by other folks on the 
list, but I'm going to repeat things along here anyway:

Preamble:

Does this document actually obsolete 5849? Since OAuth2 is explicitly 
not backwards compatible, is this WG really making the claim that we're 
updating OAuth, or rather defining a newer (and better) way of doing it?

1.4.2 (et al)

I still don't like the word "implicit" being used here, since there's 
really nothing implicit about it. The grant being made is explicit as 
far as the end user is concerned, and could even have an intermediary 
"do you authorize this?" screen in the middle. I'm still failing to come 
up with a better term than the original "user-agent" wording. What we're 
really talking about here is a way for an end user to directly authorize 
a client as opposed to doing a traditional double-redirect. So it's 
direct like client-credentials and username-and-password, but it's on 
behalf of a user and the client still never sees the user's credentials 
to the AS. We need, and have needed for some time, a better way to say this.

2.0

The phrase "extension grant types MAY define" should probably be the 
more encompasing "extensions MAY define".

2.1

The wording on implicit and explicit makes even less sense here, since 
if the client is getting back a token directly then the grant is even 
more explicit than if the client has to trade the code for something. 
Think about it this way: if the AS is giving you a code, it's implied 
that that code is good for you to get a token that you can actually do 
something with. The AS hasn't actually granted the client access to the 
PR yet, though, just provided a means for doing so. On the other hand, 
the client that gets a token directly is being granted explicit access 
to the PR directly. The server's not implying anything here, it's saying 
"hey, go get stuff with this token".

3.

With 'client_id' required on most steps, the phrase that the AS should 
not issue credentials to untrustworthy clients is incongruous. Perhaps 
better would be to say that the AS shouldn't trust the credentials 
issued to clients without the ability to keep secrets. Basically, we 
need a way of saying that the client identifier is necessary but the 
assumption of it being kept a secret can only go so far. I'm sure the 
security considerations will cover this more deeply, but this is 
something that should be clarified up front here, especially because 
this section is referenced throughout the document.

4.1.2 (and other flows)

Rephrase: "The clients should avoid making assumptions about code value 
sizes. The authorization server should document the size of any value it 
issues." as "Clients should avoid making assumptions about code value 
sizes, and the authorization server should document the size of any 
value it issues."

4.1.3

"Validate the client credentials and ensure they match the authorization 
code." makes it sound like the client credentials and the authorization 
code are the same, or derived from each other. Suggest: "Validate the 
client credentials  and ensure that the client presenting the code is 
the same one the code was originally issued to." This phrasing also 
implies an architecture decision: access codes need to be bound to 
client id's.

4.1.4 (and other flows)

What's with the "example_parameter" bit in all the examples? I think we 
only need this in 5.1's example. It's confusing when peppered throughout 
the spec without context.

4.2

Remove "or native applications", add language about the saved 
round-trip, which is the real reason for this flow, not security 
concerns over saved secrets. Javascript clients could easily use the 
auth code flow with their security profile (and an untrusted client 
password, which is allowed).

5

This section should probably point out that the poorly-named implicit 
flow doesn't use the format in here, and that the reader should go check 
out section 4.2 instead.

5.2

Provide a mechanism for extensions to put different error codes onto the 
wire, either through a registry, URIs, or language saying how to update 
this RFC.

6

Do we need to say that downscoping an access token doesn't change the 
issued scope for the refresh token? It seems obvious to me, but I'm 
wondering if we want to head off questions about this behavior. In 
general, I'd still like to see an explicit section about this behavior 
apart from the (well-written) paragraph about the scope parameter. 
Particularly since we've had someone propose a rescoping proposal 
already (but I can't seem to find this in my email archives now.) I can 
propose text if the WG agrees this is of use; otherwise it probably 
belongs in developer guides.

Overall, -13 is in decent shape, and modulo a little polishing as 
enumerated here it's basically ready, in my opinion.

  -- Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Mar 2011 15:27:27 -0600

<hat type='AD'/>

> other comments other than "its ready to go" - we need those as much as we need "I found a problem".

Sorry about the late comments.

Overall the spec is much improved from the last time I read it.
Naturally we all await the addition of the security considerations
section, so I won't comment on those aspects until I've had a chance to
read draft-lodderstedt-oauth-security in the next few days. Also I won't
comment on aspects that others have raised in during WGLC. Here are a
few additional points...

1. I think it would help in the Introduction to state specifically that
this protocol is designed for use on the web and with HTTP (i.e., use
with other application protocols is out of scope).

2. I find the concept of "implicit grant" to be a bit foggy in Section
1.4.2. A forward reference to Section 4.2 might help. (Also, it would be
good to reference draft-ietf-websec-origin from Section 4.2.)

3. In the definition of "token endpoint" in Section 2, should "used to
exchange an authorization grant for an access token" be "used to
exchange an authorization grant or refresh token for an access token"?

4. In Section 2.1, a reference to RFC 2616 would be nice at
"authorization server MUST support the use of the HTTP "GET" method".

5. Section 3 states:

   The authorization server SHOULD NOT issue client credentials to
   clients incapable of keeping their secrets confidential.

How does the authorization server know that a client is not capable of
keeping its secrets confidential?

6. Section 3.2 states:

   In cases where client password authentication is not suitable or
   sufficient, the authorization server MAY support other existing HTTP
   authentication schemes or define new methods.

What is meant by "new methods"?

7. The various subsections of Section 4 have lots of repeated text for
the parameter definitions (e.g., "client_id" and "scope", as well as the
error codes). I think it would be cleaner to define these once and
reference those definitions throughout the spec.

8. The various subsections of Section 4 also provide conflicting
information about various parameter values. For example, Section 4.1.1
says of "response_type" that it "MUST be set to "code"" whereas Section
4.2.1 says "MUST be set to "token"". It would reduce the possibility of
confusion to say "When the request is an authorization request, the
response_type MUST be set to "code"" or somesuch.

9. What is the expected lifetime of access tokens? Does it make sense to
have expires_at (in UTC) instead of, or in addition to, expires_in (a
number of seconds)?

10. In Section 4.3.2 there is an open issue regarding
internationalization of the client's username and password. What is the
current thinking about a resolution?

11. In Section 5.1, a reference to RFC 2616 would be good regarding the
HTTP "Cache-Control" response header field.

12. In Section 7, a reference to RFC 2671 would be good regarding the
HTTP "Authorization" request header.

13. In Section 8.2, are we really recommending "x_"? I must finish work
on draft-saintandre-xdash-considered-harmful...

14. In Sections 10.1 and 10.2, I'm uncomfortable with this text:

   Before a period of 14 days has passed, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision both to the review list and to IANA.  Denials should include
   an explanation and, if applicable, suggestions as to how to make the
   request successful.  Registration requests that are undetermined for
   a period longer than 21 days can be brought to the IESG's attention
   (using the [email-masked] mailing list) for resolution.

I suggest that we re-use the text from RFC 5988:

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the review list and IANA.  Denials should include an
   explanation and, if applicable, suggestions as to how to make the
   request successful.

   Decisions (or lack thereof) made by the Designated Expert can be
   first appealed to Application Area Directors (contactable using
   [email-masked] email address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied with the response, to the full IESG (using
   the [email-masked] mailing list).

15. Section 10.2.1 says:

   Parameter usage location:
      The location(s) where parameter can be used.  The possible
      locations are: authorization request, authorization response,
      token request, or token response.

Are those the only allowable locations? I notice that the bearer token
spec adds a locations of "resource request" and "resource response". I'm
not quite saying we need a registry of locations, but it might be good
to have a well-defined way of adding to the list of allowable locations
(otherwise a document like the bearer spec might need to say that it
updates the base spec).

16. In Section 11.1, I think RFC 2616 needs to be a normative reference.

That's it for now!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 15:11:36 -0700

I have started processing all the incoming feedback (expect responses to each note received). If you have additional feedback, I suggest it waits for the next draft (-14). However, if it is a blocking comment, please post to the list as soon as possible.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 17:04:26 -0700

> Of Torsten Lodderstedt
> Sent: Sunday, March 13, 2011 3:51 PM

> Since passwords represent authorization grants as well, I would suggest to
> adjust the wording to "intermediate or permanent"

Intermediate refers to their use in OAuth, and does not apply to their external existence.
 
> protected resources previously arranged with the authorization server."
> 
> Does this mean, the client is not the resource owner but gets access because
> of an existing authorization? How does this differ from an implicit grant?

The authorization server can provide users with a control panel with a list of pre-selected clients. The users can chose to authorize these clients directly without going through the authorization flow. Later, the client can use this grant type to access the user's protected resources because they have been pre-approved.
 
> authorization grant typically when the client is acting on its own behalf (the
> client is also the resource owner)."
> 
> What are the alternatives? I would suggest to remove "typically".

See above.
 
> authorization server SHOULD require TLS 1.2 and any additional transport-
> layer mechanism meeting its security requirements."
> 
> Why only "SHOULD" and not "MUST"? Otherwise, alternative means for
> Moreover, this is about the redirect_uri, isn't it? What about the endpoint's
> security itself, i.e. requests to this endpoint?

This is only about the confidentiality of the response, if the response includes credentials (bearer token, MAC token secret, etc.).

> section 2.1.1:
> 
> 3. paragraph: "The authorization server SHOULD require the client to pre-
> register their redirection URI or at least certain components such as the
> Pre-registered redirect_uri facilitate client authentication while tying a client
> to a certain deployment. Although this is typical practice nowdays I expect
> this to change if OAuth really gains traction for standard client software, such
> as mail clients.
> 

I think this should stay a SHOULD given it can improve security.

> That's to restrictive, probably client identification but not authentication.
> Otherwise, this endpoint cannot be used for most native apps.

New text in section 3 clarifies this:

   In addition, the authorization server MAY allow unauthenticated
   access token requests when the client identity does not matter (e.g.
   anonymous client) or when the client identity is established via
   other means.  For readability purposes only, this specification is
   written under the assumption that the authorization server requires
   some form of client authentication.  However, such language does not
   affect the authorization server's discretion in allowing
   unauthenticated client requests.

> I think it would be helpful for the reader to explain the purposes client
> identitification and authentication serve in OAuth. I see the following use
> cases (more text can be found in
> - Establish trust to the client and display relevant registration information to a
> user when requesting consent for authorization
> - Collate associated request to the same originator (e.g. a particular end-user
> authorization process and the corresponding request on the tokens endpoint
> to exchange the authorization code for tokens)

This goes beyond what the specification offers on other protocol elements. I added the following to section 3:

        The methods through which the client obtains its client credentials are beyond the scope of
        this specification. However, the client registration process typically includes gathering
        relevant information used to inform the resource owner about the client when requesting
        authorization.

> incapable of keeping their secrets confidential."
> 
> same client credentials should not be used for multiple installations of the
> same software, e.g. all instances of the same native app running on different
> PCs or smartphones."

I don't think this is necessary, but can be expanded in the security considerations section.
 
> when the client identity does not matter (e.g. anonymous client) or when
> the client identity is established via other means."
> 

Moved up to 3.
 
> section 4.1:
> 
> In my opinion, the introduction of this section over-emphasizes the aspect of
> client secrets & authentication while neglecting the other properties of the
> authorization code flow. Moreover, it encourages the impression this flow
> can only be used by clients equipped with a secret.
> This is wrong as this flow should be usable by clients w/o client secrets as well
> because it offers unique properties beside its aibility to support client
> authentication. In my opinion these are:
> 
> - user identity and credentials are not exposed to client (in contrast to
> resource owner password grant)
> - flow is especially suited for clients which are web applications (in contrast to
> implicit grant)
> - client credentials and tokens are sent over protected, direct communication
> channels between client and authorization server (no browser caches and
> HTTP referers involved)
> The introduction should explain all properties of the flow and offer some
> guidance when and how to use the flow.

I disagree. The code and implicit grants were explicitly designed to accommodate the two cases of clients with and without secrets. While the code grant can be used without a secret, it loses many of its properties. By narrowly defining the two profiles in such a way, we simplify the security considerations section, without restricting their applicability. Note that there is no MUST when it comes to client secrets. It is just an introduction.

I expect others to define and publish profiles of how to apply these two grant types to various cases typical for native applications. But beside good intentions, this group has not produced such a comprehensive document and it is too late to delay this work.

Also, as your list above shows, this is not a simple list but a feature matrix, comparing it to multiple grant types. I don't think an introduction will be helpful in selecting the right grant type, but a comprehensive analysis. If someone wants to try writing one, we can consider adding it, but it will have to be done in a matter of 2-3 weeks. Overall, I think a blog post will be as useful.

> section 4.1.3:
> Why is the name of the response type "code" whereas the name of the
> grant type is "authorization_code"?

Trying to be succinct on the wire. The prose is more descriptive.
 
> "redirect_uri" should only be required if it was an input parameter to the
> corresponding authz request.

No. It should be set to wherever the callback was sent to since sometimes servers allow both pre-registered and override.

> last paragraph: "Validate the client credentials and ensure they match the
> authorization code." should be "Validate the client credentials (if

See reply to your previous post.

> section 4.1.4:
> 
> "If the request failed due to failed client authentication or is invalid" - Some
> words missing here?
> 

Not sure what you mean.

> section 4.2.:
> 
> I'm struggeling with the name "implicit grant". Why not just stick with "User
> Agent Flow"? It has been designed for that kind of app.

The name should be descriptive of the grant characteristics, not its intended purpose (which would be incomplete and misleading). I'm open to other names, but not 'user agent'.

> As already mentioned for section 4.1., also this introduction puts to much
> emphasize on the client secret story. I don't think this was the original driver
> of its development. I would expect the intro to focus on the functional
> properties of the flow:
> 
> As I understand, it has been designed with JavaScript clients in mind, which
> due to the same origin policy, are unable to send requests directly to an
> authorization server outside of its origin. So instead of obtaining tokens
> through a POST request (via authz code), the access token is delivered
> directly via the redirect URI. In order to reduce the exposure of the token
> (and because it is sufficient), the access token is sent via the fragment. As a
> consequence of the design this flow does not support client authentication
> via secrets. The client's identity can nevertheless be validated using pre-
> registered redirect_uri's.
> 
> This flow cannot be used with web applications. And as long as the flow does
> not support refresh tokens, the same holds true for native apps (see also
> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01).

The design accommodates a few features:

1. Use fragment to improve performance (caching)
2. Use fragment to prevent token from being sent to the server hosting the client script for the redirection
3. Limited functionality (no refresh token) because of lack of client secrets

But again, If we want to provide a feature matrix to help developers choose the right grant type, that's one thing, but I am not going to change the simple introductions because it makes the rest of the protocol much simpler to explain and does not take sides in a debate (which profile to use when) which is far from settled.

> section 4.3:
> 
> 2. paragraph: I suggest to add "It is even possible to migrate from stored
> credentials to stored refresh tokens. Leakage of the later would have less
> impact."

I think this is redundant.

> Figure 5/ Step C) I suggest to add ", and optionally a refresh token."

Diagram has it. I think keep repeating it makes the document less readable.

> section 4.3.3
> 
> "If the access token request is valid and authorized, the authorization server
> issues an access token and optional refresh token as described in Section
> 5.1."
> 
> Since this is not an interactive flow, the authorization server cannot ask the
> resource owner.

Server policy.

> should be "The authorization server MUST validate the client credentials (if
> present), ..."

See above.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 18:35:33 -0700

> Of Chuck Mortimore
> Sent: Monday, March 14, 2011 6:10 PM

> 1) I'd vote for dropping the following from 1.4.2.   In turn I'd discuss some of
> the security considerations, such as difficulty of protecting a client_secret in
> almost all use-cases of this profile.
> 

Why drop it? What about it isn't accurate?

> 2) Section 2.1, we should MUST TLS even for Authorization Code.

Why? What's the attack vector?
 
> 3) Section 4.1.3 - not clear to me why redirect_uri is REQUIRED since in 4.1.1

The client should always confirm where the code was sent to. It can omit the redirection is one was provided but should tell the server where it went to. This is more consistent on the verification side, but if the original flow designers want to chime in (Dick, Brian, etc.?), I'm open to change this.

> 4) Section 4.2.2 - when did we drop refresh_token?     I assume this goes
> back to disagreement on how best to handle native clients. I'd prefer it to
> simply reference 5.1 and leave what is issued up to the security profile of the
> particular deployment as to what is issued.

-08 June 2010.

This has been decided for a long time. I'm not eager to change it.

EHL

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 Mar 2011 18:46:03 -0700

Phil
[email-masked]

> Why? What's the attack vector?

This was a big issue in the SAML Artifact profiles for which the OAuth authorization code is pretty much the same. You don't want to have the code hijacked/sniffed, etc, even if it is a one-time code or limited time code. I believe we talked about this in security considerations extensively.

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 24 Mar 2011 19:22:05 -0700

> Why drop it? What about it isn't accurate?

It's accurate, but my opinion is it sends the wrong message.   It's clearly the less secure of the response types.  By positioning it as the most performant people may find that attractive and make the wrong security decision. 

> Why? What's the attack vector?

See Phils comment on past experience with artifact bindings.  Spec should default for security always on, and let deployments that don't want to use HTTPs simply be non-conformant.  

> This has been decided for a long time. I'm not eager to change it.

Thanks - I can live with it.  Unfortunately we still seem to be fragmenting on the native client approach.   Good topic for IIW I suspect

-cmort

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 22:59:26 -0700

> From: Chuck Mortimore [mailto:[email-masked]]
> Sent: Thursday, March 24, 2011 7:22 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Chuck Mortimore
> >> the security considerations, such as difficulty of protecting a
> >> client_secret in almost all use-cases of this profile.
> >>
> It's accurate, but my opinion is it sends the wrong message.   It's clearly the
> less secure of the response types.  By positioning it as the most performant
> people may find that attractive and make the wrong security decision.

It is not less secure if you can't authenticate the client. If the application is running inside the browser, how is any other profile better? It is performing better for browsers and is actually more secure by not sending anything over to the server hosting the static scripts.

> See Phils comment on past experience with artifact bindings.  Spec should
> default for security always on, and let deployments that don't want to use
> HTTPs simply be non-conformant.

That does not explain the attack vector... The code is useless unless you have the ability to authenticate the client it was issued for. We have been requiring TLS solely because of secrets confidentiality (bearer token, MAC secret, client secret, etc.). This sounds like a different reason to require TLS, and I'm just trying to understand what it is.
 
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 23:55:30 -0700

> Of Justin Richer
> Sent: Wednesday, March 16, 2011 4:05 PM

> Preamble:
> 
> Does this document actually obsolete 5849? Since OAuth2 is explicitly not
> backwards compatible, is this WG really making the claim that we're updating
> OAuth, or rather defining a newer (and better) way of doing it?

People considering implementing 5849 should reconsider and implement this. So yeah.
 
> 1.4.2 (et al)
> 
> I still don't like the word "implicit" being used here, since there's really
> nothing implicit about it. The grant being made is explicit as far as the end
> user is concerned, and could even have an intermediary "do you authorize
> this?" screen in the middle. I'm still failing to come up with a better term than
> the original "user-agent" wording. What we're really talking about here is a
> way for an end user to directly authorize a client as opposed to doing a
> traditional double-redirect. So it's direct like client-credentials and username-
> and-password, but it's on behalf of a user and the client still never sees the
> user's credentials to the AS. We need, and have needed for some time, a
> better way to say this.

Implicit as in, there isn't any string or value being issues which represents it (as in authorization code, user password, etc.). You go from request to access token without anything in the middle - an authorization grant.

> more encompasing "extensions MAY define".

The only use cases we've seen for new endpoints are from new grant types (e.g. device flow).

> code." makes it sound like the client credentials and the authorization code
> are the same, or derived from each other. Suggest: "Validate the client
> credentials  and ensure that the client presenting the code is the same one
> the code was originally issued to." This phrasing also implies an architecture
> decision: access codes need to be bound to client id's.

                Verify that the authorization code is valid, and that the redirection URI matches
                the redirection URI used by the authorization server to deliver the authorization
                code.

> the spec without context.

I refuse to use bearer tokens as examples throughout the spec (or to waste a month talking about it), and I figured people will not be happy with using MAC examples exclusively (except for the two in section 7). So I am using a made up access token type 'example'. I'm happy to change it to MAC examples.

> 5
> 
> This section should probably point out that the poorly-named implicit flow
> doesn't use the format in here, and that the reader should go check out
> section 4.2 instead.

It's pretty clear when you read 4.2.
 
> belongs in developer guides.

I rather not touch the balance we have. This belongs elsewhere where scopes are expanded into something more specific.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Mar 2011 00:42:43 -0700

> Of Peter Saint-Andre
> Sent: Wednesday, March 23, 2011 2:27 PM

> 1. I think it would help in the Introduction to state specifically that this
> protocol is designed for use on the web and with HTTP (i.e., use with other
> application protocols is out of scope).

        This specification is designed for use with HTTP <xref target='RFC2616' />. The use of
        OAuth with any transport protocol other than HTTP is undefined.

> 2. I find the concept of "implicit grant" to be a bit foggy in Section 1.4.2. A
> forward reference to Section 4.2 might help. (Also, it would be good to
> reference draft-ietf-websec-origin from Section 4.2.)

New first paragraph for 1.4.2:

            When an access token is issued to the client directly as the result of the resource
            owner authorization, without an intermediary authorization grant (such as an
            authorization code), the grant is considered implicit.

I did my best to avoid any forward references, and the reference to same origin policy was dropped so not sure where the reference to draft-ietf-websec-origin fit.

> exchange an authorization grant for an access token" be "used to exchange
> an authorization grant or refresh token for an access token"?

I guess. A refresh token is an authorization grant of sorts.

> keeping its secrets confidential?

Ask. Most services ask about the client type in their registration process.

> What is meant by "new methods"?

New schemes, parameters, etc.

> 7. The various subsections of Section 4 have lots of repeated text for the
> parameter definitions (e.g., "client_id" and "scope", as well as the error
> codes). I think it would be cleaner to define these once and reference those
> definitions throughout the spec.

Tried that. It was nicer for the editor but much less readable. Most people are not expected to read the entire specification, just the parts they care about. This is the result of many long rewrites.
 
> 8. The various subsections of Section 4 also provide conflicting information
> about various parameter values. For example, Section 4.1.1 says of
> "response_type" that it "MUST be set to "code"" whereas Section

Added to 2.1:

   The REQUIRED "response_type" request parameter is used to identify
   which grant type the client is requesting: authorization code or
   implicit, described in Section 4.1.1 and Section 4.2.1 respectively.
   If the request is missing the "response_type" parameter, the
   authorization server SHOULD return an error response as described in
   Section 4.1.2.1.

> have expires_at (in UTC) instead of, or in addition to, expires_in (a number
> of seconds)?

Lifetime is out of scope. As for the parameter, we had a few long threads and the conclusion was that expires_in is easier to issue and as easy to parse. The client can always take the Date header and add the value to it. In low latency environments, this reduces the need for clock synchronization since the value is relative.

> 10. In Section 4.3.2 there is an open issue regarding internationalization of
> the client's username and password. What is the current thinking about a
> resolution?

Nothing. Leave it where HTTP Basic left it. Not ideal but after almost a year, no one offered a text (including the person who raised the issue).

> 13. In Section 8.2, are we really recommending "x_"? I must finish work on
> draft-saintandre-xdash-considered-harmful...

It's the simplest way to curve out a namespace for vendor specific parameters that have no value or place being registered. We can't use URI's for parameter names (that would be awful). Got other suggestions?

>    (using the [email-masked] mailing list) for resolution.

It's from RFC 5785 which was negotiated with the IESG before RFC 5988. I'll make the switch to 5988.

> Are those the only allowable locations? I notice that the bearer token spec
> adds a locations of "resource request" and "resource response". I'm not
> quite saying we need a registry of locations, but it might be good to have a
> well-defined way of adding to the list of allowable locations (otherwise a
> document like the bearer spec might need to say that it updates the base
> spec).

The bearer token proposal to extend the locations available is in violation of the protocol and specification architecture. It is just a really bad idea. Specifically, the idea of any registry defining HTTP URI query request parameters is a violation of the provider's namespace. We can define a registry for OAuth endpoints but not for protected resources which may not even support any URI query or form-encoded body parameters. Doing so would REQUIRE updating 2616.

There are no use cases or requirements for extending the locations and no extensibility is needed.

EHL

---

From: Phil Hunt <[email-masked]>
Date: Fri, 25 Mar 2011 12:41:51 -0700

Regarding the message: http://www.ietf.org/mail-archive/web/oauth/current/msg05762.html  (sorry I somehow lost the message in my email).

This issue is theft of the authorization code during the redirect. Authenticating the client is an important feature and goes a long way, but it is not sufficient since in many cases, the client_id/client_secret will likely be hard coded and relatively easy to deduce (e.g. mobile client apps).  Of course a strong client authentication won't have this issue. This makes many consumer situations very susceptible to an attack where the authorization code is intercepted.

For more information look at the SAML Artifact issues in section 6.5 (specifically stolen artifact, replay, etc) of this document: http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

There are a number of remediations suggested (small lifetime, single use), but the foundational one is confidentiality of the exchange (TLS). Hence the recommendation that the return of an authorization code be kept secure with a MUST for TLS.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Mar 2011 13:03:36 -0700

Unless someone has an objection, I'll make the change from SHOULD to MUST.

EHL

> From: Phil Hunt [mailto:[email-masked]]
> Sent: Friday, March 25, 2011 12:42 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG; Chuck & Mara Mortimore
> Regarding the message: http://www.ietf.org/mail-
> archive/web/oauth/current/msg05762.html  (sorry I somehow lost the
> message in my email).
> 
> This issue is theft of the authorization code during the redirect.
> Authenticating the client is an important feature and goes a long way, but it is
> not sufficient since in many cases, the client_id/client_secret will likely be
> hard coded and relatively easy to deduce (e.g. mobile client apps).  Of course
> a strong client authentication won't have this issue. This makes many
> consumer situations very susceptible to an attack where the authorization
> code is intercepted.
> 
> For more information look at the SAML Artifact issues in section 6.5
> (specifically stolen artifact, replay, etc) of this document: http://docs.oasis-
> open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
> 
> There are a number of remediations suggested (small lifetime, single use),
> but the foundational one is confidentiality of the exchange (TLS). Hence the
> recommendation that the return of an authorization code be kept secure
> with a MUST for TLS.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> >> The client should always confirm where the code was sent to. It can omit
> the redirection is one was provided but should tell the server where it went
> to. This is more consistent on the verification side, but if the original flow
> designers want to chime in (Dick, Brian, etc.?), I'm open to change this.
> >>
> >>> back to disagreement on how best to handle native clients. I'd
> >>> prefer it to simply reference 5.1 and leave what is issued up to the
> >>> security profile of the particular deployment as to what is issued.
> >>
> >> -08 June 2010.
> >>
> > Thanks - I can live with it.  Unfortunately we still seem to be fragmenting on
> the native client approach.   Good topic for IIW I suspect
> >
> > -cmort
> >
> >>
> >> EHL
> >>
> >>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 26 Mar 2011 14:56:00 +0100

[written while in transit, delivery will be delayed]

Thanks for the clarifications. A few comments and questions inline,
other topics elided for brevity.

> I guess. A refresh token is an authorization grant of sorts.

Section 1.4 is about authorization grants and Section 1.5 is about
refresh tokens, so I assumed that the latter is not included in the
former. Thus my confusion.

> Ask. Most services ask about the client type in their registration process.

Now that you phrase it that way, it makes sense (no in-band discovery
needed). Perhaps add a parenthetical phrase such as:

   The authorization server SHOULD NOT issue client credentials to
   clients incapable of keeping their secrets confidential (e.g., as
   determined when the client registers with the authorization server).

> Tried that. It was nicer for the editor but much less readable. Most people are not expected to read the entire specification, just the parts they care about. This is the result of many long rewrit…

OK, I just worry about saying the same thing in different places but in
slightly different ways. We'll want to harmonize them at the end (could
be handled via XML entities within the source document).

>    authorization server SHOULD return an error response as described in

WFM.

> Lifetime is out of scope. As for the parameter, we had a few long threads and the conclusion was that expires_in is easier to issue and as easy to parse. The client can always take the Date header…

OK.

> Nothing. Leave it where HTTP Basic left it. Not ideal but after almost a year, no one offered a text (including the person who raised the issue).

I think that's fine here given that these are the usernames and
passwords of automated clients, not human users (as RFC 2277 says,
"internationalization is for humans").

> It's the simplest way to curve out a namespace for vendor specific parameters that have no value or place being registered. We can't use URI's for parameter names (that would be awful). Got other s…

Not yet. I'll give it more thought.

> It's from RFC 5785 which was negotiated with the IESG before RFC 5988. I'll make the switch to 5988.

This was a bone of contention during IESG discussions of what became RFC
5988, so the language from the latter spec should be less controversial.

> There are no use cases or requirements for extending the locations and no extensibility is needed.

So will draft-ietf-oauth-v2-bearer be fixed?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 26 Mar 2011 14:56:20 -0700

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Saturday, March 26, 2011 6:56 AM

> > Nothing. Leave it where HTTP Basic left it. Not ideal but after almost a year,
> no one offered a text (including the person who raised the issue).
> 

This is the same as HTTP Basic, so these credentials belong to human users. We're just sticking out heads in the Basic Auth sand.
 
> > It's the simplest way to curve out a namespace for vendor specific
> parameters that have no value or place being registered. We can't use URI's
> for parameter names (that would be awful). Got other suggestions?
> 

One option is to use period as a reserved character for vendor-specific parameters such as  'yahoo.id' and 'google.lang'. This used to be a problem with older versions of PHP4 but I don't think it is an issue anymore.
 
> 5988, so the language from the latter spec should be less controversial.

Yep. Been there.
 
> spec
> > The bearer token proposal to extend the locations available is in violation of
> the protocol and specification architecture. It is just a really bad idea.
> Specifically, the idea of any registry defining HTTP URI query request
> parameters is a violation of the provider's namespace. We can define a
> registry for OAuth endpoints but not for protected resources which may not
> even support any URI query or form-encoded body parameters. Doing so
> would REQUIRE updating 2616.
> >

Mike Jones is still pushing for this change, and in a way, holding the bearer token spec hostage... :-)

EHL

---

From: Justin Richer <[email-masked]>
Date: Mon, 28 Mar 2011 13:05:09 -0400

What about non-http return uri's, or client-localhost, such as 

  someapp://app/?code=foo

  http://localhost:87345/?code=foo

HTTPS makes sense when you're talking between two web servers, but it
seems to fall apart otherwise. I think SHOULD is appropriate here.

 -- Justin

---

From: George Fletcher <[email-masked]>
Date: Mon, 28 Mar 2011 14:54:30 -0400

+1 for SHOULD

... with a reference to the Security Considerations section that 
addresses the issues. The one we're facing right now with this, is that 
for easy development it's nice to allow the redirect_uri to be 
http://localhost :) For production deployments, I agree that TLS is the 
best option.

Thanks,
George

On 3/28/11 1:05 PM, Justin Richer wrote:
>>> Cc: OAuth WG; Chuck&  Mara Mortimore

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Mar 2011 12:52:57 -0700

No change then. But the security considerations section must reflect this.

EHL

> From: Justin Richer [mailto:[email-masked]]
> Sent: Monday, March 28, 2011 10:05 AM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; OAuth WG
> > > Authenticating the client is an important feature and goes a long
> > > way, but it is not sufficient since in many cases, the
> > > client_id/client_secret will likely be hard coded and relatively
> > > easy to deduce (e.g. mobile client apps).  Of course a strong client
> > > authentication won't have this issue. This makes many consumer
> > > situations very susceptible to an attack where the authorization code is
> intercepted.
> > >
> > > There are a number of remediations suggested (small lifetime, single
> > > use), but the foundational one is confidentiality of the exchange
> > > (TLS). Hence the recommendation that the return of an authorization
> > > code be kept secure with a MUST for TLS.
> > >
> > > Phil
> > > [email-masked]
> > >
> > >
> > >
> > >
> > > >>> 1) I'd vote for dropping the following from 1.4.2.   In turn I'd discuss
> some
> > > of
> > > less secure of the response types.  By positioning it as the most
> > > performant people may find that attractive and make the wrong security
> decision.
> > > >
> > > >
> > > >>
> > > default for security always on, and let deployments that don't want
> > > to use HTTPs simply be non-conformant.
> > > >
> > > >>
> > > the redirection is one was provided but should tell the server where
> > > it went to. This is more consistent on the verification side, but if
> > > the original flow designers want to chime in (Dick, Brian, etc.?), I'm open
> to change this.
> > > >>
> > > >>> prefer it to simply reference 5.1 and leave what is issued up to
> > > >>> the security profile of the particular deployment as to what is issued.
> > > >>
> > > >> -08 June 2010.
> > > >>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Mar 2011 13:25:04 -0700

Justin, How is that so? Remember firesheep?  I wouldn't want the authorization code being exchanged without TLS in a cafe. Intercept is just too easy. And as I mentioned earlier, client credentials are already very weak in many cases. In contrast, two web servers are hard to sniff unless you are able to gain access to their network communications path.

As for testing, it seems more reasonable to put servers in temporary non-compliance while testing rather then allow non-secure servers in production because of the SHOULD loophole. 

Also, while it does seem convenient for the developer not to have to use TLS for authz codes, note that the developer still has to have TLS enabled when exchanging the code for an access token. So I'm not sure how relaxing TLS for obtaining authorization actually simplifies the developer lifecycle since they still have to set it up to test the other parts.  In my view, it would be ok for a developer to temporarily disable TLS everywhere during development -- which places operation outside RFC compliance while developing -- but forces compliance once they go into production.

It seems like I had to give a pretty substantial justification and we backed off because TLS is seen as inconvenient. I think we need more evidence that there are safe cases that don't need TLS.

Sorry for pushing hard on this one, but TLS is the backbone of OAuth security at present.

Phil
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 28 Mar 2011 16:37:06 -0400

Phil,

The main difference is that it's a requirement on the *client* instead
of the *provider* side of the equation, and clients aren't always even
speaking HTTP. I agree that all client web servers SHOULD do it. A
particular provider can even REQUIRE it for their registered clients, a
step that is outside the scope of OAuth. But there are real, in-use
patterns that don't require the client to make an HTTP request to an
external service. 

I don't see how Firesheep is relevant to this discussion -- if your
browser is making a call to localhost to get the token, who outside of
your machine is going to do it? I'm not talking about convenience for
developers here (which I would argue should NOT be discounted, but
that's another argument), I'm talking about cases where the browser
isn't going outside of a trusted security boundary. There are also
instances where there may not even be an HTTP transaction involved, let
alone one that could support TLS.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Mar 2011 14:27:55 -0700

This was referring to section 2.1 that the authorization server must use TLS when returning an authorization code.

If it doesn't use TLS then the code being returned to the client can be intercepted.

Or did I miss something?

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 28 Mar 2011 15:28:20 -0700

The code is returned in two steps:

1. The authorization server replies to the user-agent request (providing authorization) with a redirection instruction typically using the Location response header field.
2. The user-agent makes an HTTP GET request to the provided location (which may be something other than an HTTP URI, or an HTTP URI to localhost).

#1 is an HTTP response to a user-agent request to the authorization endpoint (or a subsequent one if the server implementation has multiple authorization steps).

#2 is an HTTP request made by the user-agent.

In order for the code to be secure end-to-end, both steps must use TLS. The arguments made against making TLS required are based on use cases for #2. We can make #1 (the authorization endpoint require TLS since it already has to support it for the 'token' response type. We should make callbacks a SHOULD for TLS.

Does this sound like a reasonable compromise?

EHL

> Sent: Monday, March 28, 2011 2:28 PM
> To: Justin Richer
> Cc: Eran Hammer-Lahav; OAuth WG
> > particular provider can even REQUIRE it for their registered clients,
> > a step that is outside the scope of OAuth. But there are real, in-use
> > instances where there may not even be an HTTP transaction involved,
> > let alone one that could support TLS.
> >
> > -- Justin
> >
> >> Justin, How is that so? Remember firesheep?  I wouldn't want the
> authorization code being exchanged without TLS in a cafe. Intercept is just
> too easy. And as I mentioned earlier, client credentials are already very weak
> in many cases. In contrast, two web servers are hard to sniff unless you are
> able to gain access to their network communications path.
> >>
> >> As for testing, it seems more reasonable to put servers in temporary non-
> compliance while testing rather then allow non-secure servers in production
> because of the SHOULD loophole.
> >>
> >> Also, while it does seem convenient for the developer not to have to use
> TLS for authz codes, note that the developer still has to have TLS enabled
> when exchanging the code for an access token. So I'm not sure how relaxing
> TLS for obtaining authorization actually simplifies the developer lifecycle since
> they still have to set it up to test the other parts.  In my view, it would be ok
> for a developer to temporarily disable TLS everywhere during development -
> - which places operation outside RFC compliance while developing -- but
> forces compliance once they go into production.
> >>
> >> It seems like I had to give a pretty substantial justification and we backed
> off because TLS is seen as inconvenient. I think we need more evidence that
> there are safe cases that don't need TLS.
> >>
> >>>> HTTPS makes sense when you're talking between two web servers, but
> >>>> it seems to fall apart otherwise. I think SHOULD is appropriate here.
> >>>>
> >>>> -- Justin
> >>>>
> >>>>
> >>>>> Unless someone has an objection, I'll make the change from SHOULD
> >>>>> to
> >>>> MUST.
> >>>>>
> >>>>> EHL
> >>>>>
> >>>>>> archive/web/oauth/current/msg05762.html  (sorry I somehow lost
> >>>>>> the message in my email).
> >>>>>>
> >>>>>> easy to deduce (e.g. mobile client apps).  Of course a strong
> >>>>>> client authentication won't have this issue. This makes many
> >>>>>> consumer situations very susceptible to an attack where the
> >>>>>> authorization code is
> >>>> intercepted.
> >>>>>>
> >>>>>> For more information look at the SAML Artifact issues in section
> >>>>>> 6.5 (specifically stolen artifact, replay, etc) of this document:
> >>>>>> http://docs.oasis-
> >>>>>> There are a number of remediations suggested (small lifetime,
> >>>>>> single use), but the foundational one is confidentiality of the
> >>>>>> exchange (TLS). Hence the recommendation that the return of an
> >>>>>> authorization code be kept secure with a MUST for TLS.
> >>>>>>
> >>>>>> Phil
> >>>>>> [email-masked]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>> From: [email-masked] [mailto:oauth-
> [email-masked]]
> >>>>>>>>> On Behalf Of Chuck Mortimore
> >>>>>>>>> the security considerations, such as difficulty of protecting
> >>>>>>>>> a client_secret in almost all use-cases of this profile.
> >>>>>>>>>
> >>>>>>>>>  "Implicit grants improve the responsiveness and efficiency of
> >>>>>>>>> some clients (such as a client implemented as an in-browser
> >>>>>>>>> application) since it reduces the number of round trips
> >>>>>>>>> required to obtain an access token."
> >>>>>>>>
> >>>>>>> It's accurate, but my opinion is it sends the wrong message.   It's
> clearly
> >>>> the
> >>>>>> default for security always on, and let deployments that don't
> >>>>>> want to use HTTPs simply be non-conformant.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> 3) Section 4.1.3 - not clear to me why redirect_uri is
> >>>>>>>>> REQUIRED since in 4.1.1 it's "REQUIRED unless"
> >>>>>>>>
> >>>>>> the redirection is one was provided but should tell the server
> >>>>>> where it went to. This is more consistent on the verification
> >>>>>> side, but if the original flow designers want to chime in (Dick,
> >>>>>> Brian, etc.?), I'm open
> >>>> to change this.
> >>>>>>>>
> >>>>>>>>> 4) Section 4.2.2 - when did we drop refresh_token?     I assume
> this
> >>>> goes
> >>>>>>>>> prefer it to simply reference 5.1 and leave what is issued up
> >>>>>>>>> to the security profile of the particular deployment as to what is
> issued.
> >>>>>>>>
> >>>>>>>> -08 June 2010.
> >>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 28 Mar 2011 15:31:51 -0700

Thanks for the clarification.  Yes, the compromise makes sense.

Phil
[email-masked]

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 10:05:24 -0700 (PDT)

Eran,

It's not a reasonable compromise.  #2 MUST use tls UNLESS of course it targets localhost.  If #2 is sent without TLS to a Web server, the authorization code can be easily intercepted by an attacker.  The attacker can then use it to obtain protected resources by submitting the authorization code to the client.  (This is independent of whether the client authenticates itself when exchanging the authorization code for an access token or not.) In the Facebook use case, the attacker can use the authorization code to log in to the client using the user's Facebook identity.  I believe this vulnerability exists in many implementations of the Facebook login button today.

Btw, I've pointed this out before three or four times on this mailing list, including in a response to the WGLC that you never replied to.

Francisco

--- On Mon, 3/28/11, Eran Hammer-Lahav <[email-masked]> wrote:

From: Eran Hammer-Lahav <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "Phil Hunt" <[email-masked]>, "Justin Richer" <[email-masked]>
Cc: "OAuth WG" <[email-masked]>
Date: Monday, March 28, 2011, 10:28 PM

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 10:42:57 -0700

Can you explain how intercepting the authorization code without having access to the client credentials is a problem? For the sake of discussion, assume that the client has valid and secure credentials that an attacker cannot access. Also assume that the client has implemented some form of cross-site protection.

I don't know much about FB's implementation but if they allow the authorization code to be used for anything other than exchanged for an access token using secure client credentials, then they are not implementing the protocol as specified.

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 10:05 AM
To: Phil Hunt; Justin Richer; Eran Hammer-Lahav
Cc: OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Eran,

Francisco

--- On Mon, 3/28/11, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Justin Richer" <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 28, 2011, 10:28 PM
The code is returned in two steps:

EHL

> From: Phil Hunt [mailto:[email-masked]</mc/compose?to=[email-masked]>]
> [email-masked]</mc/compose?to=[email-masked]>
>
>
>
>
> >> [email-masked]</mc/compose?to=[email-masked]>
> >>
> >>
> >>
> >>
> >>>> From: Justin Richer [mailto:[email-masked]</mc/compose?to=[email-masked]>]
> >>>>>> From: Phil Hunt [mailto:[email-masked]</mc/compose?to=[email-masked]>]
> >>>>>> [email-masked]</mc/compose?to=[email-masked]>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Mar 24, 2011, at 6:36 PM, "Eran Hammer-Lahav"
> >>>>>> <[email-masked]</mc/compose?to=[email-masked]>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> From: [email-masked]</mc/compose?to=[email-masked]> [mailto:oauth-
> [email-masked]</mc/compose?to=[email-masked]>]
> >>>>>>> [email-masked]</mc/compose?to=[email-masked]>
> >>>>> [email-masked]</mc/compose?to=[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]</mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Tue, 29 Mar 2011 13:53:12 -0400

Along this same line...

To make sure I understand, the attacker must execute a MITM attack 
against the redirect_uri so that it receives the code value and ensures 
the code value is never exchanged at the authorization service by the 
original requester. Then the attacker takes the code and presents it to 
the same service but under a different controlling party. This ensures 
that the correct client authentication takes place and associates the 
delegated authorization with a different user at the "client" service.

Basically, Alice goes to example.com and authenticates with her 
example.com credentials. She then tries to associate resources 
socialsite.example.com. The MITM attacker captures the code when 
socialsite.example.com redirects the browser to example.com. The MITM 
attacker returns an error to Alice.

The Attacker then logs into example.com with a different set of 
credentials. When the attacker tries to associate resources from 
socialsite.example.com, the MITM attack returns Alice's code to 
example.com. Example.com then retrieves the access_token and associates 
Alice's resources to the attackers identity at example.com.

So I see this as an exposure where the client has it's own idea of who 
the user is and is then using OAuth to associate resources with the that 
user.

Thanks,
George

On 3/29/11 1:42 PM, Eran Hammer-Lahav wrote:
>
> Can you explain how intercepting the authorization code without having 
> access to the client credentials is a problem? For the sake of 
> discussion, assume that the client has valid and secure credentials 
> that an attacker cannot access. Also assume that the client has 
> implemented some form of cross-site protection.
>
> I don’t know much about FB’s implementation but if they allow the 
> authorization code to be used for anything other than exchanged for an 
> access token using secure client credentials, then they are not 
> implementing the protocol as specified.
>
> EHL
>
> *From:*Francisco Corella [mailto:[email-masked]]
> *Sent:* Tuesday, March 29, 2011 10:05 AM
> *To:* Phil Hunt; Justin Richer; Eran Hammer-Lahav
> *Cc:* OAuth WG; Karen P. Lewison
> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>
> Eran,
>
> It's not a reasonable compromise.  #2 MUST use tls UNLESS of course it 
> targets localhost.  If #2 is sent without TLS to a Web server, the 
> authorization code can be easily intercepted by an attacker.  The 
> attacker can then use it to obtain protected resources by submitting 
> the authorization code to the client.  (This is independent of whether 
> the client authenticates itself when exchanging the authorization code 
> for an access token or not.) In the Facebook use case, the attacker 
> can use the authorization code to log in to the client using the 
> user's Facebook identity.  I believe this vulnerability exists in many 
> implementations of the Facebook login button today.
>
> Btw, I've pointed this out before three or four times on this mailing 
> list, including in a response to the WGLC that you never replied to.
>
> Francisco
>
> --- On *Mon, 3/28/11, Eran Hammer-Lahav /<[email-masked] 
> <mailto:[email-masked]>>/* wrote:
>
>
> From: Eran Hammer-Lahav <[email-masked] <mailto:[email-masked]>>
> To: "Phil Hunt" <[email-masked] <mailto:[email-masked]>>, 
> "Justin Richer" <[email-masked] <mailto:[email-masked]>>
> Cc: "OAuth WG" <[email-masked] <mailto:[email-masked]>>
> 1. The authorization server replies to the user-agent request 
> (providing authorization) with a redirection instruction typically 
> using the Location response header field.
> 2. The user-agent makes an HTTP GET request to the provided location 
> (which may be something other than an HTTP URI, or an HTTP URI to 
> localhost).
>
> #1 is an HTTP response to a user-agent request to the authorization 
> endpoint (or a subsequent one if the server implementation has 
> multiple authorization steps).
>
> In order for the code to be secure end-to-end, both steps must use 
> TLS. The arguments made against making TLS required are based on use 
> cases for #2. We can make #1 (the authorization endpoint require TLS 
> since it already has to support it for the 'token' response type. We 
> should make callbacks a SHOULD for TLS.
>
> > This was referring to section 2.1 that the authorization server must 
> use TLS
> > when returning an authorization code.
> >
> > [email-masked] </mc/compose?to=[email-masked]>
> >
> >
> >
> >
> > >> [email-masked] </mc/compose?to=[email-masked]>
> > >>
> > >>
> > >>
> > >>
> > >>>>>> [email-masked] </mc/compose?to=[email-masked]>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> <[email-masked] </mc/compose?to=[email-masked]>> wrote:
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>> From: [email-masked] 
> </mc/compose?to=[email-masked]> [mailto:oauth-
> > [email-masked] </mc/compose?to=[email-masked]>]
> > >>>>>>>>> 1) I'd vote for dropping the following from 1.4.2.   In 
> turn I'd
> > discuss
> > >>>> some
> > >>>>>> of
> > >>>>>>> [email-masked] </mc/compose?to=[email-masked]>
> > >>>>> [email-masked] </mc/compose?to=[email-masked]>
> [email-masked] </mc/compose?to=[email-masked]>
> =

---

From: George Fletcher <[email-masked]>
Date: Tue, 29 Mar 2011 13:55:27 -0400

Hi Francisco,

So the examples that Justin gave were either localhost or non HTTP based 
schemes. If OAuth2 is to support these other schemes (often used in 
mobile clients) then I'm not sure how TLS can be a MUST unless it's 
qualified to apply to HTTP based URLs only.

Is it sufficient to document this possible exposure in the security 
section such that the spec doesn't preclude the use of OAuth2 with non 
HTTP based redirect_uri?

Thanks,
George

On 3/29/11 1:05 PM, Francisco Corella wrote:
> --- On *Mon, 3/28/11, Eran Hammer-Lahav /<[email-masked]>/* wrote:
>
>
>     2. The user-agent makes an HTTP GET request to the provided
>     location (which may be something other than an HTTP URI, or an
>     HTTP URI to localhost).
>
>     #1 is an HTTP response to a user-agent request to the
>     authorization endpoint (or a subsequent one if the server
>     implementation has multiple authorization steps).
>
>     TLS. The arguments made against making TLS required are based on
>     use cases for #2. We can make #1 (the authorization endpoint
>     require TLS since it already has to support it for the 'token'
>     response type. We should make callbacks a SHOULD for TLS.
>
>     > This was referring to section 2.1 that the authorization server
>     must use TLS
>     > If it doesn't use TLS then the code being returned to the client
>     can be
>     > intercepted.
>     >
>     > Or did I miss something?
>     >
>     > Phil
>     > >> Sorry for pushing hard on this one, but TLS is the backbone
>     of OAuth
>     > security at present.
>     > >>
>     > >> Phil
>     > >>> No change then. But the security considerations section must
>     reflect
>     > this.
>     > >>>
>     > >>> EHL
>     > >>>
>     > >>>>>> <[email-masked]
>     </mc/compose?to=[email-masked]>> wrote:
>     > >>>>>>>
>     > >>>>>>>>
>     > >>>>>>>>> 1) I'd vote for dropping the following from
>     1.4.2.   In turn I'd
>     > discuss
>     > >>>> some
>     > >>>>>> of
>     > >>>>>>>> The client should always confirm where the code was
>     sent to. It
>     > >>>>>>>> can omit
>     > >>>>>>> Thanks - I can live with it.  Unfortunately we still
>     seem to be
>     > >>>>>>> fragmenting on

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Mar 2011 11:03:27 -0700

My primary concern is that when the authorization code is handed back to the target app (in this case by way of redirect through a user-agent/browser), then the return path to the browser is at least secure.  If the browser/user-agent is redirecting to a local app, then no big deal. BUT, if the app is redirecting back to a web service, then that path too must be secure.

So both #1 and #2 (described earlier) MUST be secure unless redirect is local in which case 2 (outgoing GET by user agent) is optional since it cannot be scanned.  

I think SHOULD is too weak (too broad). I'd rather have a MUST with an appropriate specific exception to cover the local portion of the redirect.

Phil
[email-masked]

On 2011-03-29, at 10:55 AM, George Fletcher wrote:

> Hi Francisco,
> 
> So the examples that Justin gave were either localhost or non HTTP based schemes. If OAuth2 is to support these other schemes (often used in mobile clients) then I'm not sure how TLS can be a MUST unless it's qualified to apply to HTTP based URLs only.
> 
> Is it sufficient to document this possible exposure in the security section such that the spec doesn't preclude the use of OAuth2 with non HTTP based redirect_uri?
> 
> Thanks,
> George
> 
>> > >>>>>> <[email-masked]> wrote:
>> > >>>>>>>
>> > >>>>>>>>

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 11:45:58 -0700 (PDT)

> Can you explain how intercepting the authorization code
> without having access to the client credentials is a
> problem? For the sake of discussion, assume that the client
> has valid and secure credentials that an attacker cannot
> access. Also assume that the client has implemented some
> form of cross-site protection.

One way: man-in-the-middle attack.  The traffic between the legitimate
user's browser and the client goes through the attacker's machine
(easy to set up with a rogue WiFi access point).  The user's browser
sends an http request to the client, targeting the redirect URI.  The
attacker's machine doesn't let that request go through.  The attacker
then sends the same identical request from the attacker's own browser.
When the client receives the request, it has no way to tell that it is
coming from the attacker's browser rather than from the user's
browser.  The client exchanges the authorization code for an access
token, uses the access token to obtain protected resources belonging
to the user, and delivers those resources to the attacker's browser.
(Or manipulates those resources as directed by the attacker's
browser.)  In the Facebook use case, the client logs the user in upon
verifying that the authorization code is valid by exchanging it
successfully for an access token.

Another way (passive attack): The attacker observes the request from
the user's browser to the client.  The attacker does not stop the
request.  The client receives the request with the authorization code
and exchanges the authorization code for the access token.  Now the
attacker sends the same request from the attacker's own browser.  The
client receives the second request and exchanges the authorization
code for another access token.  Upon receiving the second request for
the same authorization code, the authorization server revokes the
first access token, as suggested in section 4.1.2 of the
specification: "If an authorization code is used more than once, the
auhorization server MAY revoke all tokens previously issued based on
that authorization code".  The client then uses the second access
token to access protected resources for the benefit of the attacker.
In the Facebook use case, the attacker is logged in as the legitimate
user.

> I don‚Äôt know much about FB‚Äôs implementation but if they
> allow the authorization code to be used for anything other
> than exchanged for an access token using secure client
> credentials, then they are not implementing the protocol as
> specified.

Facebook uses the protocol correctly, but the examples in the Facebook
documentation use http rather than https for redirect URIs, so
implementations that follow the examples use http rather than https.

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 12:03:50 -0700 (PDT)

George,

Yes, that's another attack scenario.  (It would be clearer if the social site where not a subdomain of example.com).  In your scenario, the user and the attacker have ordinary credentials (userid and password) with the client (example.com) and they both log in to the client before the attack.  In the "login with Facebook" scenario, neither the user nor the attacker need to have password credentials with the client.  The attacker does not need to have an account with the client, and gets logged with the client as the user as a result of the attack.

Franciso

--- On Tue, 3/29/11, George Fletcher <[email-masked]> wrote:

From: George Fletcher <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "[email-masked]" <[email-masked]>
Cc: "Eran Hammer-Lahav" <[email-masked]>, "Phil Hunt" <[email-masked]>, "Justin Richer" <[email-masked]>, "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Tuesday, March 29, 2011, 5:53 PM

  Along this same line...

    To make sure I
      understand, the attacker must execute a MITM attack against the
      redirect_uri so that it receives the code value and ensures the
      code value is never exchanged at the authorization service by the
      original requester. Then the attacker takes the code and presents
      it to the same service but under a different controlling party.
      This ensures that the correct client authentication takes place
      and associates the delegated authorization with a different user
      at the "client" service.

      Basically, Alice goes to example.com and authenticates with her
      example.com credentials. She then tries to associate resources
      socialsite.example.com. The MITM attacker captures the code when
      socialsite.example.com redirects the browser to example.com. The
      MITM attacker returns an error to Alice.

      The Attacker then logs into example.com with a different set of
      credentials. When the attacker tries to associate resources from
      socialsite.example.com, the MITM attack returns Alice's code to
      example.com. Example.com then retrieves the access_token and
      associates Alice's resources to the attackers identity at
      example.com.

      So I see this as an exposure where the client has it's own idea of
      who the user is and is then using OAuth to associate resources
      with the that user. 

      Thanks,

      George

      

        Can you explain how intercepting the
            authorization code without having access to the client
            credentials is a problem? For the sake of discussion, assume
            that the client has valid and secure credentials that an
            attacker cannot access. Also assume that the client has
            implemented some form of cross-site protection. 
           
        I don’t know much about FB’s implementation but
            if they allow the authorization code to be used for anything
            other than exchanged for an access token using secure client
            credentials, then they are not implementing the protocol as
            specified. 
           
        EHL 

            
              From: Francisco
                  Corella [mailto:[email-masked]] 

                  Subject: Re: [OAUTH-WG] WGLC on
                  draft-ietf-oauth-v2-13.txt 

              
                
                  Eran,

                    It's not a reasonable compromise.  #2 MUST use tls
                    UNLESS of course it targets localhost.  If #2 is
                    sent without TLS to a Web server, the authorization
                    code can be easily intercepted by an attacker.  The
                    attacker can then use it to obtain protected
                    resources by submitting the authorization code to
                    the client.  (This is independent of whether the
                    client authenticates itself when exchanging the
                    authorization code for an access token or not.) In
                    the Facebook use case, the attacker can use the
                    authorization code to log in to the client using the
                    user's Facebook identity.  I believe this
                    vulnerability exists in many implementations of the
                    Facebook login button today.

                    Btw, I've pointed this out before three or four
                    times on this mailing list, including in a response
                    to the WGLC that you never replied to.

                    Francisco

                    --- On Mon, 3/28/11, Eran Hammer-Lahav <[email-masked]>
                    wrote: 

                    Subject: Re: [OAUTH-WG] WGLC on
                    draft-ietf-oauth-v2-13.txt

                    To: "Phil Hunt" <[email-masked]>,
                    "Justin Richer" <[email-masked]>

                  
                    The code is returned in two
                      steps:

                      1. The authorization server replies to the
                      user-agent request (providing authorization) with
                      a redirection instruction typically using the
                      Location response header field.

                      2. The user-agent makes an HTTP GET request to the
                      provided location (which may be something other
                      than an HTTP URI, or an HTTP URI to localhost).

                      #1 is an HTTP response to a user-agent request to
                      the authorization endpoint (or a subsequent one if
                      the server implementation has multiple
                      authorization steps).

                      In order for the code to be secure end-to-end,
                      both steps must use TLS. The arguments made
                      against making TLS required are based on use cases
                      for #2. We can make #1 (the authorization endpoint
                      require TLS since it already has to support it for
                      the 'token' response type. We should make
                      callbacks a SHOULD for TLS.

                      EHL

                      > This was referring to section 2.1 that the
                      authorization server must use TLS

                      > If it doesn't use TLS then the code being
                      returned to the client can be

                      > >> As for testing, it seems more
                      reasonable to put servers in temporary non-

                      > >> Sorry for pushing hard on this one,
                      but TLS is the backbone of OAuth

                      > >>> No change then. But the security
                      considerations section must reflect

                      > >>>> HTTPS makes sense when
                      you're talking between two web servers, but

                      > >>>> it seems to fall apart
                      otherwise. I think SHOULD is appropriate here.

                      > >>>>> Unless someone has an
                      objection, I'll make the change from SHOULD

                      > >>>>>> To: Eran
                      Hammer-Lahav

                      > >>>>>> Subject: Re:
                      [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

                      archive/web/oauth/current/msg05762.html  (sorry I
                      somehow lost

                      > >>>>>> the message in my
                      email).

                      > >>>>>> This issue is theft
                      of the authorization code during the redirect.

                      > >>>>>> Authenticating the
                      client is an important feature and goes a long

                      client_id/client_secret will likely be hard coded
                      and relatively

                      > >>>>>> client
                      authentication won't have this issue. This makes
                      many

                      > >>>>>> authorization code
                      is

                      > >>>>>> For more information
                      look at the SAML Artifact issues in section

                      > >>>>>> 6.5 (specifically

                      > >>>>>> There are a number
                      of remediations suggested (small lifetime,

                      > >>>>>> single use), but the
                      foundational one is confidentiality of the

                      > >>>>>> exchange (TLS).
                      Hence the recommendation that the return of an

                      -----Original Message-----

                      > >>>>>>>>> From: [email-masked]
                      [mailto:oauth-

                      > >>>>>>>>> 1) I'd
                      vote for dropping the following from 1.4.2.   In
                      turn I'd

                      > >>>>>>>>> the
                      security considerations, such as difficulty of
                      protecting

                      > >>>>>>>>> a
                      client_secret in almost all use-cases of this
                      profile.

                      "Implicit grants improve the responsiveness and
                      efficiency of

                      > >>>>>>>>> some
                      clients (such as a client implemented as an
                      in-browser

                      application) since it reduces the number of round
                      trips

                      > >>>>>>> It's accurate,
                      but my opinion is it sends the wrong
                      message.   It's

                      > >>>>>> less secure of the
                      response types.  By positioning it as the most

                      > >>>>>> performant people
                      may find that attractive and make the wrong

                      > >>>>>> security

                      > >>>>>>>>> 2)
                      Section 2.1, we should MUST TLS even for
                      Authorization Code.

                      > >>>>>>> See Phils
                      comment on past experience with artifact bindings.

                      > >>>>>>> Spec should

                      > >>>>>> default for security
                      always on, and let deployments that don't

                      > >>>>>>>>> 3)
                      Section 4.1.3 - not clear to me why redirect_uri
                      is

                      > >>>>>>>> The client
                      should always confirm where the code was sent to.
                      It

                      > >>>>>> the redirection is
                      one was provided but should tell the server

                      > >>>>>> where it went to.
                      This is more consistent on the verification

                      > >>>>>> side, but if the
                      original flow designers want to chime in (Dick,

                      > >>>>>> Brian, etc.?), I'm
                      open

                      > >>>>>>>>> 4)
                      Section 4.2.2 - when did we drop refresh_token? 
                         I assume

                      > >>>>>>>>> back to
                      disagreement on how best to handle native clients.
                      I'd

                      > >>>>>>>>> prefer
                      it to simply reference 5.1 and leave what is
                      issued up

                      > >>>>>>>>> to the
                      security profile of the particular deployment as
                      to what is

                      > >>>>>>>> -08 June
                      2010.

                      > >>>>>>>> This has
                      been decided for a long time. I'm not eager to
                      change it.

                      > >>>>>>> Thanks - I can
                      live with it.  Unfortunately we still seem to be

                      > >>>>>>> OAuth mailing
                      list

                      OAuth mailing list

                      [email-masked]

              

      =

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 12:05:14 -0700 (PDT)

I agree.        - Francisco

--- On Tue, 3/29/11, Phil Hunt <[email-masked]> wrote:

From: Phil Hunt <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "George Fletcher" <[email-masked]>
Cc: [email-masked], "Justin Richer" <[email-masked]>, "Eran Hammer-Lahav" <[email-masked]>, "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Tuesday, March 29, 2011, 6:03 PM

[email-masked]

    Hi Francisco,

      So the examples that Justin gave were either localhost or non HTTP
      based schemes. If OAuth2 is to support these other schemes (often
      used in mobile clients) then I'm not sure how TLS can be a MUST
      unless it's qualified to apply to HTTP based URLs only.

      Is it sufficient to document this possible exposure in the
      security section such that the spec doesn't preclude the use of
      OAuth2 with non HTTP based redirect_uri?

      Thanks,

      George

        
          
            Eran,

              It's not a reasonable compromise.  #2 MUST use tls UNLESS
              of course it targets localhost.  If #2 is sent without TLS
              to a Web server, the authorization code can be easily
              intercepted by an attacker.  The attacker can then use it
              to obtain protected resources by submitting the
              authorization code to the client.  (This is independent of
              whether the client authenticates itself when exchanging
              the authorization code for an access token or not.) In the
              Facebook use case, the attacker can use the authorization
              code to log in to the client using the user's Facebook
              identity.  I believe this vulnerability exists in many
              implementations of the Facebook login button today.

              Btw, I've pointed this out before three or four times on
              this mailing list, including in a response to the WGLC
              that you never replied to.

              Francisco

                To: "Phil Hunt" <[email-masked]>, "Justin
                Richer" <[email-masked]>

                  1. The authorization server replies to the user-agent
                  request (providing authorization) with a redirection
                  instruction typically using the Location response
                  header field.

                  2. The user-agent makes an HTTP GET request to the
                  provided location (which may be something other than
                  an HTTP URI, or an HTTP URI to localhost).

                  #1 is an HTTP response to a user-agent request to the
                  authorization endpoint (or a subsequent one if the
                  server implementation has multiple authorization
                  steps).

                  In order for the code to be secure end-to-end, both
                  steps must use TLS. The arguments made against making
                  TLS required are based on use cases for #2. We can
                  make #1 (the authorization endpoint require TLS since
                  it already has to support it for the 'token' response
                  type. We should make callbacks a SHOULD for TLS.

                  EHL

                  > >> Sorry for pushing hard on this one, but
                  TLS is the backbone of OAuth

                  email).

                  > >>>>>> This issue is theft of
                  the authorization code during the redirect.

                  -----Original Message-----

                  [mailto:oauth-

                  > >>>>>>>>> 1) I'd vote
                  for dropping the following from 1.4.2.   In turn I'd

                  > >>>>>>>>> the security
                  considerations, such as difficulty of protecting

                  > >>>>>>>>>  "Implicit
                  grants improve the responsiveness and efficiency of

                  > >>>>>>>>> some clients
                  (such as a client implemented as an in-browser

                  > >>>>>>>>> application)
                  since it reduces the number of round trips

                  > >>>>>>> It's accurate, but
                  my opinion is it sends the wrong message.   It's

                  > >>>>>> performant people may
                  find that attractive and make the wrong

                  > >>>>>>>>> 2) Section
                  2.1, we should MUST TLS even for Authorization Code.

                  > >>>>>>> See Phils comment on
                  past experience with artifact bindings.

                  > >>>>>>>>> 3) Section
                  4.1.3 - not clear to me why redirect_uri is

                  > >>>>>>>> The client
                  should always confirm where the code was sent to. It

                  > >>>>>>>>> 4) Section
                  4.2.2 - when did we drop refresh_token?     I assume

                  > >>>>>>>>> back to
                  disagreement on how best to handle native clients. I'd

                  > >>>>>>>>> prefer it to
                  simply reference 5.1 and leave what is issued up

                  > >>>>>>>>> to the
                  security profile of the particular deployment as to
                  what is

                  > >>>>>>>> This has been
                  decided for a long time. I'm not eager to change it.

                  > >>>>>>> Thanks - I can live
                  with it.  Unfortunately we still seem to be

                  OAuth mailing list

                  [email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 12:46:18 -0700

As a matter of practicality, requiring all clients to deploy server-side TLS is absurd. If we mandate redirections URIs to use https, we are basically making everyone ignore it. It’s like a speed limit sign of 5mph.

EHL

From: George Fletcher [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 10:55 AM
To: [email-masked]
Cc: Phil Hunt; Justin Richer; Eran Hammer-Lahav; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Hi Francisco,

Thanks,
George

Francisco

--- On Mon, 3/28/11, Eran Hammer-Lahav <[email-masked]><mailto:[email-masked]> wrote:

From: Eran Hammer-Lahav <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "Phil Hunt" <[email-masked]><mailto:[email-masked]>, "Justin Richer" <[email-masked]><mailto:[email-masked]>
Cc: "OAuth WG" <[email-masked]><mailto:[email-masked]>
Date: Monday, March 28, 2011, 10:28 PM
The code is returned in two steps:

EHL

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 12:50:48 -0700

Isn’t all this just different flavors of a session fixation attacks? The client should use cookies and the state parameter to ensure the same user-agent it redirected to the authorization server is the one coming back.

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 11:46 AM
To: Phil Hunt; Justin Richer; Eran Hammer-Lahav
Cc: OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked])
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 15:39:56 -0700 (PDT)

> Isn’t all this just different flavors of a session fixation attacks?
> The client should use cookies and the state parameter to ensure the
> same user-agent it redirected to the authorization server is the one
> coming back.

It's not a session fixation attack.  It's just an interception of a
credential.  The authorization code is a credential that provides
access to the protected resources.  If the attacker can get it, the
attacker can get the protected resources (using the client as an
agent, so to speak).

A cookie won't help, since it would be sent from the browser to the client
along with the authorization code.  If the attacker can observe or
intercept the authorization code, the attacker and observe or
intercept the cookie.

Francisco

--- On Tue, 3/29/11, Eran Hammer-Lahav <[email-masked]> wrote:

From: Eran Hammer-Lahav <[email-masked]>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "[email-masked]" <[email-masked]>, "Phil Hunt" <[email-masked]>, "Justin Richer" <[email-masked]>
Cc: "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>, "Paul Tarjan ([email-masked])" <[email-masked]>
Date: Tuesday, March 29, 2011, 7:50 PM

Isn’t all this just different flavors of a session fixation attacks? The client should use cookies and the state parameter to ensure the same user-agent it redirected to the authorization server is the one coming back.  EHL  From: Francisco Corella [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 11:46 AM
To: Phil Hunt; Justin Richer; Eran Hammer-Lahav
Cc: OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked])
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt  > Can you explain how intercepting the authorization code

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 15:49:41 -0700 (PDT)

> As a matter of practicality, requiring all clients to deploy
> server-side TLS is absurd. If we mandate redirections URIs to use
> https, we are basically making everyone ignore it. It’s like a speed
> limit sign of 5mph.

Why is that?  Can you elaborate?  I'm very puzzled.  And didn't you
propose requiring TLS a few messages back?

Francisco

From: Eran Hammer-Lahav <[email-masked]>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "George Fletcher" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Phil Hunt" <[email-masked]>, "Justin Richer" <[email-masked]>, "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Tuesday, March 29, 2011, 7:46 PM

As a matter of practicality, requiring all clients to deploy server-side TLS is absurd. If we mandate redirections URIs to use https, we are basically making everyone ignore it. It’s like a speed limit sign of 5mph.  EHL  From: George Fletcher [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 10:55 AM
To: [email-masked]
Cc: Phil Hunt; Justin Richer; Eran Hammer-Lahav; OAuth WG; Karen P. Lewison
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt  Hi Francisco,

Thanks,
George

On 3/29/11 1:05 PM, Francisco Corella wrote: Eran,

Francisco

Date: Monday, March 28, 2011, 10:28 PMThe code is returned in two steps:

EHL

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 16:29:19 -0700

Twitter and Facebook can’t require all their application developers to deploy TLS. Just not going to happen. How many clients today use TLS for their callbacks? I’m guessing less than half.

I am advocating TLS on the server side, because it is already required there for other endpoints. But on the client there is currently no such requirements. Making the callback a MUST use TLS is a huge change.

EHL

From: Francisco Corella [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 3:50 PM
To: George Fletcher; Eran Hammer-Lahav
Cc: Phil Hunt; Justin Richer; OAuth WG; Karen P. Lewison
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Francisco

--- On Tue, 3/29/11, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "George Fletcher" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Justin Richer" <[email-masked]<mailto:[email-masked]>>, "OAuth WG" <[email-masked]<mailto:[email-masked]>>, "Karen P. Lewison" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 29, 2011, 7:46 PM

EHL

Hi Francisco,

Thanks,
George

Eran,

Francisco

--- On Mon, 3/28/11, Eran Hammer-Lahav <[email-masked]></mc/compose?to=[email-masked]> wrote:

From: Eran Hammer-Lahav <[email-masked]></mc/compose?to=[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "Phil Hunt" <[email-masked]></mc/compose?to=[email-masked]>, "Justin Richer" <[email-masked]></mc/compose?to=[email-masked]>
Cc: "OAuth WG" <[email-masked]></mc/compose?to=[email-masked]>
Date: Monday, March 28, 2011, 10:28 PM

EHL

> From: Phil Hunt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> [email-masked]<mailto:[email-masked]>
>
>
>
>
> >> [email-masked]<mailto:[email-masked]>
> >>
> >>
> >>
> >>
> >>>> From: Justin Richer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> >>>>>> From: Phil Hunt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> >>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:oauth</mc/compose?to=oauth>-
> [email-masked]<mailto:[email-masked]>]

OAuth mailing list

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 30 Mar 2011 10:37:26 +1100

A http redirect_uri that doesn’t address localhost is a security risk.

Requiring https is a solution, but with a cost to client apps.

Using any http on the web is a security risk.

Some sites use https for their login page and http for the content. That is a security risk (eg firesheep).

Perhaps the question for OAuth2 is whether an http redirect_uri is like:

1. A site with http for everything (login page and session); or

2. A site with an https login page, but http for the rest of the session.

OAuth definitely shouldn’t allow #1, but perhaps forbidding #2 is too harsh today (or perhaps not given firesheep).

An http redirect_uri may be able to be treated like #2 as long as an attacker cannot use the access flowing from the authorization code beyond the attacker’s current session with the client app.

--

James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, 30 March 2011 6:46 AM
To: George Fletcher; [email-masked]
Cc: [email-masked]; Karen P. Lewison; WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 16:40:27 -0700

To clarify, I am not opposed to mandating TLS on the callback, just that if we do, we can’t ship the protocol the way it is without coming up with some other alternative that does not require TLS deployment on the client side. OAuth 1.0 has no such requirement and adding it in 2.0 is completely unexpected by the community at large.

It would be helpful to hear from some companies with large 1.0 or 2.0 deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter, etc.?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, March 29, 2011 4:29 PM
To: [email-masked]; George Fletcher
Cc: [email-masked]; Karen P. Lewison; WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

EHL

Francisco

EHL

Hi Francisco,

Thanks,
George

Eran,

Francisco

EHL

OAuth mailing list

---

From: Francisco Corella <[email-masked]>
Date: Tue, 29 Mar 2011 16:43:00 -0700 (PDT)

They don't use it because they don't know it's needed.  If they knew that not using it is as dangerous to their users as sending passwords in the clear they would use it.  And I doubt the IETF is going to endorse a protocol that sends credentials in the clear.

Francisco

From: Eran Hammer-Lahav <[email-masked]>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "[email-masked]" <[email-masked]>, "George Fletcher" <[email-masked]>
Cc: "Phil Hunt" <[email-masked]>, "Justin Richer" <[email-masked]>, "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Tuesday, March 29, 2011, 11:29 PM

Twitter and Facebook can’t require all their application developers to deploy TLS. Just not going to happen. How many clients today use TLS for their callbacks? I’m guessing less than half.  I am advocating TLS on the server side, because it is already required there for other endpoints. But on the client there is currently no such requirements. Making the callback a MUST use TLS is a huge change.  EHL  From: Francisco Corella [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 3:50 PM
To: George Fletcher; Eran Hammer-Lahav
Cc: Phil Hunt; Justin Richer; OAuth WG; Karen P. Lewison
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt  > As a matter of practicality, requiring all clients to deploy

Francisco

Date: Tuesday, March 29, 2011, 7:46 PMAs a matter of practicality, requiring all clients to deploy server-side TLS is absurd. If we mandate redirections URIs to use https, we are basically making everyone ignore it. It’s like a speed limit sign of 5mph. EHL From: George Fletcher [mailto:[email-masked]] 

Thanks,
George

Francisco

EHL

---

From: Dick Hardt <[email-masked]>
Date: Tue, 29 Mar 2011 21:02:22 -0700

> To clarify, I am not opposed to mandating TLS on the callback, just that if we do, we can’t ship the protocol the way it is without coming up with some other alternative that does not require TLS d…

I only recall the concern with TLS to be on the server side, not the client side -- and I don't think that it is unexpected at all.

> It would be helpful to hear from some companies with large 1.0 or 2.0 deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter, etc.?

When working on OAuth-WRAP, I talked to all of those companies about using TLS, and only Facebook said that they wanted an option to be able to not require TLS. Since then, all Facebook's new APIs which are essentially using OAuth 2.0 run on TLS.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 22:07:13 -0700

I think you got this backwards. We're talking about forcing developers using the Facebook (or any other service) API to deploy their own TLS endpoint for the incoming callback (via redirection). Every developer will need to get a cert and deploy an HTTPS endpoint.

That's has never been discussed.

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 9:02 PM
To: Eran Hammer-Lahav
Cc: WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

To clarify, I am not opposed to mandating TLS on the callback, just that if we do, we can't ship the protocol the way it is without coming up with some other alternative that does not require TLS deployment on the client side. OAuth 1.0 has no such requirement and adding it in 2.0 is completely unexpected by the community at large.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 22:48:47 -0700

Francisco – thanks for being persistent.

Sounds like the same problem exists in OAuth 1.0. Basically, the only way the client knows that the same user who granted authorization is the one coming back, is via the authorization code. Anyone who has that code is basically assumed to be the one granting access. If the code is intercepted, whoever gets it can pretend to be its legitimate holder.

I agree this is an issue.

Requiring callbacks to use TLS is a big change.

There are some cases where it is not needed – namely, when the client uses the access token obtained through this transaction to do something on the backend without actually exposing anything to the user who delivered the authorization code. For example, an application scanning your Twitter account in the background, sending you emails when someone is no longer following you. Such a client does not need TLS because the authorization code represents a valid grant, and the MITM doesn’t get any benefit from hijacking the callback. No data is exposed.

However, this is not the typical use case.

As long as the security considerations are clearly stated, we can move forward with either a MUST or a SHOULD. We can easily exempts any internal callbacks from this requirement (localhost, application scheme handler, etc.).
I don’t want to write a specification that everyone knowingly ignores. Once people ignore one security requirement, what’s to stop them from ignoring others. So the most important input to this discussion is what the vendors are going to do (regardless of what the document says)?

EHL

Sent: Tuesday, March 29, 2011 3:40 PM

Francisco

From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Justin Richer" <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG" <[email-masked]<mailto:[email-masked]>>, "Karen P. Lewison" <[email-masked]<mailto:[email-masked]>>, "Paul Tarjan ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 29, 2011, 7:50 PM

EHL

Francisco

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 29 Mar 2011 22:55:12 -0700

Why can't TLS be a must except when the token cannot be exposed. Eg because the redirect is local? 

Phil

Sent from my phone.

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 29 Mar 2011 23:18:59 -0700

+1

I disagree that to use TLS is a big change.  Rather I'd categorize using TLS as a big inconvenience.

We should define a secure profile.  If individual deployments choose to relax the spec and determine HTTP acceptable for local host or other convenience thats fine, but it shouldn't be compliant.

- cmort

On Mar 29, 2011, at 10:55 PM, "Phillip Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Sent from my phone.

On 2011-03-29, at 22:48, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

EHL

Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)

Francisco

--- On Tue, 3/29/11, Eran Hammer-Lahav <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

From: Eran Hammer-Lahav <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "Phil Hunt" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "Justin Richer" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "Karen P. Lewison" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "Paul Tarjan (<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 29, 2011, 7:50 PM

EHL

Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)

Francisco

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Mar 2011 23:34:57 -0700

I’ve been doing this longer. Requiring TLS on the redirection endpoint is a big change for OAuth deployments. This would have been unthinkable for OAuth 1.0(a). One of the main goals of 2.0 was to make it much easier for client developers. I don’t think deploying HTTPS as a prerequisite for playing with an OAuth endpoint is trivial for most client developers.

When we had the same debate over bearer token and TLS, many people argued to keep it SHOULD, but no one said they will actually deploy it without TLS. That was a very useful data point. We should take a moment to find out what existing OAuth providers have to say about this.

To clarify – I am not objecting to making this a MUST. But I am objecting and will delay this change until we gather more information from actual deployments. Since this applies to OAuth 1.0, it would be very relevant to ask existing providers if they will try and enforce such a restriction for 1.0 as well.

Specifications written in a bubble usually fail outright or fail to reflect reality.

Also, the attacks are different for the authorization code and implicit grant types. Each can benefit from using TLS for the redirection endpoint in different ways (one transmission of code from user-agent to client, the other manipulation of scripts from client to user-agent). Just want to make sure we don’t just focus on one vector.

EHL

From: Chuck Mortimore [mailto:[email-masked]]
Sent: Tuesday, March 29, 2011 11:19 PM
To: Phillip Hunt
Cc: Eran Hammer-Lahav; Karen P. Lewison; OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

+1

- cmort

Phil

Sent from my phone.

On 2011-03-29, at 22:48, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Francisco – thanks for being persistent.

EHL

Cc: OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked]<mailto:[email-masked]>)

Francisco

EHL

Cc: OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked]<mailto:[email-masked]>)

Francisco

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 30 Mar 2011 08:56:07 +0200

We are discussing TLS right now as a mean to prevent impersonation of 
the end-user's session on the client site. Correct? It's definitely a 
good advice to protect session from being highjacked that way. But I'm 
wondering whether this really belongs into the scope of OAuth?

BTW: It's covered in 
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.6.

regards,
Torsten.

Am 30.03.2011 08:34, schrieb Eran Hammer-Lahav:
>
> I’ve been doing this longer. Requiring TLS on the redirection endpoint 
> is a big change for OAuth deployments. This would have been 
> unthinkable for OAuth 1.0(a). One of the main goals of 2.0 was to make 
> it much easier for client developers. I don’t think deploying HTTPS as 
> a prerequisite for playing with an OAuth endpoint is trivial for most 
> client developers.
>
> When we had the same debate over bearer token and TLS, many people 
> argued to keep it SHOULD, but no one said they will actually deploy it 
> without TLS. That was a very useful data point. We should take a 
> moment to find out what existing OAuth providers have to say about this.
>
> To clarify – I am not objecting to making this a MUST. But I am 
> objecting and will delay this change until we gather more information 
> from actual deployments. Since this applies to OAuth 1.0, it would be 
> very relevant to ask existing providers if they will try and enforce 
> such a restriction for 1.0 as well.
>
> Also, the attacks are different for the authorization code and 
> implicit grant types. Each can benefit from using TLS for the 
> redirection endpoint in different ways (one transmission of code from 
> user-agent to client, the other manipulation of scripts from client to 
> user-agent). Just want to make sure we don’t just focus on one vector.
>
> EHL
>
> *From:*Chuck Mortimore [mailto:[email-masked]]
> *Sent:* Tuesday, March 29, 2011 11:19 PM
> *To:* Phillip Hunt
> *Cc:* Eran Hammer-Lahav; Karen P. Lewison; OAuth WG
> We should define a secure profile.  If individual deployments choose 
> to relax the spec and determine HTTP acceptable for local host or 
> other convenience thats fine, but it shouldn't be compliant.
>
>
> - cmort
>
>
>         Sounds like the same problem exists in OAuth 1.0. Basically,
>         the only way the client knows that the same user who granted
>         authorization is the one coming back, is via the authorization
>         code. Anyone who has that code is basically assumed to be the
>         one granting access. If the code is intercepted, whoever gets
>         it can pretend to be its legitimate holder.
>
>         There are some cases where it is not needed – namely, when the
>         client uses the access token obtained through this transaction
>         to do something on the backend without actually exposing
>         anything to the user who delivered the authorization code. For
>         example, an application scanning your Twitter account in the
>         background, sending you emails when someone is no longer
>         following you. Such a client does not need TLS because the
>         authorization code represents a valid grant, and the MITM
>         doesn’t get any benefit from hijacking the callback. No data
>         is exposed.
>
>         As long as the security considerations are clearly stated, we
>         can move forward with either a MUST or a SHOULD. We can easily
>         exempts any internal callbacks from this requirement
>         (localhost, application scheme handler, etc.).
>
>         I don’t want to write a specification that everyone knowingly
>         ignores. Once people ignore one security requirement, what’s
>         to stop them from ignoring others. So the most important input
>         to this discussion is what the vendors are going to do
>         (regardless of what the document says)?
>
>         EHL
>
>         *Sent:* Tuesday, March 29, 2011 3:40 PM
>         *Cc:* OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked]
>         <mailto:[email-masked]>)
>         *Subject:* RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>
>         --- On *Tue, 3/29/11, Eran Hammer-Lahav /<[email-masked]
>         To: "[email-masked] <mailto:[email-masked]>"
>         <[email-masked] <mailto:[email-masked]>>, "Phil
>         Hunt" <[email-masked] <mailto:[email-masked]>>,
>         Cc: "OAuth WG" <[email-masked] <mailto:[email-masked]>>,
>         "Karen P. Lewison" <[email-masked]
>         <mailto:[email-masked]>>, "Paul Tarjan ([email-masked]
>         <mailto:[email-masked]>)" <[email-masked] <mailto:[email-masked]>>
>         Isn’t all this just different flavors of a session fixation
>         attacks? The client should use cookies and the state parameter
>         to ensure the same user-agent it redirected to the
>         authorization server is the one coming back.
>
>         EHL
>
>         *Sent:* Tuesday, March 29, 2011 11:46 AM
>         *Cc:* OAuth WG; Karen P. Lewison; Paul Tarjan ([email-masked]
>         <mailto:[email-masked]>)
>         *Subject:* RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Wed, 30 Mar 2011 10:03:31 -0400

Isn't a "MUST with exceptions" basically the same weight as a "SHOULD"?
As per 2119:

   "SHOULD ... there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

I've always put pretty heavy weight on "SHOULD" components in a spec, as
it really comes down to "ignore at your own peril." A "MUST" shouldn't
have exceptions like that if it's really a "MUST."

 -- Justin

On Wed, 2011-03-30 at 01:55 -0400, Phillip Hunt wrote:
> > Sounds like the same problem exists in OAuth 1.0. Basically, the
> > only way the client knows that the same user who granted
> > authorization is the one coming back, is via the authorization code.
> > Anyone who has that code is basically assumed to be the one granting
> > access. If the code is intercepted, whoever gets it can pretend to
> > be its legitimate holder.
> > 
> >  
> > 
> > client uses the access token obtained through this transaction to do
> > something on the backend without actually exposing anything to the
> > user who delivered the authorization code. For example, an
> > application scanning your Twitter account in the background, sending
> > you emails when someone is no longer following you. Such a client
> > does not need TLS because the authorization code represents a valid
> > grant, and the MITM doesn’t get any benefit from hijacking the
> > callback. No data is exposed.
> > 
> >  
> > 
> > As long as the security considerations are clearly stated, we can
> > move forward with either a MUST or a SHOULD. We can easily exempts
> > any internal callbacks from this requirement (localhost, application
> > scheme handler, etc.).
> > 
> > ignores. Once people ignore one security requirement, what’s to stop
> > them from ignoring others. So the most important input to this
> > discussion is what the vendors are going to do (regardless of what
> > the document says)?
> > 
> >  
> > 
> > EHL
> > 
> >  
> > 
> >  
> > 
> > attacks?
> > To: "[email-masked]" <[email-masked]>, "Phil Hunt"
> > <[email-masked]>, "Justin Richer" <[email-masked]>
> > Cc: "OAuth WG" <[email-masked]>, "Karen P. Lewison"
> > <[email-masked]>, "Paul Tarjan ([email-masked])" <[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 30 Mar 2011 08:19:14 -0700

Thanks for pointing out my misunderstanding. I was thinking client in the sense of the side of TLS initiating a request.

I agree that requiring TLS on the callback is an unexpected change. 

I recall reviewing the security implications of an unsecured callback as being nominal if the authorization grant is linked to the client credentials.

On 2011-03-29, at 10:07 PM, Eran Hammer-Lahav wrote:

> I think you got this backwards. We’re talking about forcing developers using the Facebook (or any other service) API to deploy their own TLS endpoint for the incoming callback (via redirection). Every developer will need to get a cert and deploy an HTTPS endpoint.
>  
> That’s has never been discussed.
>  
> EHL
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Mar 2011 09:15:46 -0700

Developers of say a mobile app would not have to deploy it since the redirect endpoint would be local per the specific exception proposed. There should be NO requirement to make a client app implement TLS server side security. 

The concern here is that all "network" paths are secured to prevent impersonation or theft of the session. Remember that in many cases, once the code is granted, the subsequent token is often good for a LONG time and thus this becomes the weak point in this protocol.

Re: Justin's comments on SHOULD, I find SHOULD is just too broad, it does not define when it is acceptable not to have security.  I prefer clear specification text that says the network paths must be protected.

Re: Eran's comments about impact on the existing community.  I don't think you are grasping the broadness of acceptance of OAuth 2.0. The existing OAuth 1.0 users are primarily social networks. I haven't heard them object. In fact, I've noticed almost all have started enabling HTTPS everywhere (at least as a user option). But OAuth2 has a much broader community now that I would argue is VERY concerned about risks of impersonation and real financial loss.

Phil
[email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Wed, 30 Mar 2011 09:25:06 -0700

Phil

I'd suggest you review the spec so that you understand what Eran and I are saying. No code has been granted in the redirect to a web client, where implementing TLS server side is a major barrier. 

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 30 Mar 2011 10:00:54 -0700

MUST with listed exceptions is much stronger than a SHOULD with implicit exceptions. 

EHL

---

From: George Fletcher <[email-masked]>
Date: Wed, 30 Mar 2011 13:33:01 -0400

From a deployment perspective... I'm considering allowing HTTP 
redirect_uri (for development only) but making the UI very obnoxious 
(e.g. bright red background, warnings etc) such that no real user would 
click through, but a developer will ignore. It also forces them to 
switch to TLS for production. Thoughts?

Also, as long as the authorization code is one-time-use, the passive 
attack doesn't work. It has to be MITM. Is there any reason 
authorization codes shouldn't be short-lived and one-time-use?

Thanks,
George

---

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Mar 2011 11:08:44 -0700

I believe there are really two separate issues in this thread - hence the confusion. This is a fairly complex interchange since it involves re-directs, message confidentiality, and server authentication issues.

ONE: 

I believe the text Dick is referring to is:

"If the response includes an access token, the authorization server MUST require TLS 1.2 as defined in [RFC5246] and MAY support additional transport- layer mechanisms meeting its security requirements. If the response does not include an access token, the authorization server SHOULD require TLS 1.2 and any additional transport-layer mechanism meeting its security requirements."

I believe the contentious part is the second part "If the response does not include an access token...".  
1. Should we further clarify as "either within the redirect URL" or within a response document since some might argue that a redirect URL is not the response document when in this case it still carries information.
2. If no data is present, "state" is still available. How much of a concern do we have? Some are arguing that there is no need to secure this. 

In my opinion the MUST is required for reasons other than leakage. Note that we are talking about a RESPONSE message to a REQUEST that definitely should have been secure because in this case TLS authenticates the authorization server. Reverting to a SHOULD implies the original REQUEST need not be secure -- which means the client app has not authenticated the authorization service. If this is the case, then security depends solely on the integrity of the authorization code (artifact) not being spoofed since the whole authorization step is not secured from the perspective of the client. Given the variety of token systems out there, I would rather not depend on security of the authz code alone.

TWO:

There is a second issue that people are raising regarding the redirect that would force clients to implement TLS server side security. I'm not seeing where this is covered in the spec. The exception we are discussing is that if the redirect endpoint is local to the user-agent, then TLS is not required. However, if it is remote (such as an OAuth client that is a web service), then TLS is a MUST.  Maybe this point needs to be discussed in section 2.1.1?

Further, from section 2.2:
"Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the token endpoints. The authorization server MUST support TLS 1.2 as defined in [RFC5246], and MAY support additional transport-layer mechanisms meeting its security requirements"

This paragraph seems to indicate that the transmission of the authz code in 2.1 is unsecure.  I think the first phrase (Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response)) should be removed as it isn't quite in sync with even the current 2.1 endpoint behaviour.

Cheers,

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 30 Mar 2011 11:23:07 -0700

We have consensus to change issue one to a MUST. Basically, the authorization endpoint MUST always use TLS regardless of its output.

We are still debating mandating TLS for the redirection URI (registered or dynamic) for any non-localhost transmission. The issue is not limited to sending the authorization code, but also when receiving HTML/JS code used to extract the token from the fragment in the implicit grant case. The issue is not whether there is a security risk, but what language we should use to warn against it (i.e. make insecure a violation of the spec via a MUST, or clearly explain the risks via a SHOULD).

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 11:09 AM
To: Dick Hardt
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

ONE:

TWO:

Cheers,

Phil

Phil

-- Dick

Phil

EHL

---

From: Phil Hunt <[email-masked]>
Date: Wed, 30 Mar 2011 11:29:20 -0700

+1 for the first

The second is almost right, except some of us are suggesting a middle ground of using a 'MUST EXCEPT' for where the redirect is to a client local to the user-agent.

IMO, the phrasing below reflect positions that are too restrictive/too open.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 30 Mar 2011 15:18:51 -0700

After much reflection and review of the big picture (OAuth 1.0 deployment included), I have come to the conclusion that this is a valid security concern which should be explained in the security consideration section, but which does not merit a requirement to use TLS on the client side.

I am now opposed to specifying a MUST use TLS with the callback URI deployed by the client.

We should change section 2.1 as follows:

   Since requests to the authorization endpoint result in user authentication
   and the transmission of clear-text credentials (in the HTTP response), the
   authorization server MUST require the use of a transport-layer
   security mechanism when sending requests to the token endpoints.  The
   authorization server MUST support TLS 1.2 as defined in [RFC5246<http://tools.ietf.org/html/rfc5246>],
   and MAY support additional transport-layer mechanisms meeting its
   security requirements.

This is the only normative change we should make.

My reason for rejecting the requirement to use TLS on the client side is that it is a misleading and narrowly focused guideline. If the client deploys an HTTPS redirection URI endpoint, only to then set an insecure cookie for session management, the same attack is still possible. IOW, if the client allows *any* kind of insecure authentication, OAuth or not, this exploit can put protected resources at risk.

The only meaningful - but completely out of scope – requirement to make is that any client using OAuth MUST only support secure authentication of any kind using any protocol (OAuth, cookies, Basic). This translates into full HTTPS deployment for client applications, something that is a growing trend but far from industry standard.

So while this is a valid concern, forcing the client to deploy TLS for the OAuth endpoint is an over-reaction and insufficient at that.

EHL

From: George Fletcher [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 10:33 AM
To: Eran Hammer-Lahav
Cc: Chuck Mortimore; Phillip Hunt; Karen P. Lewison; OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

From a deployment perspective... I'm considering allowing HTTP redirect_uri (for development only) but making the UI very obnoxious (e.g. bright red background, warnings etc) such that no real user would click through, but a developer will ignore. It also forces them to switch to TLS for production. Thoughts?

Also, as long as the authorization code is one-time-use, the passive attack doesn't work. It has to be MITM. Is there any reason authorization codes shouldn't be short-lived and one-time-use?

Thanks,
George

EHL

+1

- cmort

Phil

Sent from my phone.

EHL

Francisco

EHL

Francisco

OAuth mailing list

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 31 Mar 2011 09:03:32 -0400

I would like to strongly disagree with this proposal.

It amounts to explicitly making OAuth 2.0 insecure so as to satisfy some 
mysterious and unspecified set of legacy OAuth 1.0 deployments.

The SAML web SSO (artifact) profile - which shares many characteristics 
with the initial steps in OAuth - requires precisely such a 
counter-measure and is widely implemented
in 1000s of deployments.

It is irrelevant that clients, authorization servers or resource servers 
might indulge in poor secuirty practices outside of OAuth 2.0.
It is specious and inappropriate to reference such behavior when 
discussing the security properties of OAuth; instead
our task is to ensure that the OAuth 2.0 does not include well-known 
security defects of precisely this type.

- prateek

> After much reflection and review of the big picture (OAuth 1.0 
> deployment included), I have come to the conclusion that this is a 
> valid security concern which should be explained in the security 
> consideration section, but which does not merit a requirement to use 
> TLS on the client side.
>
>  
>
> My reason for rejecting the requirement to use TLS on the client side 
> is that it is a misleading and narrowly focused guideline. If the 
> client deploys an HTTPS redirection URI endpoint, only to then set an 
> insecure cookie for session management, the same attack is still 
> possible. IOW, if the client allows **any** kind of insecure 
> authentication, OAuth or not, this exploit can put protected resources 
> at risk.
>
>  
>
> The only meaningful - but completely out of scope – requirement to 
> make is that any client using OAuth MUST only support secure 
> authentication of any kind using any protocol (OAuth, cookies, Basic). 
> This translates into full HTTPS deployment for client applications, 
> something that is a growing trend but far from industry standard.
>
>  
>
> So while this is a valid concern, forcing the client to deploy TLS for 
> the OAuth endpoint is an over-reaction and insufficient at that.
>
>  
>
> EHL
>
>  
>
>  
>
> *From:* George Fletcher [mailto:[email-masked]]
> *Sent:* Wednesday, March 30, 2011 10:33 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Chuck Mortimore; Phillip Hunt; Karen P. Lewison; OAuth WG
> (e.g. bright red background, warnings etc) such that no real user 
> would click through, but a developer will ignore. It also forces them 
> to switch to TLS for production. Thoughts?
>
> *From:* Chuck Mortimore [mailto:[email-masked]]
>         *From:* Francisco Corella [mailto:[email-masked]]
>         *From:* Francisco Corella [mailto:[email-masked]]
> ------------------------------------------------------------------------
>

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 31 Mar 2011 10:32:01 -0400

A requirement for TLS on the callback would make OAuth prohibitive for many of our developers. The developers are usually volunteers and they are already donating their own resources to help a non-profit (from which US law mandates the developers cannot profit). In other cases the developers are small firms operating in developing counties where establishing and maintaing a valid certificate may still be a imperfect art.

In short, a requirement like this puts the nail in the coffin of many would-be efforts to help out.

So as Dick identifies here, we have sufficient security around the authorization grant by tying it client credentials.  I would thus be opposed to the term "MUST."  I also think it's helpful to have the language limit the SHOULD to the non-user-agent cases. There's no reason we should suggest a callback URI designed for client-side intercept to use an HTTPS url - so this is in the spirit of Phil's response to Justin's comment on limiting the scope of SHOULD.

skylar

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 31 Mar 2011 09:42:24 -0700

It is important to distinguish between securing the resource server and securing the client. I think this is where this conversation has been somewhat broken.

If the client is user-agent based or web server based, it MUST user TLS 100% of the time when authenticating its users or delivering any scripts that may have access to any OAuth credentials (tokens, code, etc.). This goes far beyond just securing the redirection call.

For example, a JS client running in the browser will not leak the access token received from the authorization server using the implicit grant because it is delivered over TLS and is in the fragment which will not be send to the server containing the script. However, if that script is served without TLS, it can be manipulated by a MITM and changed to send the access token anywhere.

Same with server based clients using cookies for their own user authentication. If they don't use TLS exclusively, sessions can be hijacked and any protected resources they have access to are now potentially compromised.

IOW, if the client isn't perfect all around, securing the redirection URI does not increase its security. It's like putting an armed guard at one entrance to a building with 100 other wide-open doors. It is hypocritical and irresponsible to create the illusion of client security by focusing solely on the redirection URI.

IMO, a strong warning with a comprehensive explanation of the overall client security model will do much more good than putting horse blinds on and pretending that what the client does right after the callback is 'not OAuth' and something we should not care about.

A MUST use TLS focused narrowly on the redirection URI does not make the web better. At best, it make one door secure, but it also has the potential of creating a false sense of security which is typically where things go terribly wrong.

BTW, a profile of OAuth used primarily for login such as the proposed OpenID Connect, should make the callback use of TLS required. In that context, it is a logical extension of the server's use of TLS to provide a secure login experience.

EHL

> From: Skylar Woodward [mailto:[email-masked]]
> Sent: Thursday, March 31, 2011 7:32 AM
> To: Dick Hardt
> A requirement for TLS on the callback would make OAuth prohibitive for
> many of our developers. The developers are usually volunteers and they are
> already donating their own resources to help a non-profit (from which US law
> mandates the developers cannot profit). In other cases the developers are
> small firms operating in developing counties where establishing and
> maintaing a valid certificate may still be a imperfect art.
> 
> So as Dick identifies here, we have sufficient security around the
> authorization grant by tying it client credentials.  I would thus be opposed to
> the term "MUST."  I also think it's helpful to have the language limit the
> SHOULD to the non-user-agent cases. There's no reason we should suggest a
> callback URI designed for client-side intercept to use an HTTPS url - so this is
> in the spirit of Phil's response to Justin's comment on limiting the scope of
> SHOULD.
> 
> skylar
> 
> 
> 
> > Thanks for pointing out my misunderstanding. I was thinking client in the
> sense of the side of TLS initiating a request.
> >
> > I recall reviewing the security implications of an unsecured callback as being
> nominal if the authorization grant is linked to the client credentials.
> >
> >
> >> I think you got this backwards. We're talking about forcing developers
> using the Facebook (or any other service) API to deploy their own TLS
> endpoint for the incoming callback (via redirection). Every developer will
> need to get a cert and deploy an HTTPS endpoint.
> >>
> >> To clarify, I am not opposed to mandating TLS on the callback, just that if
> we do, we can't ship the protocol the way it is without coming up with some
> other alternative that does not require TLS deployment on the client side.
> OAuth 1.0 has no such requirement and adding it in 2.0 is completely
> unexpected by the community at large.
> >>
> >> I only recall the concern with TLS to be on the server side, not the client
> side -- and I don't think that it is unexpected at all.
> >>
> >>
> >>
> >> It would be helpful to hear from some companies with large 1.0 or 2.0
> deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter,
> etc.?
> >>
> >> When working on OAuth-WRAP, I talked to all of those companies about
> using TLS, and only Facebook said that they wanted an option to be able to
> not require TLS. Since then, all Facebook's new APIs which are essentially
> using OAuth 2.0 run on TLS.
> >>
> >>
> >>
> >

---

From: Phil Hunt <[email-masked]>
Date: Thu, 31 Mar 2011 10:30:03 -0700

+1

I agree this is not just about setting one TLS setting to mandatory. 

I believe we need language that is simple and clear.  Terms like SHOULD are loopholes that create risk as they are too broad. They also have served to make the security considerations incredibly long and complex since we had to explain all the risks exposed. In this respect, I think the overall specification needs to be tightened up considerably in order to get back to a simple specification.

Folks this is an AUTHORIZATION protocol! Our default position 'should' be that TLS is a MUST unless it can be demonstrated why there is absolutely no risk to turning it off.  For example, I agree that if a redirect end-point is local, it does not need to be on. There are relatively few exceptions.

In my opinion, most OAuth sites in production today do not do enough to protect authorization codes and are currently open to relatively simple hijacking attacks. The current OAuth usage in my opinion is not only a mark of success of OAuth but rather a demonstration that tightening requirements is critical to keeping OAuth successful.

As deployers of OAuth come on board supporting higher-risk data (e.g. financial, trading, etc) the tolerance for OAuth failures will be low.  We've got a good acceptance now, and I would not like to see it jeopardized by some deployers taking short-cuts because of lack of effort or lack of proper funds to support a secure deployment. If I were a charity, the last thing I would want is to risk the confidentiality of my donors.

If however, there is a strong community here that disagrees because they don't see any risk, then maybe there is a strong case to be made for a second RFC that defines a tighter set of requirements ("Secure OAuth"). In a sense, this is starting to happen now with regards to security considerations - they are just too long.  I would rather avoid this if we can.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 31 Mar 2011 10:43:31 -0700

Seems like your +1 is for a different conclusion :-)

My point is that specifications should reflect reality, not unattained aspirations. That leads to devaluation of the specification and dismissal of other - more important - security requirements. If the majority of members will confirm that they will not allow clients to register or provide a non HTTPS callback (excluding localhost), I will be much more inclined to support a MUST here. But without that, I don't want to write text knowing it will be ignored by many deployments.

Also, what should be the policy regarding non http/https schemes? What if the callback is using a local application handler which triggers sending the code over an insecure channel? This is another example where an explanation is much more valuable than a normative MUST.

EHL

> Sent: Thursday, March 31, 2011 10:30 AM
> To: Eran Hammer-Lahav
> Cc: Skylar Woodward; Dick Hardt; OAuth WG
> I believe we need language that is simple and clear.  Terms like SHOULD are
> loopholes that create risk as they are too broad. They also have served to
> make the security considerations incredibly long and complex since we had
> to explain all the risks exposed. In this respect, I think the overall
> specification needs to be tightened up considerably in order to get back to a
> simple specification.
> 
> Folks this is an AUTHORIZATION protocol! Our default position 'should' be
> that TLS is a MUST unless it can be demonstrated why there is absolutely no
> risk to turning it off.  For example, I agree that if a redirect end-point is local,
> it does not need to be on. There are relatively few exceptions.
> 
> In my opinion, most OAuth sites in production today do not do enough to
> protect authorization codes and are currently open to relatively simple
> hijacking attacks. The current OAuth usage in my opinion is not only a mark of
> success of OAuth but rather a demonstration that tightening requirements is
> critical to keeping OAuth successful.
> 
> As deployers of OAuth come on board supporting higher-risk data (e.g.
> financial, trading, etc) the tolerance for OAuth failures will be low.  We've got
> a good acceptance now, and I would not like to see it jeopardized by some
> deployers taking short-cuts because of lack of effort or lack of proper funds
> to support a secure deployment. If I were a charity, the last thing I would
> want is to risk the confidentiality of my donors.
> 
> If however, there is a strong community here that disagrees because they
> don't see any risk, then maybe there is a strong case to be made for a second
> RFC that defines a tighter set of requirements ("Secure OAuth"). In a sense,
> this is starting to happen now with regards to security considerations - they
> are just too long.  I would rather avoid this if we can.
> 
> Phil
> [email-masked]
> 
> 
> 
> 
> > It is important to distinguish between securing the resource server and
> securing the client. I think this is where this conversation has been somewhat
> broken.
> >
> > If the client is user-agent based or web server based, it MUST user TLS
> 100% of the time when authenticating its users or delivering any scripts that
> may have access to any OAuth credentials (tokens, code, etc.). This goes far
> beyond just securing the redirection call.
> >
> > For example, a JS client running in the browser will not leak the access
> token received from the authorization server using the implicit grant because
> it is delivered over TLS and is in the fragment which will not be send to the
> server containing the script. However, if that script is served without TLS, it
> can be manipulated by a MITM and changed to send the access token
> anywhere.
> >
> > Same with server based clients using cookies for their own user
> authentication. If they don't use TLS exclusively, sessions can be hijacked and
> any protected resources they have access to are now potentially
> compromised.
> >
> > IOW, if the client isn't perfect all around, securing the redirection URI does
> not increase its security. It's like putting an armed guard at one entrance to a
> building with 100 other wide-open doors. It is hypocritical and irresponsible
> to create the illusion of client security by focusing solely on the redirection
> URI.
> >
> > IMO, a strong warning with a comprehensive explanation of the overall
> client security model will do much more good than putting horse blinds on
> and pretending that what the client does right after the callback is 'not
> OAuth' and something we should not care about.
> >
> > A MUST use TLS focused narrowly on the redirection URI does not make
> the web better. At best, it make one door secure, but it also has the
> potential of creating a false sense of security which is typically where things
> go terribly wrong.
> >
> > BTW, a profile of OAuth used primarily for login such as the proposed
> OpenID Connect, should make the callback use of TLS required. In that
> context, it is a logical extension of the server's use of TLS to provide a secure
> login experience.
> >
> > EHL
> >
> >> A requirement for TLS on the callback would make OAuth prohibitive
> >> for many of our developers. The developers are usually volunteers and
> >> they are already donating their own resources to help a non-profit
> >> (from which US law mandates the developers cannot profit). In other
> >> cases the developers are small firms operating in developing counties
> >> where establishing and maintaing a valid certificate may still be a
> imperfect art.
> >>
> >> authorization grant by tying it client credentials.  I would thus be
> >> opposed to the term "MUST."  I also think it's helpful to have the
> >> language limit the SHOULD to the non-user-agent cases. There's no
> >> reason we should suggest a callback URI designed for client-side
> >> intercept to use an HTTPS url - so this is in the spirit of Phil's
> >> response to Justin's comment on limiting the scope of SHOULD.
> >>
> >> skylar
> >>
> >>
> >>
> >> endpoint for the incoming callback (via redirection). Every developer
> >> will need to get a cert and deploy an HTTPS endpoint.
> >>>>
> >> we do, we can't ship the protocol the way it is without coming up
> >> with some other alternative that does not require TLS deployment on the
> client side.
> >> deployment on this matter? Anyone from Google, Facebook, Yahoo,
> >> Twitter, etc.?
> >>>>
> >> using TLS, and only Facebook said that they wanted an option to be
> >> able to not require TLS. Since then, all Facebook's new APIs which
> >> are essentially using OAuth 2.0 run on TLS.
> >>>>
> >>>>
> >>>>
> >>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 31 Mar 2011 11:10:25 -0700

Unfortunately these aren't just "aspirations". We're talking about what are the *necessary* minimums.

Yes, I have been focusing on a couple of very specific aspects of authorization and I agree, the whole spec is important. But I disagree that that would be justification not to fix authorization as you suggest.  After all if the first step, authorization, is insecure or hijackable, the rest of the specification is kind of pointless isn't it?

Having contributed to the security considerations, I have grown concerned that the lassie faire approach is actually making the spec more complex. Because of all the options, the security considerations have had to explain all of the issues (and there are many) and what the remediations are. Further with so many specific deployment options, inter-operability seems to be a big question. With so many specifics, what would an inter-operable specification be? My conclusion? The OAuth 2 spec is bogged down by too much choice resulting to too much practical complexity. 

==> Conclusion: Current implementors will find it challenging to ensure their deployment is secure. <==  I can't make this point strongly enough!

I think we are in agreement on most things (hence my +1). But I think we are simply at a stage where refinement is key to success. A good specification should focus on what are the key options keeping choice to a minimum. We just aren't there yet - and we may need some substantive changes to fix this (I hope not).

Phil
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 Mar 2011 18:18:20 +0000

I have removed the extension of the OAuth Parameters registry in draft-ietf-oauth-v2-bearer-04, per your feedback Peter.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Saturday, March 26, 2011 6:56 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

>> Are those the only allowable locations? I notice that the bearer 
>> token spec adds a locations of "resource request" and "resource 
>> response". I'm not quite saying we need a registry of locations, but 
>> it might be good to have a well-defined way of adding to the list of 
>> allowable locations (otherwise a document like the bearer spec might 
>> need to say that it updates the base spec).
> 

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 31 Mar 2011 14:50:41 -0400

I think I understand both of your points. Phil is saying that the client must run over HTTPS to be secure so not being able to take an HTTP endpoint is a non-starter anyway.  Eran is saying security is a holistic evaluation, and since all secure clients would be HTTPS anyway (as Phil also asserts) why bother concerning the spec with this.

I'd have to agree with Eran on this especially as I think Phil's argument assumes popular use cases but not all possible applications. So, imagine a website secured inside a corporate firewall. This service needs to access the provider's services via OAuth and thus exposes one callback open to the world for purposes of the OAuth handshake. The redirect URI is HTTP since the corporation is having trouble acquiring or setting up a certificate for HTTPS - in any case, the provider does not requrire it. In this case, the auth code flows into the firewall via HTTP, but is further validated by client credentials over TLS in access token requests. Valid tokens return to the web application inside the corporate firewall over TLS and the information is still secure from outside threats. So, my point is that the use of client credentials (always kept secret and inside the firewall) secures the auth code exchange and use of HTTP doesn't create a vulnerability.  It is actually more critical that the user-interface portion of the app (not the callback URI, on whichever server it may reside) be secured than the actual callback URI itself.

However, all points are taken that developers should be encourage to develop secure apps and that in most cases, that means deploying common-case consumer web apps over HTTPS.  I don't think we'll be using our API to force this shift in the web, however. Given that some companies represented in the working group still have developer web sites that transmit all secrets and application data over HTTP, we have to assume the developers habits will trail the examples of the industry.  Instead, we'll use developer education to help them make secure products and thus earn the trust of our users.  But enforcing a best-practice via the API won't ensure secure apps. Only careful auditing and approval of the clients will help increase security of our app ecosystem.  Currently we don't have the bandwidth to do this. We can only promise to shut down or disable misleading or careless apps as we find them.

To access certain kinds of data we may have increased expectations around app security or encryption. (Not all of our data is financial, much of it is more social-private like Facebook or Twitter.)  For the more sensitive apps we would review the apps more closely and regularly to see they preform to our stated Terms of Service, expectations, or partner contract. Still, we can't ensure that level of compliance just by requiring TLS at one leg of the Auth handshake.

I understand the desire to establish a minimum level of tenacity in fighting for overall protocol strength. I just feel that if you require TLS on the callback URI for web apps you'll have a fair number of violations due to the state of the art today and will exclude alternative use cases like the one I described. Furthermore the requirement of TLS here isn't required to ensure security, so much as the need for TLS on web app server itself (which may be different from that of the callback).  (Apps without client credentials, if allowed, would also need TLS).

skylar

---

From: Francisco Corella <[email-masked]>
Date: Thu, 31 Mar 2011 11:59:08 -0700 (PDT)

Hi Torsten,

> We are discussing TLS right now as a mean to prevent
> impersonation of the end-user's session on the client
> site. Correct? It's definitely a good advice to protect
> session from being highjacked that way. But I'm wondering
> whether this really belongs into the scope of OAuth?
> 
> BTW: It's covered in http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.6.

I'm not sure you undertand the attack.  In the section
4.4.1.6 that you reference you propose the following
countermeasure:

>    o  The authorization server shall require the client to authenticate
>       with a secret, so the binding of the authorization code to a
>       certain client can be validated in a reliable way (see
>       Section 5.2.4.4).

This is not a countermeasure.  CLIENT AUTHENTICATION DOES
NOTHING TO MITIGATE THE ATTACK.

You should read again the attack descriptions I described in
the discussion we had back in early January:
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html
http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html
and those I sent recently:
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html
and the attack scneraio that George Fletcher described:
http://www.ietf.org/mail-archive/web/oauth/current/msg05825.html

The security considerations section that you have just proposed
fails to explain the issue.

Regarding those security considerations, I also wanted to
point out that the section on session fixation does not make
sense.  What session fixation attack are you talking about?
There was a session fixation vulnerability in the original
version of OAuth 1.0, but it was due to the fact that the
client obtained the temporary credentials (token request and
secret, analogous to the current authorization code) in a
direct request to the server before redirecting the user's
browser to the server for user authentication.  The server
created a session when it provided the temporary credentials
to the client, and the attacker fixated that session by
using a fake client to redirect the user to the server with
the request token issued to the attacker, which referred the
server to the attacker's session.  IN OAUTH 2.0 THIS
SESSSION FIXATION VULNERABILITY IS NOT AN ISSUE BECAUSE THE
DIRECT REQUEST TO OBTAIN TEMPORARY CREDENTIALS HAS BEEN
ELIMINATED.

Francisco

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 31 Mar 2011 22:05:24 +0200

Hi Francisco,

> I'm not sure you undertand the attack.  In the section

Then you should probably precisely describe the attack you want to talk 
about. I refered to MITM.

> NOTHING TO MITIGATE THE ATTACK.

I'm not sure you read the description carefully enough. It also states 
that the redirect_uri shall be authenticated:

"The browser shall be utilized to authenticate the redirect_uri of
       the client using server authentication"

--> MITM

Moreover, 
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.2 
requires

"Authorization server as well as the client MUST ensure that these
       transmissions are protected using transport-layer mechanisms such
       as TLS or SSL (see Section 5.1.1)."

--> Wiretapping

> fails to explain the issue.

Any proposal of better text is welcome.

> DIRECT REQUEST TO OBTAIN TEMPORARY CREDENTIALS HAS BEEN

I would suggest you calm down a bit and describe what is wrong with the 
description.

regards,
Torsten.

---

From: Francisco Corella <[email-masked]>
Date: Thu, 31 Mar 2011 13:06:56 -0700 (PDT)

Skylar,

> So, imagine a website secured inside a corporate
> firewall. This service needs to access the provider's
> services via OAuth and thus exposes one callback open to the
> world for purposes of the OAuth handshake. The redirect URI
> is HTTP since the corporation is having trouble acquiring or
> setting up a certificate for HTTPS - in any case, the
> provider does not requrire it. In this case, the auth code
> flows into the firewall via HTTP, but is further validated
> by client credentials over TLS in access token
> requests. Valid tokens return to the web application inside
> the corporate firewall over TLS and the information is still
> secure from outside threats. So, my point is that the use of
> client credentials (always kept secret and inside the
> firewall) secures the auth code exchange and use of HTTP
> doesn't create a vulnerability.

That is simply not true.  CLIENT CREDENTIALS DON'T HELP.  If
the user is outside the firewall and the callback URI is not
protected by TLS, the attacker intercepts the authorization
code outside the firewall and submits it to the client
through the firewall.  The client exchanges it for the
access token, uses the access token to get protected
resources, and sends those resources to the attacker
outside the firewall.

Francisco

---

From: Phil Hunt <[email-masked]>
Date: Thu, 31 Mar 2011 13:40:14 -0700

I have to agree. In OAuth, client credentials are dramatically weakened by the number of clients sharing the same credential.

If the hacker has the same client with the same credentials (such as the case with mobile client apps), then use of client credentials when exchanging for an access token has minimal security value if any.  However, if only one client can have the client credential, then it does add security value and Skylar's scenario may be valid. 

IMO using client credentials alone is insufficient to validate a particular client instances right to use an authorization code that could be leaked.

I have been pushing the TLS thing for several days on the list, and I agree there is strong push-back.  Let's explore some other alternatives.

What if we had some other means of positively linking specific requesting clients to a returned authorization token that does not rely solely on the client credential (since they are shared by multiple instances).  This would help prevent an eavesdropper from hijacking an authorization. Would this be a better way to simplify?

Phil
[email-masked]

---

From: Francisco Corella <[email-masked]>
Date: Thu, 31 Mar 2011 13:56:57 -0700 (PDT)

Hi Torsten,

> I'm not sure you read the description carefully enough. It also states that the redirect_uri shall be authenticated:
> 
> Moreover, http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.2 requires
> 

I'm very glad you want to require TLS for the callback
endpoint.  But many people in this mailing list believe that
client credentials mitigate the attack.  That belief is
mistaken, and it's causing a lot of confusion.  Your second
countermeasure in section 4.4.1.6,

> > >       certain client can be validated in a reliable way (see

indicates that you believe that too.  I'm trying to dispel that
misconception.

> Any proposal of better text is welcome.

Here is some text: "If the redirect URI is not protected by
TLS and is not local to the host where the user's browser is
running, an attacker who intercepts the authorization code
as it is sent by the browser to the callback endpoint can
gain access to protected resources by submitting the
authorization code to the client.  The client will exchange
the authorization code for an access token and use the
access token to access protected resources for the benefit
of the attacker, delivering protected resources to the
attacker, or modifying protected resources as directed by
the attacker.  If OAuth is used by the client to delegate
authentication to a social site (e.g. as in the
implementation of the "Facebook Login" button), the attacker
can use the intercapted authorization code to log in to the
client as the user."

> I would suggest you calm down a bit and describe what is
> wrong with the description.

What's wrong with the session fixation section is that it
addresses a problem that does not exist, unless there is a
session fixation attack that I'm not aware of.  If there is
such an attack, it should be described.  Telling
implementors "do this" or "don't do that" without
explanation is not helpful.

Regards,

Francisco

---

From: Dick Hardt <[email-masked]>
Date: Thu, 31 Mar 2011 14:00:31 -0700

> So as Dick identifies here, we have sufficient security around the authorization grant by tying it client credentials.  I would thus be opposed to the term "MUST."  I also think it's helpful to hav…

Unfortunately I was mistaken. The attack that Francisco is discussing and George summarized is NOT dealt with by the client credentials.

Summary: If authorized by Alice, client.com can expose information to the Attacker about Alice that is stored at resource.com.

If the Attacker can intercept the authorization code (and likely any session management between Alice and content.com), client.com does not realize that it is being presented by the Attacker since it is common that the only identity that client.com has about the user is from resource.com, there is no way for resource.com to know they are not acting on behalf of Alice, even though the session is with the Attacker. 

The Attacker now has access to Alice's resources at resource.com via client.com

The attack is enabled because there is no means for client.com to authenticate the user, and is often using resource.com to authenticate.

-- Dick

---

From: Francisco Corella <[email-masked]>
Date: Thu, 31 Mar 2011 14:16:33 -0700 (PDT)

Skylar's scenario is not valid even if only one client has the client credential, for the reason explained in my reply to Skylar, below.

 Francisco

--- On Thu, 3/31/11, Phil Hunt <[email-masked]> wrote:

From: Phil Hunt <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: [email-masked]
Cc: "Skylar Woodward" <[email-masked]>, "OAuth WG" <[email-masked]>, "Karen P. Lewison" <[email-masked]>
Date: Thursday, March 31, 2011, 8:40 PM

[email-masked]

> firewall)
 secures the auth code exchange and use of HTTP

Francisco

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 1 Apr 2011 01:03:04 -0400

Francisco, correct me if I'm wrong, but in your discussion you assume that the application is incapable of keeping secrets from the public (eg, mobile, desktop apps, etc.).  According to the spec, those applications should never receive client credentials to begin with.  They can't keep secrets so they aren't issued any. Obfuscating secrets in binary code doesn't count - if the tokens in question are outside a secured firewall, they aren't secrets.

George's attack is a MITM attack which can be expensive or difficult to pull off, but a possibility. At the least, it's a security consideration of why a callback *should* use TLS.

Someone speak up if George's scenario is flawed or I'm misunderstanding it.  My understanding is this:

- Bob uses (web) client C to access provider P.
- Mallory has set up a MITM attack between client C and Bob's computer.
- Mallory also uses client to C and starts an an approval process from the client to provider P
- Bob sends a request over HTTPS to provider P with client ID for C.
- Provider P responds to his request with a redirect to an authentication code.
- Meanwhile, Mallory does not continue with the auth flow at provider P. Instead, he waits for Bob.
- Bob's browser performs the redirect sent from provider P back to client C (over HTTP).
- Mallory intercepts the clear-text request from Bob's computer and does not pass the request on to client C.
- Mallory uses the auth code from Bob (and any state information) to forge a redirect request to client C on his own session.
- Client C requests an access token from provider P for Bob's account using it's secured client credentials.
- Mallory now has credentials for Bob on client C.  Bob has a dead or invalid auth handshake which was interrupted by Mallory (and not passed on to P to avoid replay detection).

(NOTE: I wrote this before the other examples, so apologies if it repeats the example Dick made).

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 1 Apr 2011 01:19:13 -0400

Right, but just so we are clear, the only case you are discussing here is the MITM attack, which George, I and others have recently outlined.

I'm not outright opposed to the language requiring TLS for the redirect URI, but the consequence is that some providers may need to find workarounds or (breaking?) exceptions to this rule. In reality the OAuth process will be much more paranoid than most provider websites serving the same information, but for the purposes of the spec, it's not necessarily a bad thing. It just means some people might need to bend the rules to serve there customers until all of the web gets to a higher level TSL competency and dependence on signature authorities.

So, if MITM is the only attack then for this case, we're sure that all other aspects of the exchange are similarly protected from MITM as well?

I think for some providers, the risk of MITM in this case will be so low as to not trump the value of the data protected (or the availability of that data through other or more cost-effective means). Still it doesn't mean the OAuth spec has to settle for less - we had the same argument around Bearer tokens. In the worst case, clients unable to set up HTTPS endpoints could be forced to require OOB flows (where the auth code must be manually transferred by the user from the provider into the client app) if they still wanted a fully spec-complient deployment.

skylar