Re: [OAUTH-WG] Auth Code Swap Attack

[Phil Hunt]

I felt the argument provided was persuasive and that the current spec leaves 
implementers open to attack. I get concerned when the core spec says "OPTIONAL" 
for state and then Security Considerations says REQUIRED. The inconsistency 
seemed to be a flaw in draft 20.

As to your comment about a tie vote, all that shows is a lack of consensus. 
Clearly we need to keep working on some more proposals.

I think it is reasonable to determine whether MUST is appropriate in all cases. 
I agree with what you said earlier, we should have more specific language other 
then "of sufficient complexity" to describe the value of the state parameter. 

I saw a proposal by William Mills that I would like to see more discussion on.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote:

> I would like to hear from the other 3 authors of the proposed change about 
> their reasons for changing the use of ‘state’ from recommended to required 
> for CSRF prevention. It would also help moving this issue forward if the 4 
> authors can provide answers or clarifications on the issues raised below.
>  
> Assuming we can count all 4 authors are in favor of making the change, I 
> believe we have a tie (4:4) and therefore no consensus for making it (as of 
> this point). However, we did identify issues with the section’s language and 
> clarity which we should address either way.
>  
> To clarify – I am not proposing we close this issue just yet.
>  
> EHL
>  
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Eran Hammer-Lahav
> Sent: Monday, August 15, 2011 9:35 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Auth Code Swap Attack
>  
> To demonstrate why making state required as proposed isn’t very helpful, here 
> is an incomplete list of other requirements needed to make an effective CSRF:
>  
> * State value must not be empty (a common bug in many implementations using 
> simple value comparison).
>  
> * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash 
> of the session cookie, with or without salt which isn’t sufficient. We use 
> “cannot be generated, modified, or guessed to produce valid values” elsewhere 
> in the document, but this is much easier to get right for access tokens and 
> refresh tokens than CSRF tokens which are often just some algorithm on top of 
> the session cookie.
>  
> * State CSRF value should be short-lived or based on a short-lived session 
> cookie to prevent the use of a leaked state value in multiple attacks on the 
> same user session once the leak is no longer viable.
>  
> In addition, this is not what “state” was originally intended for. If the 
> working group decides to mandate a CSRF parameter, it should probably be a 
> new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients 
> to use “state” for this purpose, developers will need to use dynamic queries 
> for other state information which further reduces the security of the 
> protocol (as the draft recommends not using dynamic callback query 
> components). Encoding both CSRF tokens and other state information can be 
> non-intuitive or complicated for some developers/platforms.
>  
> EHL
>  
>  
>  
>  
> From: Eran Hammer-Lahav 
> Sent: Friday, August 12, 2011 2:53 PM
> To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Auth Code Swap Attack
>  
> This is really just a flavor of CSRF attacks. I have no objections to better 
> documenting it (though I feel the current text is already sufficient), but we 
> can't realistically expect to identify and close every possible browser-based 
> attack. A new one is invented every other week.
>  
> The problem with this text is that developers who do no understand CSRF 
> attacks are not likely to implement it correctly with this information. Those 
> who understand it do not need the extra verbiage which is more confusing than 
> helpful.
>  
> As for the new requirements, they are insufficient to actually accomplish 
> what the authors propose without additional requirements on state local 
> storage and verification to complete the flow. Also, the proposed text needs 
> clarifications as noted below.
>  
>  
> From: Anthony Nadalin 
> Date: Fri, 12 Aug 2011 12:06:36 -0700
> To: "OAuth WG (oauth@ietf.org)" 
> Subject: [OAUTH-WG] Auth Code Swap Attack
>  
>  
>  
> Recommended Changes to draft-ietf-oauth-v2
>  
> In section 4, request options (e.g. 4.1.1) featuring "state" should change 
> from:
>  
> state
> OPTIONAL. An opaque value used by the client to maintain state between the 
> request and callback. The authorization server includes this value when 
> redirecting the user-agent back to the client.
>  
> to:
>  
> state
> REQUIRED. An opaque value used by the client to maintain state between the 
> request and callback. The authorization server includes this value when 
> redirecting the user-agent back to the c

Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)

[Eran Hammer-Lahav]

I think using phishing here is misleading. This is not a classic phishing 
attack. I'm open to other suggestions.

EHL

From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)

Text sounds very good.

wrt title: this threat is about phishing another user's authorization code. 
Because of the design of the protocol this requires the attacker to use another 
redirect URI than used by the legitimate client. To make this the title sound 
bit weird to me. Why not "authorization code phishing"?

regards,
Torsten.

Von: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 17. August 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)


> 10.6. Authorization Code Leakage: Comment "I fancy myself as being

> reasonably intelligent and I'm unclear what attack is actually being described

> here."



Yeah... I had to go back to -16 to be reminded of the section original title 
'session fixation attack' to figure out what this was about.



How about this:



10.6.  Authorization Code Redirection URI Manipulation



   When requesting authorization using the authorization code grant

   type, the client can specify a redirection URI via the "redirect_uri"

   parameter.  If an attacker can manipulate the value of the

   redirection URI, it can cause the authorization server to redirect

   the resource owner user-agent to a URI under the control of the

   attacker with the authorization code.



   An attacker can create an account at a legitimate client and initiate

   the authorization flow.  When the attacker is sent to the

   authorization server to grant access, the attacker grabs the

   authorization URI provided by the legitimate client, and replaces the

   client's redirection URI with a URI under the control of the

   attacker.  The attacker then tricks the victim into following the

   manipulated link to authorize access to the legitimate client.



   Once at the authorization server, the victim is prompted with a

   normal, valid request on behalf of a legitimate and familiar client,

   and authorizes the request.  The victim is then redirected to an

   endpoint under the control of the attacker with the authorization

   code.  The attacker completes the authorization flow by sending

   the authorization code to the client using the original redirection

   URI provided by the client.  The client exchanges the authorization

   code with an access token and links it to the attacker's client

  account which can now gain access to the protected resources

   authorized by the victim (via the client).



   In order to prevent such an attack, the authorization server MUST

   ensure that the redirection URI used to obtain the authorization

   code, is the same as the redirection URI provided when exchanging the

   authorization code for an access token.  The authorization server

   SHOULD require the client to register their redirection URI and if

   provided, MUST validate the redirection URI received in the

   authorization request against the registered value.



EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Eran Hammer-Lahav]

I would like to hear from the other 3 authors of the proposed change about 
their reasons for changing the use of 'state' from recommended to required for 
CSRF prevention. It would also help moving this issue forward if the 4 authors 
can provide answers or clarifications on the issues raised below.

Assuming we can count all 4 authors are in favor of making the change, I 
believe we have a tie (4:4) and therefore no consensus for making it (as of 
this point). However, we did identify issues with the section's language and 
clarity which we should address either way.

To clarify - I am not proposing we close this issue just yet.

EHL

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

To demonstrate why making state required as proposed isn't very helpful, here 
is an incomplete list of other requirements needed to make an effective CSRF:

* State value must not be empty (a common bug in many implementations using 
simple value comparison).

* 'Non-guessable' isn't sufficient as most developers will simply use a hash of 
the session cookie, with or without salt which isn't sufficient. We use "cannot 
be generated, modified, or guessed to produce valid values" elsewhere in the 
document, but this is much easier to get right for access tokens and refresh 
tokens than CSRF tokens which are often just some algorithm on top of the 
session cookie.

* State CSRF value should be short-lived or based on a short-lived session 
cookie to prevent the use of a leaked state value in multiple attacks on the 
same user session once the leak is no longer viable.

In addition, this is not what "state" was originally intended for. If the 
working group decides to mandate a CSRF parameter, it should probably be a new 
parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use 
"state" for this purpose, developers will need to use dynamic queries for other 
state information which further reduces the security of the protocol (as the 
draft recommends not using dynamic callback query components). Encoding both 
CSRF tokens and other state information can be non-intuitive or complicated for 
some developers/platforms.

EHL




From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

This is really just a flavor of CSRF attacks. I have no objections to better 
documenting it (though I feel the current text is already sufficient), but we 
can't realistically expect to identify and close every possible browser-based 
attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks 
are not likely to implement it correctly with this information. Those who 
understand it do not need the extra verbiage which is more confusing than 
helpful.

As for the new requirements, they are insufficient to actually accomplish what 
the authors propose without additional requirements on state local storage and 
verification to complete the flow. Also, the proposed text needs clarifications 
as noted below.


From: Anthony Nadalin mailto:tony...@microsoft.com>>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" 
mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Auth Code Swap Attack



Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

state
OPTIONAL. An opaque value used by the client to maintain state between the 
request and callback. The authorization server includes this value when 
redirecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the 
request and callback. The authorization server includes this value when 
redirecting the user-agent back to the client. The encoded value SHOULD enable 
the client application to determine the user-context that was active at the 
time of the  request (see section 10.12). The value MUST NOT be guessable or 
predictable, and MUST be kept confidential.


Making the parameter required without making its usage required (I.e. "value 
SHOULD enable") accomplishes nothing. Also, what does "MUST be kept 
confidential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests 
are transmitted from the user-agent of an end-user the server trusts or has 
authenticated. CSRF attacks enable the attacker to intermix the attacker's 
security context with that of the resource owner resulting in a compromise of 
either the resource server or of the client application itself. In the OAuth 
context, such attacks allow an attacker to inject their ow

Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

I've read the thread leading to this, and the proposed text and I do not 
understand the attack. Can you provide a step-by-step scenario of how an 
attacker gains access?

Also, it is unlikely that any major provider is going to require CAPCHA as part 
of the authorization flow. This is especially true in the case of using OAuth 
for login which has to be practically transparent (one click). I would hate to 
recommend a solution that no one is going to take seriously.

I'm keeping this proposed text out until we resolve this questions.

EHL


> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, August 12, 2011 7:56 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> Hi all,
> 
> I think the impersonation issue as raised by Niv on the list should be covered
> by the core spec. It directly aims at the trustworthiness of the user consent,
> which in my opinion is one of the core principles of OAuth. I therefore
> suggest to add a description to section 10.
> 
> Please find below the text Niv and I prepared. In comparison to  Niv's 
> original
> proposal, it covers resource owner impersonation for all client categories.
> 
> regards,
> Torsten.
> 
> proposed text:
> 
> 10. Resource Owner Impersonation
> 
> When a client requests access to protected resources, the authorization flow
> normally involves the resource owner's explicit response to the access
> request, either granting or denying access to the protected resources.
> 
> A malicious client can exploit knowledge of the structure of this flow in 
> order
> to gain authorization without the resource owner's consent, by transmitting
> the necessary requests programmatically, and simulating the flow against the
> authorization server. An suthorization server will be vulnerable to this 
> threat,
> if it uses non-interactive authentication mechanisms or split the 
> authorization
> flow across multiple pages.
> 
> It is RECOMMENDED that the authorization server takes measures to ensure
> that the authorization flow cannot be simulated.
> Attacks performed by scripts running within a trusted user-agent can be
> detected by verifying the source of the request using HTTP referrer headers.
> In order to prevent such an attack, the authorization server may force a user
> interaction based on non-predictable input values as part of the user consent
> approval.
> 
> The authorization server could combine password authentication and user
> consent in a single form, make use of CAPTCHAs or one-time secrets.
> 
> Alternatively, the authorization server could notify the resource owner of
> any approval by appropriate means, e.g. text message or e-Mail.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 20 last call comments

[Eran Hammer-Lahav]

> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Wednesday, August 17, 2011 1:13 PM

> > > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access
> > > Token, Refresh Token
> >
> > Not sure. What do others think? I put access token first because it is a 
> > more
> important term to get out of the way.
> 
> I agree that access tokens are a more important topic to OAuth overall, but
> the rest of the document presents things in protocol flow order: you get the
> auth grant, then you get the tokens.

Ok. I'll give it a try.

> > > 1.4.1: We probably want to mention a user agent here in the exposure
> > > risk at the end. Since that's really the problem -- the browser
> > > could steal the token, not the end user.
> >
> > Proposed text?
> 
>The authorization code provides a few important security benefits
>such as the ability to authenticate the client and issuing the access
>token directly to the client without potentially exposing it to
>others, including the resource owner or other applications in the resource
>owner's user agent.

How about:

The authorization code provides a few important security benefits 
such as the ability
to authenticate the client, and the transmission of the the access 
token directly to
the client without passing it through the resource owner's 
user-agnet, potentially
exposing it to others, including the resource owner.

> > > 2: Isn't "means" generally treated as singular in instances like this?
> > > Thus "means ... is" instead of "means ... are".
> >
> > Don't know.
> 
> I think it is, unless someone can put a stake in to say that's wrong.

"It is plural when it refers to a group of strategies or methods"
 
> > > 2.1/2.2: The requirements (2.2) should go first in section 2. The
> > > client types are part of deciding the requirements, and the concepts flow
> better this way.
> >
> > You need to first define client types before you can require it.
> 
> No you don't, you just need to reference them. You already don't define the
> other requirements until after (such as the redirection urls). I think it 
> reads
> better to have the requirements up front, when the full matter of what
> they're all about in the following sections. The client As it is now, there 
> are
> both forward and backward references in the requirements paragraph and
> it's confusing to read like that.

Ok.

> > > 2.4.2: Want to mention the MAC binding as an example here? This
> > > would parallel the OAuth2 method of signing the fetch for a request
> > > token more directly.
> >
> > Nah.
> 
> Let me put it stronger: I would like to see an explicit reference to the MAC
> binding here as an example of a stronger auth binding, along with an
> example. OAuth1 allowed for binding against the token endpoint using a
> client secret that was not passed across the wire, and the MAC spec gives
> that capability to OAuth2. I would really like to see that.
> 
> I see no problem in the core document pointing out the MAC and Bearer
> documents as prime examples where appropriate.

Pointing to the MAC specification in this context will be both confusing and 
against the balance we have reached (with great effort) in how we discuss 
authentication. No one is a bigger supporter of the MAC proposal than me... and 
I rather avoid this reference, here.

EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OMA Liaison Has Arrived!

[Igor Faynberg]

Barry,

I personally think that this is both a very thorough and very timely 
follow-up.


(You may consider a minor editorial: "As this writing" in the first 
answer, should be "As of this writing."  Could not catch anything else.  
The only other suggestion is that maybe the response could omit RFC 
Queue and other details of the IETF process as those are unfamiliar to 
OMA. They asked for dates, and the dates are there.)


Igor


On 8/17/2011 4:34 PM, Barry Leiba wrote:

I'm sorry for the delay in getting this written.  Because of the
delay, the working group has just a short time to review my proposed
response, below.  Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.  Hannes, please also check with the IAB
in parallel, and make sure we can send this via Murray as soon as
we've resolved any WG objections.

Barry, as chair

-

The IETF OAuth working group thanks OMA ARC SEC for the liaison
statement titled "OAuth discovery and specification availability",
dated 18 July 2011.

The OMA liaison statement asks the OAuth working group to address five
issues, and our answers are as follows:

•   Availability of the IETF OAuth specifications: especially
[draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also
[draft-hammer-oauth-v2-mac-token],
[draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

Answer:
The IETF cannot guarantee publication dates, but we can give some
best-guess timeframes.  As this writing, draft-ietf-oauth-v2 and
draft-ietf-oauth-v2-bearer have completed Working Group last call and
are undergoing their final revisions before being sent to the IESG.
We expect the final versions of those documents to be in the RFC
Editor queue around the end of September, though it could be later if
issues come up in IETF-wide last call or during IESG evaluation.  The
draft-hammer-oauth-v2-mac-token document has been replaced by
draft-ietf-oauth-v2-http-mac, which is a working group document.  It
is likely to be in the RFC Editor queue by the end of the year.

The remaining two documents are not working group documents, and the
working group can say nothing about their status.  The OAuth working
group intends to revise its charter in the November timeframe, and
it's possible that one or both of those documents could be adopted by
the working group at that time, and we could have further information
about target publication dates then.

•   Availability of the OAuth Parameters Registry

Answer:
The draft-ietf-oauth-v2 document establishes the OAuth Parameters
Registry (in section 11.2, as of draft version 20).  The registry will
be available when the RFC is published, which will be some time after
the document goes into the RFC Editor queue, depending upon the RFC
Editor's load at the time.

•   IETF intent to specify an OAuth Discovery mechanism

Answer:
There is interest among OAuth working group participants for
specifying such a mechanism, but the work is not in the current
charter.  It will likely be considered during the aforementioned
charter update in (approximately) November.

•   Considerations that can help implementors decide about the type of
OAuth access token to deploy.

Answer:
There is no current work planned, but documents with such
implementation advice might also be considered during the rechartering
discussion.

•   For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

Answer:
In the bearer token document (Section 2.4 of
draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header
Field"), the "scope-v" element is unambiguously defined to allow a
specific set of characters.  That set of characters does permit, but
does not mandate, support for percent-encoding of characters.

-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OMA Liaison Has Arrived!

[Barry Leiba]

I'm sorry for the delay in getting this written.  Because of the
delay, the working group has just a short time to review my proposed
response, below.  Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.  Hannes, please also check with the IAB
in parallel, and make sure we can send this via Murray as soon as
we've resolved any WG objections.

Barry, as chair

-

The IETF OAuth working group thanks OMA ARC SEC for the liaison
statement titled "OAuth discovery and specification availability",
dated 18 July 2011.

The OMA liaison statement asks the OAuth working group to address five
issues, and our answers are as follows:

•   Availability of the IETF OAuth specifications: especially
[draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also
[draft-hammer-oauth-v2-mac-token],
[draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

Answer:
The IETF cannot guarantee publication dates, but we can give some
best-guess timeframes.  As this writing, draft-ietf-oauth-v2 and
draft-ietf-oauth-v2-bearer have completed Working Group last call and
are undergoing their final revisions before being sent to the IESG.
We expect the final versions of those documents to be in the RFC
Editor queue around the end of September, though it could be later if
issues come up in IETF-wide last call or during IESG evaluation.  The
draft-hammer-oauth-v2-mac-token document has been replaced by
draft-ietf-oauth-v2-http-mac, which is a working group document.  It
is likely to be in the RFC Editor queue by the end of the year.

The remaining two documents are not working group documents, and the
working group can say nothing about their status.  The OAuth working
group intends to revise its charter in the November timeframe, and
it's possible that one or both of those documents could be adopted by
the working group at that time, and we could have further information
about target publication dates then.

•   Availability of the OAuth Parameters Registry

Answer:
The draft-ietf-oauth-v2 document establishes the OAuth Parameters
Registry (in section 11.2, as of draft version 20).  The registry will
be available when the RFC is published, which will be some time after
the document goes into the RFC Editor queue, depending upon the RFC
Editor's load at the time.

•   IETF intent to specify an OAuth Discovery mechanism

Answer:
There is interest among OAuth working group participants for
specifying such a mechanism, but the work is not in the current
charter.  It will likely be considered during the aforementioned
charter update in (approximately) November.

•   Considerations that can help implementors decide about the type of
OAuth access token to deploy.

Answer:
There is no current work planned, but documents with such
implementation advice might also be considered during the rechartering
discussion.

•   For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

Answer:
In the bearer token document (Section 2.4 of
draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header
Field"), the "scope-v" element is unambiguously defined to allow a
specific set of characters.  That set of characters does permit, but
does not mandate, support for percent-encoding of characters.

-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 20 last call comments

[Justin Richer]

Comments inline.

On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote:
> Thanks for the feedback.
> 
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Justin Richer
> > Sent: Thursday, August 11, 2011 2:07 PM
> 
> > 1.2/1.4: The term "authorization grant" remains confusing and the
> > introduction is riddled with jargon like "intermediate credential". With the
> > diagram in 1.2, it appears to be an explicit technological underpinning of 
> > the
> > protocol flow instead of a general conceptual construct that is used in 
> > several
> > different ways. Basically, what "authorization grant" *means* is not obvious
> > within this document.
> >
> > Section 4 makes much more sense than the introduction text does here.
> > Perhaps we should just replace most of 1.4 with just the introductory text 
> > to
> > 4 (perhaps slightly expanded), and then a reference to the sub-parts of
> > section 4 for the meat of the concept (and in the process, nix the 
> > subsections
> > of 1.4 entirely).
> > 
> > 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the 
> > last
> > sentence is awkward. Suggest reword to:
> > The client receives an authorization grant which represents the
> > authorization granted by the resource owner.  The type of
> > authorization grant is dependent on which methods are supported
> > by both the client and authorization server.
> 
> Change (B) in 1.2 to:
> 
>   The client receives an authorization grant which is a 
> credential representing
>   the resource owner's authorization, expressed using one of four 
> grant types defined
>   in this specification or using an extension grant type. The 
> authorization grant type
>   depends on the method used by the client to request 
> authorization and the types
>   supported by the authorization server.
>
> And changed 1.4 to:
> 
>   An authorization grant is a credential representing the resource 
> owner's authorization
>   (to access its protected resources) used by the client to obtain an 
> access token. This
>   specification defines four grant types: authorization code, 
> implicit, resource owner
>   password credentials, and client credentials, as well as an 
> extensibility mechanism for
>   defining additional types.

Much better for both overall though.


> > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
> > Refresh Token
> 
> Not sure. What do others think? I put access token first because it is a more 
> important term to get out of the way.

I agree that access tokens are a more important topic to OAuth overall,
but the rest of the document presents things in protocol flow order: you
get the auth grant, then you get the tokens.

> > 1.4.1: We probably want to mention a user agent here in the exposure risk at
> > the end. Since that's really the problem -- the browser could steal the 
> > token,
> > not the end user.
> 
> Proposed text?

   The authorization code provides a few important security benefits
   such as the ability to authenticate the client and issuing the access
   token directly to the client without potentially exposing it to
   others, including the resource owner or other applications in the resource
   owner's user agent.

(Still not good wording... but the idea is to point out that you the
leak possibility here stems from using the front channel.)

> > 1.4.2: Still don't like the term "implicit". It's misleading. Even "direct
> > authorization" would be better, though still not ideal.
> 
> It's the best we've got. "Direct authorization" is not a grant type, but a 
> flow description.

Fair enough. I shall remain a conscientious objector. :)

> > 1.4.5: Throw a simple reference to 8.3 here?
> 
> No forward references whenever possible.

Fair style point, but I think this one is worth it. This is why our
documents have hyperlinks.



For each of 1.4.x, I'd still rather see the 1.4.x sections just go away.



> > 2: Isn't "means" generally treated as singular in instances like this?
> > Thus "means ... is" instead of "means ... are".
> 
> Don't know.

I think it is, unless someone can put a stake in to say that's wrong.

> > 2.1/2.2: The requirements (2.2) should go first in section 2. The client 
> > types
> > are part of deciding the requirements, and the concepts flow better this 
> > way.
> 
> You need to first define client types before you can require it.

No you don't, you just need to reference them. You already don't define
the other requirements until after (such as the redirection urls). I
think it reads better to have the requirements up front, when the full
matter of what they're all about in the following sections. The client
As it is now, there are both forward and backward references in the
requirements paragraph and it's confusing to read like that.

> > 2.1: I l

Re: [OAUTH-WG] Draft 20 last call comments

[Eran Hammer-Lahav]

Thanks for the feedback.

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Justin Richer
> Sent: Thursday, August 11, 2011 2:07 PM

> 1.2/1.4: The term "authorization grant" remains confusing and the
> introduction is riddled with jargon like "intermediate credential". With the
> diagram in 1.2, it appears to be an explicit technological underpinning of the
> protocol flow instead of a general conceptual construct that is used in 
> several
> different ways. Basically, what "authorization grant" *means* is not obvious
> within this document.
>
> Section 4 makes much more sense than the introduction text does here.
> Perhaps we should just replace most of 1.4 with just the introductory text to
> 4 (perhaps slightly expanded), and then a reference to the sub-parts of
> section 4 for the meat of the concept (and in the process, nix the subsections
> of 1.4 entirely).
> 
> 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the last
> sentence is awkward. Suggest reword to:
> The client receives an authorization grant which represents the
> authorization granted by the resource owner.  The type of
>   authorization grant is dependent on which methods are supported
>   by both the client and authorization server.

Change (B) in 1.2 to:

  The client receives an authorization grant which is a credential 
representing
  the resource owner's authorization, expressed using one of four 
grant types defined
  in this specification or using an extension grant type. The 
authorization grant type
  depends on the method used by the client to request authorization 
and the types
  supported by the authorization server.

And changed 1.4 to:

  An authorization grant is a credential representing the resource 
owner's authorization
  (to access its protected resources) used by the client to obtain an 
access token. This
  specification defines four grant types: authorization code, implicit, 
resource owner
  password credentials, and client credentials, as well as an 
extensibility mechanism for
  defining additional types.

> 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
> Refresh Token

Not sure. What do others think? I put access token first because it is a more 
important term to get out of the way.

> 1.4.1: We probably want to mention a user agent here in the exposure risk at
> the end. Since that's really the problem -- the browser could steal the token,
> not the end user.

Proposed text?

> 1.4.2: Still don't like the term "implicit". It's misleading. Even "direct
> authorization" would be better, though still not ideal.

It's the best we've got. "Direct authorization" is not a grant type, but a flow 
description.

> 1.4.5: Throw a simple reference to 8.3 here?

No forward references whenever possible.

> 2: Isn't "means" generally treated as singular in instances like this?
> Thus "means ... is" instead of "means ... are".

Don't know.

> 2.1/2.2: The requirements (2.2) should go first in section 2. The client types
> are part of deciding the requirements, and the concepts flow better this way.

You need to first define client types before you can require it.

> 2.1: I like the calling out of the types of clients, it helps cement things.
> 
> 2.3: Suggest renaming to "Client Identification" to parallel "Client
> Authentication" in 2.4

It's not about identification.
 
> 2.3: Should "... cannot be used alone" be made into a normative, as "...
> MUST NOT be used alone"?

I'm ok with that. Anyone else?

> 2.4.2: Want to mention the MAC binding as an example here? This would
> parallel the OAuth2 method of signing the fetch for a request token more
> directly.

Nah.

> 3. Authorization endpoint's "used to obtain authorization from" should be
> "used to obtain an authorization grant from", to be parallel with the token
> endpoint description.

Ok.

EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)

[Lodderstedt, Torsten]

Text sounds very good.

wrt title: this threat is about phishing another user's authorization code. 
Because of the design of the protocol this requires the attacker to use another 
redirect URI than used by the legitimate client. To make this the title sound 
bit weird to me. Why not "authorization code phishing"?

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Mittwoch, 17. August 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)


> 10.6. Authorization Code Leakage: Comment "I fancy myself as being

> reasonably intelligent and I'm unclear what attack is actually being described

> here."



Yeah... I had to go back to -16 to be reminded of the section original title 
'session fixation attack' to figure out what this was about.



How about this:



10.6.  Authorization Code Redirection URI Manipulation



   When requesting authorization using the authorization code grant

   type, the client can specify a redirection URI via the "redirect_uri"

   parameter.  If an attacker can manipulate the value of the

   redirection URI, it can cause the authorization server to redirect

   the resource owner user-agent to a URI under the control of the

   attacker with the authorization code.



   An attacker can create an account at a legitimate client and initiate

   the authorization flow.  When the attacker is sent to the

   authorization server to grant access, the attacker grabs the

   authorization URI provided by the legitimate client, and replaces the

   client's redirection URI with a URI under the control of the

   attacker.  The attacker then tricks the victim into following the

   manipulated link to authorize access to the legitimate client.



   Once at the authorization server, the victim is prompted with a

   normal, valid request on behalf of a legitimate and familiar client,

   and authorizes the request.  The victim is then redirected to an

   endpoint under the control of the attacker with the authorization

   code.  The attacker completes the authorization flow by sending

   the authorization code to the client using the original redirection

   URI provided by the client.  The client exchanges the authorization

   code with an access token and links it to the attacker's client

  account which can now gain access to the protected resources

   authorized by the victim (via the client).



   In order to prevent such an attack, the authorization server MUST

   ensure that the redirection URI used to obtain the authorization

   code, is the same as the redirection URI provided when exchanging the

   authorization code for an access token.  The authorization server

   SHOULD require the client to register their redirection URI and if

   provided, MUST validate the redirection URI received in the

   authorization request against the registered value.



EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] x-www-form-urlencoded

[Eran Hammer-Lahav]

This seems to include two separate items.

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Anthony Nadalin
> Sent: Friday, August 12, 2011 8:29 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] x-www-form-urlencoded
> 
> In the text on the authorization and token endpoints an assumption is made
> that the query component of the URLs will be specified based on x-www-
> form-urlencoded. But in fact that is never explicitly stated. What is 
> explicitly
> stated is that RFC 3986 section 3 has to be used (and then only for the
> authorization endpoint, not the token endpoint). But section 3 just defines
> what characters can be used in a query component, it says nothing about x-
> www-form-urlencoded. Suggest that the specification needs  to normatively
> state that we are requiring all authorization endpoints that use the query
> component to do so using x-www-form-urlencoded. 

This issue was raised by Yaron and corrected for both endpoints as indicated on 
the other thread. The new text is:

  The endpoint URI MAY include an "application/x-www-form-urlencoded" 
formatted
  ([W3C.REC-html401-19991224]) query component ([RFC3986] section 3.4), 
which MUST
  be retained when adding additional query parameters. The endpoint URI 
MUST NOT
  include a fragment component.

> Where RFC 5552 comes
> into the picture is in cases where the request body is an html form. In that
> case it makes sense to natively encode the form content using UTF-8. So this
> only applies to OAuth requests that use the request body. So this would
> apply to sections 2.4.1, 3.1, 3.2, 4.1.3, 4.3.2 & 4.4.2. Really, anywhere 
> that a
> request can be made in the request body

I have no idea what this is about.

EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland

[Eran Hammer-Lahav]

This is fantastic feedback. Some parts moved to new threads.

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Wednesday, August 10, 2011 2:39 PM

> 1.4. Authorization Grant: Change "resource owner authorization" to
> "resource owner's authorization".

Ok.

> 1.4.1. Authorization Code:  Comment: "It seems odd that we can discuss the
> authorization code without also discussing the security issues it raises (e.g.
> passing secure information via a browser) and thus motivating the
> introduction of the refresh token. I would expect this to be referred to
> here.  Having read the security considerations section I can find no coherent
> discussion there either of the relationship between the authorization code
> and the refresh token and why one motivated the other. I think this is
> something important for implementers to understand."

This particular relationship has not been discussed on the list before.

The primary justifications of refresh tokens were the need to allow access 
token rotations because of the weaker nature of bearer tokens, and to support 
large scale deployments in which access tokens are self-contained and do not 
require a DB lookup (which implies short-lived, similar to self-contained 
session cookies).

If we are going to add a discussion, it should cover these as well, however, 
such a discussion really belongs in the threat model document. We have not 
included any other motivations in the document and I don't feel this justifies 
an exception.

Either way, please provide text and we can decide where it belongs.

> 1.4.2.  Implicit:  Comment: "I find this section confusing. I think an 
> example is
> all but mandatory here if the reader is to understand what is intended.  For
> example, when I first read this section I thought it was some kind of short 
> cut
> used in cases where the client and authorization server had a close
> relationship and could share information such as the client's identity so no
> access code was needed.  No where in here is any hint that this is about
> browser based clients who don't have servers and who need a way to get
> tokens. Seriously. Try to read this section as someone who knows nothing
> about OAuth and tell me that you get the right idea back from it. It needs to
> be written to be both explicit as to its goals and clearer as to its means."

Changed first paragraph to:

The implicit grant is a simplified authorization code flow 
optimized for clients
implemented in a browser using a scripting language such as 
JavaScript. In the implicit
flow, instead of issuing the client an authorization code, the 
client is issued an
access token directly (as the result of the resource owner 
authorization). The grant
type is implicit as no intermediate credentials (such as an 
authorization code) are
issued (and later used to obtain an access token).

> 1.4.2.  Implicit:  Change "authenticate the client and the" to "authenticate 
> the
> client directly. The".

Text already changed.

> 1.4.2.  Implicit:  Change "weighted" to "weighed".

Ok.

> 1.4.3.  Resource Owner Password Credentials: Comment on "(when
> combined with a refresh token)": "This is the first time that refresh tokens
> are mentioned in the spec. And yet there is no explanation of what they are.
> I suspect they should anyway be introduced in section 1.4.1 (as previously
> noted) and then their use here will make sense.  If that isn't possible then 
> it
> would be good to have a forward reference to section 1.5 below so the
> reader has some idea of what's going on."

I removed '(when combined with a refresh token)'. This is actually not true as 
there is no assumption that access tokens are always short-lived or that 
refresh tokens will always be issued to native applications using this grant 
type.

> 1.4.4.  Client Credentials:  Comment on "(the client is also the resource
> owner)": "I think this is misleading. Imagine something like Office where a
> client has been granted access to a particular resource by the resource
> owner. The client can then ask for an access token to the resource using the
> client credentials and no access code or refresh token. Just having the
> address of the intended resource (probably provided via SCOPE) along with
> the client credentials is more than enough to decide if an access token should
> be issued.
>
> My point is that the client credentials scenario is fully applicable to cases
> where the client is not the resource owner but in which the resource URI
> provides all the context needed to determine if the client should be able to
> get an access token. I think the current text would imply otherwise.
>
> So I would propose changing the sentence to "Client credentials are used as
> an authorization grant when the client is acting on its own behalf (the 
> client is
> also the resource owner) or when th