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

[Lodderstedt, Torsten]

The security document designates it as "Authorization code leakage through 
counterfeit client"

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7


Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

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]

There was no argument made. You described a CSRF attack scenario which carries 
the exact same risk and uses the exact same solution as the CSRF attack already 
present in the specification. Then jumped from there to a new normative 
requirement. I have not seen any argument to justify the new MUST requirement - 
if I have missed it, please point me in the right direction.

Also, -20 has no such inconsistencies. It is OPTIONAL in one place and 
RECOMMENDED in the other.

However, -20 does not *require* CSRF protection which put it at odds with how 
we address every other attack vector, so we are in full agreement that CSRF 
prevention is a MUST. My text fixes that in a manner consistent with how you 
and the other security consideration section drafters approached many of the 
other sections (by requiring a solution but not limiting developers to a 
particular one).

There are two open issues:

- the quality of the prose (I agree that Bill's text is a good new starting 
point), and

- whether we should dictate to developers the parameter name (and location) of 
the CSRF artifact.

If we decide that we should mandate such a parameter, we then need to decide if 
'state' is the right place and if it is, find a new way to describe it because 
using it for CSRF is a relative new use case for the parameter (which still 
have all the previous use cases).

EHL


From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Wednesday, August 17, 2011 11:41 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

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

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

[Eran Hammer-Lahav]

But it's not really a counterfeit client but a real client with modified 
redirection uri. It is a counterfeit redirection endpoint. *I* understand 
exactly what you mean, but I fear new readers will get completely confused by 
the title.

EHL

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

The security document designates it as "Authorization code leakage through 
counterfeit client"

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7


Von: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

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] Authorization Code Leakage feedback (Yaron Goland)

[Lodderstedt, Torsten]

In my opinion, the counterfeit redirection endpoint is another client - the 
counterfeit client. The attacker must trick the victim into accessing this 
client and approving the authorization request. So I would assume the attacker 
would try to let his endpoint look like the real client.

Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 09:17
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

But it's not really a counterfeit client but a real client with modified 
redirection uri. It is a counterfeit redirection endpoint. *I* understand 
exactly what you mean, but I fear new readers will get completely confused by 
the title.

EHL

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

The security document designates it as "Authorization code leakage through 
counterfeit client"

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7


Von: Eran Hammer-Lahav 
[mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

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] Draft 20 last call comments

[Lodderstedt, Torsten]

>> 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 would rather consider to change order to Access Token, Refresh Token, 
Authorization Grant since the first two are the core OAuth concepts developers 
must become familiar with. Authorization grants are "just" an mean to an end to 
get the token for certain client types. Moreover, I expect the number of 
authorization grants to increase over time.

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

+1

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

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

[Lodderstedt, Torsten]

+1

-Ursprüngliche Nachricht-
Von: Barry Leiba [mailto:barryle...@computer.org] 
Gesendet: Mittwoch, 17. August 2011 22:35
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived!

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] Draft 20 last call comment (Resource Owner Impersonation)

[Lodderstedt, Torsten]

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

I'm honestly surprised you do not understand the attack. The client simply uses 
screen scraping on the authorization flow and programmatically "presses" the 
right buttons. This obviously only works if the client can predict the form 
structure and expected input values.

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

This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 
others (Phil, Tony, Barry) and all agree with it. What is the foundation of 
your strong assessment?

The text proposes three classes of countermeasures (detect source, prevent 
using unpredictable input, inform resource owner and give her a chance to 
revoke). CAPTCHAs are one out of three examples given for unpredictable input. 
So I don't understand why your objection focuses on it. The selection of the 
appropriate countermeasure is the task of the service provider and it will most 
likely depend this on its capabilities, cost, user experience, and risk/impact 
associated with abuse. CAPTCHAs (and even one time passwords) might not be the 
choice for the average internet service. This will be completely different if 
OAuth is used to process payment transactions.

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

See above - I probably misunderstand the IETF process, but several people 
agreed with it and no one (except you) objected. Why do you hold it back? 

regards,
Torsten.

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

[Lodderstedt, Torsten]

>> 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 against removing this text (w/o an suitable replacement) and w/o group 
consent. 

The -20 text clearly points out that this combination "... eliminates the need 
for the client to store the resource owner credentials for future use". The 
resource owner grant type alone does not justify this statement.
It's true that the spec does not explicitly defines the lifetime assumption for 
access and refresh tokens (which is pity in my opinion). So at least add 
something like "if the token lifetime is reasonable long enough".

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

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

[Manger, James H]

>> *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.


This is a poor answer.
A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." 
response will either compare it with strings from a OAuth2 JSON-encoded token 
response, or copy it into a request to an authorization server. It needs to 
know if it needs to %-decode the value or not before doing these things. 
Clients cannot be expected to behave differently for different servers in this 
respect.

OAuth2 core (implicitly) allows a scope to use any Unicode char except space 
(as space is used as a delimiter).
Bearer restricts scopes to 93 ASCII chars.
OMA are asking if this is intentional.

If we really want to restrict scope values it would be better done in OAuth2 
core.
If we don't want to restrict values then the bearer spec needs to be able to 
handle any possible scope value by defining an escaping mechanism for scope-v 
(or by not having a scope parameter).

--
James Manger

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

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

[Niv Steingarten]

Here are two very simple examples. They are very naive ones, but get the
point across and I would not be suprised if they could be found in the
wild:

Say a client has its authorization endpoint at

  (1) http://www.domain.com/auth.php

A client requests access to protected resources by redirecting the
user-agent to:

  (2) http://www.domain.com/auth.php?response_type=code&client_id=1234&;
  redirect_uri=SOMEURI&scope=SOMESCOPE

One possible design choice for the developer, if a bad one, is to have
the 'Allow' button point to:

  (3) http://www.domain.com/auth.php?[..previous query params..]&allow=1

In this case, a malicious client who knows the structure of this auth
flow, can simply skip (2) and redirect the user-agent to (3) in order
to gain access to the protected resources.

Another possible design choice for the developer (again, a very bad
one) would be to issue some kind of session cookie after (2) in order
to keep a state. Then, the 'Allow' button could possibly point to:

  (4) http://www.domain.com/allow.php

without any parameters (since the state is maintained by a cookie).

Here, an attacker could launch a request to (2) just to issue the state
cookie, and immediately redirect the user-agent to (4) in order to gain
access to the protected resources.

These are two very naive scenarios which can be averted using a nonce
for example (+ better design choices, for that matter).

In non-user-agent based clients, a client might also be able to actually
scrape the contents of the authorization HTML page, and simulate the
click programmatically. In this case a nonce would be useless, but a
CAPTCHA or a PIN code/password would solve the problem.

-- Niv



On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav  wrote:
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org

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

[Justin Richer]

> >> 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 would rather consider to change order to Access Token, Refresh Token, 
> Authorization Grant since the first two are the core OAuth concepts 
> developers must become familiar with. Authorization grants are "just" an mean 
> to an end to get the token for certain client types. Moreover, I expect the 
> number of authorization grants to increase over time.

You have to use *some* kind of authorization grant to get any kind of
token, and this part of the OAuth spec is all about "how to get a token
in a programmatic way". I agree that there will be many more types of
auth grants in the future, and that's why I think it should be the first
concept in the list.

I can see the logic of putting both token types first (though I still
prefer the auth grant first), but having the auth grant in between the
two token types is definitely a bad idea.

 -- Justin

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

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

[Torsten Lodderstedt]

I can see the logic of putting both token types first (though I still
prefer the auth grant first), but having the auth grant in between the
two token types is definitely a bad idea.


+1



  -- Justin

___
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 comment (Resource Owner Impersonation)

[Igor Faynberg]

This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others 
(Phil, Tony,>Barry) and all agree with it.


Maybe my e-mail was lost, but I was and still am among those who have agreed 
with the text, as I am sure many others have

What is also important is that no one has objected.

I see neither the reason nor the right of an editor to remove the text.

Igor


On 8/18/2011 3:51 AM, Lodderstedt, Torsten wrote:

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?

I'm honestly surprised you do not understand the attack. The client simply uses screen 
scraping on the authorization flow and programmatically "presses" the right 
buttons. This obviously only works if the client can predict the form structure and 
expected input values.


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.

This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 
others (Phil, Tony, Barry) and all agree with it. What is the foundation of 
your strong assessment?

The text proposes three classes of countermeasures (detect source, prevent 
using unpredictable input, inform resource owner and give her a chance to 
revoke). CAPTCHAs are one out of three examples given for unpredictable input. 
So I don't understand why your objection focuses on it. The selection of the 
appropriate countermeasure is the task of the service provider and it will most 
likely depend this on its capabilities, cost, user experience, and risk/impact 
associated with abuse. CAPTCHAs (and even one time passwords) might not be the 
choice for the average internet service. This will be completely different if 
OAuth is used to process payment transactions.


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

See above - I probably misunderstand the IETF process, but several people 
agreed with it and no one (except you) objected. Why do you hold it back?

regards,
Torsten.

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
___
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 comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

Thanks. You have a typo in #1 (the authorization endpoint belongs to the 
authorization server, not client).

This is a textbook CSRF attack on the authorization endpoint.

The right solution is for the authorization server to set or maintain a session 
cookie (or other same-origin-protected state in the browser) in #1 as well as 
some hidden CSRF token in the Accept form and not allow CORS calls to that 
endpoint. I don't see how the measures proposed in the new section are relevant 
here.

EHL


> -Original Message-
> From: Niv Steingarten [mailto:nivst...@gmail.com]
> Sent: Thursday, August 18, 2011 5:49 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> Here are two very simple examples. They are very naive ones, but get the
> point across and I would not be suprised if they could be found in the
> wild:
> 
> Say a client has its authorization endpoint at
> 
>   (1) http://www.domain.com/auth.php
> 
> A client requests access to protected resources by redirecting the user-agent
> to:
> 
>   (2)
> http://www.domain.com/auth.php?response_type=code&client_id=1234&;
>   redirect_uri=SOMEURI&scope=SOMESCOPE
> 
> One possible design choice for the developer, if a bad one, is to have the
> 'Allow' button point to:
> 
>   (3) http://www.domain.com/auth.php?[..previous query
> params..]&allow=1
> 
> In this case, a malicious client who knows the structure of this auth flow, 
> can
> simply skip (2) and redirect the user-agent to (3) in order to gain access to 
> the
> protected resources.
> 
> Another possible design choice for the developer (again, a very bad
> one) would be to issue some kind of session cookie after (2) in order to keep
> a state. Then, the 'Allow' button could possibly point to:
> 
>   (4) http://www.domain.com/allow.php
> 
> without any parameters (since the state is maintained by a cookie).
> 
> Here, an attacker could launch a request to (2) just to issue the state 
> cookie,
> and immediately redirect the user-agent to (4) in order to gain access to the
> protected resources.
> 
> These are two very naive scenarios which can be averted using a nonce for
> example (+ better design choices, for that matter).
> 
> In non-user-agent based clients, a client might also be able to actually 
> scrape
> the contents of the authorization HTML page, and simulate the click
> programmatically. In this case a nonce would be useless, but a CAPTCHA or a
> PIN code/password would solve the problem.
> 
> -- Niv
> 
> 
> 
> On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav 
> wrote:
> > 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 w

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

[Eran Hammer-Lahav]

Hey Torsten,

> -Original Message-
> From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
> Sent: Thursday, August 18, 2011 12:52 AM
> To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org
> Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> >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?
> 
> I'm honestly surprised you do not understand the attack. The client simply
> uses screen scraping on the authorization flow and programmatically
> "presses" the right buttons. This obviously only works if the client can 
> predict
> the form structure and expected input values.

That's not an attack but a description of capabilities. The attack example 
provided by Niv is a *classic* CSRF attack on the authorization endpoint.

> >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.
> 
> This text has been proposed by 2 WG members (Niv and me), and reviewed
> by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation 
> of
> your strong assessment?

I don't understand the attack and how the proposed solution address it. I'm 
really happy for everyone else who got it, but I need more information to 
process it.

> The text proposes three classes of countermeasures (detect source, prevent
> using unpredictable input, inform resource owner and give her a chance to
> revoke). CAPTCHAs are one out of three examples given for unpredictable
> input. So I don't understand why your objection focuses on it.

True. But it was central in the list discussion and was promoted as strong 
defense to whatever this attack is. I think that CAPCHA is an impractical 
recommendation in general for the authorization endpoint. Can you point to any 
real world example of a large provider forcing CAPCHA on every login? That's 
what this amounts to.

> The selection
> of the appropriate countermeasure is the task of the service provider and it
> will most likely depend this on its capabilities, cost, user experience, and
> risk/impact associated with abuse. CAPTCHAs (and even one time
> passwords) might not be the choice for the average internet service. This will
> be completely different if OAuth is used to process payment transactions.

The text hints at a very dangerous attack vector of scripts doing 'really bad 
things'. But it doesn't show why this attack requires any kind of automation at 
all. If I am targeting just a small number of people, I can "automate" this by 
sending a message to a human who will break the CAPCHA and quickly return the 
link to approve access. The other measures either have the same properties, are 
just there to annoy the attacker, or provide some kind of after the fact notice 
(when it is clearly too late to prevent damage).

> >I'm keeping this proposed text out until we resolve this questions.
> 
> See above - I probably misunderstand the IETF process, but several people
> agreed with it and no one (except you) objected. Why do you hold it back?

"no one (except you)" is an interesting statement... :-)

This is not a process issue. New text has been proposed with the support of a 
few working group members. The working group has been largely silent about it 
(and the review you referenced above was done off list). I have read the new 
text and did not understand it, therefore, could not edit the text as I have 
done with every other proposed language.

No new draft will be published until we resolve all open issues, which is 
exactly what I have stated above. To make it clearer:

I am keeping this proposed text out of *my* working draft for -21 until the 
working group discusses the text further and addresses the issues I have raised 
about the text as a working group member (technical issues) and as an editor 
(clarity issues).

As for IETF process, all it takes is one objection to block text from being 
*automatically* added to the specification. I have not implied anywhere that I 
have made any decision (or have the authority to) with regard to this text, 
only that I'm holding it back until the issues are resolved. And IETF process 
does not require full agreement to solve issues which is the role of the chairs 
to resolve. In this case, we're nowhere near needing help from the chairs - 
just the assistance of the text authors to do their job and explain it.

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

[Anthony Nadalin]

Agree,  against the removal of text

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, August 18, 2011 1:01 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 
from Yaron Goland

>> 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 against removing this text (w/o an suitable replacement) and w/o group 
consent. 

The -20 text clearly points out that this combination "... eliminates the need 
for the client to store the resource owner credentials for future use". The 
resource owner grant type alone does not justify this statement.
It's true that the spec does not explicitly defines the lifetime assumption for 
access and refresh tokens (which is pity in my opinion). So at least add 
something like "if the token lifetime is reasonable long enough".

regards,
Torsten.
___
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 comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Igor Faynberg
> Sent: Thursday, August 18, 2011 8:49 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> >This text has been proposed by 2 WG members (Niv and me), and reviewed
> by 3 others (Phil, Tony,>Barry) and all agree with it.
> 
> Maybe my e-mail was lost, but I was and still am among those who have
> agreed with the text, as I am sure many others have

Fantastic! Now explain it to me.

> What is also important is that no one has objected.
> 
> I see neither the reason nor the right of an editor to remove the text.

Nothing was *removed* - it wasn't even rejected. It is simply held back to 
allow additional discussion and it is clearly within the role of editor.

EHL

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

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

[Eran Hammer-Lahav]

I'd like to ask the chairs to open an issue for this.

I didn't realize how hyper sensitive this working group has become that every 
proposal being questioned needs a ticket to prove to people that they are not 
being dismissed. But since this is clearly the case, let's be pedantic and open 
an issue.

EHL

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, August 17, 2011 10:58 PM
> To: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Niv Steingarten]

(thanks for the typo correction)

Yes, the example I provided is a very lightweight one which does take
the form of CSRF, but it is only the simplest example of a family of
automated authorization flow attacks. Indeed, a nonce (or hidden
token, both serve the same purpose in this case) would be enough here.

If the client is not user-agent based, a full-fledged forgery of the
whole process is possible, one in which CORS and sandboxes have no
meaning. In a native client, unless some kind of human test is
performed, the whole flow could be spoofed. A CAPTCHA and/or password
entry are not bullet-proof, but they provide a steep obstacle for the
attacker. Another option would be, for example, to email the resource
owner an OTP, with the following message "The application [...]
requests access to [...]. Please use the number  to allow it
access etc..." (similar to Google's and Facebook's two-step sign-in).

The first attack described in my previous message takes the form of
CSRF, while the above one may be bypassed by an attacker with the help
of some sort of clickjacking or similar. Eventually this threat
description is for a family of attacks which mimic the behavior of the
resource owner in order to gain access to protected resources, and
some possible countermeasures.

-- Niv



On Thu, Aug 18, 2011 at 19:23, Eran Hammer-Lahav  wrote:
> Thanks. You have a typo in #1 (the authorization endpoint belongs to the 
> authorization server, not client).
>
> This is a textbook CSRF attack on the authorization endpoint.
>
> The right solution is for the authorization server to set or maintain a 
> session cookie (or other same-origin-protected state in the browser) in #1 as 
> well as some hidden CSRF token in the Accept form and not allow CORS calls to 
> that endpoint. I don't see how the measures proposed in the new section are 
> relevant here.
>
> EHL
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 5:49 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> Here are two very simple examples. They are very naive ones, but get the
>> point across and I would not be suprised if they could be found in the
>> wild:
>>
>> Say a client has its authorization endpoint at
>>
>>   (1) http://www.domain.com/auth.php
>>
>> A client requests access to protected resources by redirecting the user-agent
>> to:
>>
>>   (2)
>> http://www.domain.com/auth.php?response_type=code&client_id=1234&;
>>       redirect_uri=SOMEURI&scope=SOMESCOPE
>>
>> One possible design choice for the developer, if a bad one, is to have the
>> 'Allow' button point to:
>>
>>   (3) http://www.domain.com/auth.php?[..previous query
>> params..]&allow=1
>>
>> In this case, a malicious client who knows the structure of this auth flow, 
>> can
>> simply skip (2) and redirect the user-agent to (3) in order to gain access 
>> to the
>> protected resources.
>>
>> Another possible design choice for the developer (again, a very bad
>> one) would be to issue some kind of session cookie after (2) in order to keep
>> a state. Then, the 'Allow' button could possibly point to:
>>
>>   (4) http://www.domain.com/allow.php
>>
>> without any parameters (since the state is maintained by a cookie).
>>
>> Here, an attacker could launch a request to (2) just to issue the state 
>> cookie,
>> and immediately redirect the user-agent to (4) in order to gain access to the
>> protected resources.
>>
>> These are two very naive scenarios which can be averted using a nonce for
>> example (+ better design choices, for that matter).
>>
>> In non-user-agent based clients, a client might also be able to actually 
>> scrape
>> the contents of the authorization HTML page, and simulate the click
>> programmatically. In this case a nonce would be useless, but a CAPTCHA or a
>> PIN code/password would solve the problem.
>>
>> -- Niv
>>
>>
>>
>> On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav 
>> wrote:
>> > 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,
>> >>
>>

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

[Igor Faynberg]

+1  (against the removal)



On 8/18/2011 12:58 PM, Anthony Nadalin wrote:

Agree,  against the removal of text

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Lodderstedt, Torsten
Sent: Thursday, August 18, 2011 1:01 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 
from Yaron Goland


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 against removing this text (w/o an suitable replacement) and w/o group 
consent.

The -20 text clearly points out that this combination "... eliminates the need for 
the client to store the resource owner credentials for future use". The resource 
owner grant type alone does not justify this statement.
It's true that the spec does not explicitly defines the lifetime assumption for access 
and refresh tokens (which is pity in my opinion). So at least add something like "if 
the token lifetime is reasonable long enough".

regards,
Torsten.
___
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

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

Chairs - please open an issue for this: "Clarifying reference to refresh tokens 
in section 1.4.3 of -20".

> -Original Message-
> From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
> Sent: Thursday, August 18, 2011 1:01 AM
> To: Eran Hammer-Lahav; oauth@ietf.org
> Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft 20
> from Yaron Goland
> 
> >> 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 against removing this text (w/o an suitable replacement) and w/o group
> consent.

Since you felt it necessary to make this a process issue, I've asked the chairs 
to open a ticket.

> The -20 text clearly points out that this combination "... eliminates the need
> for the client to store the resource owner credentials for future use". The
> resource owner grant type alone does not justify this statement.
> It's true that the spec does not explicitly defines the lifetime assumption 
> for
> access and refresh tokens (which is pity in my opinion). So at least add
> something like "if the token lifetime is reasonable long enough".

How about:

   This grant type can eliminates the need for the client to store the resource 
owner
   credentials for future use, by exchanging the credentials with a long-lived 
access
   token or refresh token.

As for Yaron's original comment, I think this text is sufficient and no forward 
reference is needed to 1.5 (which is a few lines lower in the same page). Also, 
with the new organization proposed by Justin, the access token term isn't full 
defined yet either and it reads just fine.

EHL

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

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Niv Steingarten [mailto:nivst...@gmail.com]
> Sent: Thursday, August 18, 2011 10:16 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> (thanks for the typo correction)
> 
> Yes, the example I provided is a very lightweight one which does take the
> form of CSRF, but it is only the simplest example of a family of automated
> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
> same purpose in this case) would be enough here.

Great. So we need to add explicit text about preventing CSRF attacks at the 
authorization endpoint.

> If the client is not user-agent based, a full-fledged forgery of the whole
> process is possible, one in which CORS and sandboxes have no meaning. In a
> native client, unless some kind of human test is performed, the whole flow
> could be spoofed.

Can you provide another example with the same level of detail as you provided 
below?

> A CAPTCHA and/or password entry are not bullet-proof,
> but they provide a steep obstacle for the attacker.

CAPTCHA and password entry are two completely difference measures and are 
rarely interchangeable. CAPTCHA does nothing more than increase the likelihood 
that the entity on the other side is a human. Any attack prevented by CAPTCHA 
must be one in which automation and speed are crucial. I still don't understand 
what it *solves*.

> Another option would be,
> for example, to email the resource owner an OTP, with the following
> message "The application [...] requests access to [...]. Please use the number
>  to allow it access etc..." (similar to Google's and Facebook's two-step
> sign-in).

Two-factor authentication is good, but completely impractical for most web 
authorization scenario. You need to remember that the authorization page is 
used for both the initial grant, but also for delegated login (by far a more 
frequent use). An access token can be issued almost automatically if the client 
has been previously authorized.

> The first attack described in my previous message takes the form of CSRF,
> while the above one may be bypassed by an attacker with the help of some
> sort of clickjacking or similar. Eventually this threat description is for a 
> family
> of attacks which mimic the behavior of the resource owner in order to gain
> access to protected resources, and some possible countermeasures.

I don't understand this "family of attacks".

EHL

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

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

[Barry Leiba]

> I'd like to ask the chairs to open an issue for this.

http://trac.tools.ietf.org/wg/oauth/trac/ticket/24

> I didn't realize how hyper sensitive this working group has become that every
> proposal being questioned needs a ticket to prove to people that they are not
> being dismissed.

It's OK: tickets are cheap, and I don't mind... and if it helps people
to know that discussions that aren't quickly resolved are being
tracked, then that's what the issue tracker is there for.  It makes
sure things don't get forgotten, and reminds people what to look more
closely at in the next doc rev.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Barry Leiba]

>> Yes, the example I provided is a very lightweight one which does take the
>> form of CSRF, but it is only the simplest example of a family of automated
>> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
>> same purpose in this case) would be enough here.
>
> Great. So we need to add explicit text about preventing CSRF attacks at the
> authorization endpoint.

General comment, not for this issue alone (and not specifically to the
folks conversing here):

There are a great many things we can say about threats and attacks,
which is why we have the threats document by Torsten, et al.  I'm
generally in favour of putting more security considerations into the
base document to describe threats that implementors need to be
concerned about, and well-crafted text that the editors can drop in is
a good thing.

That said, the reason we decided to put "highlights" into the base
doc's Security Considerations section, and then refer to the larger
document for more details and a more complete threat analysis is that
we wanted to strike a balance, keep the base doc for protocol details,
and leave the threat descriptions in the base doc as general threat
*classes*.

As we debate the various attack descriptions and mitigations that we
might like to add, please keep that balance in mind, and think
carefully about whether the details of *this specific* attack should
go into this document, or whether we just need to cover the general
class of threats here and put the details of this attack into
draft-ietf-oauth-v2-threatmodel.

Otherwise, we might eventually merge the entire threat analysis
document into the base, one paragraph at a time.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Barry Leiba]

The text for the answer below came from Mike, as the chairs asked for
at the IETF 81 meeting.  Mike, do you have a response to James's
issue?  Can we give a better response here?  Should the bearer doc
specify %-encoding explicitly?

Barry

On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H
 wrote:
>>> *    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.
>
>
> This is a poor answer.
> A client app receiving a scope value in an "WWW-Authenticate: Bearer 
> scope=..." response will either compare it with strings from a OAuth2 
> JSON-encoded token response, or copy it into a request to an authorization 
> server. It needs to know if it needs to %-decode the value or not before 
> doing these things. Clients cannot be expected to behave differently for 
> different servers in this respect.
>
> OAuth2 core (implicitly) allows a scope to use any Unicode char except space 
> (as space is used as a delimiter).
> Bearer restricts scopes to 93 ASCII chars.
> OMA are asking if this is intentional.
>
> If we really want to restrict scope values it would be better done in OAuth2 
> core.
> If we don't want to restrict values then the bearer spec needs to be able to 
> handle any possible scope value by defining an escaping mechanism for scope-v 
> (or by not having a scope parameter).
>
> --
> James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Niv Steingarten]

On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 10:16 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
> Can you provide another example with the same level of detail as you provided 
> below?

The malicious client sends a request to the authorization endpoint
with the appropriate parameters, and in return receives the markup of
the web-page which should be displayed to the user in order to get
consent. In addition, since the request is launched not via a
sandboxed user-agent, the client also has access to any 'Set-Cookie'
HTTP headers.

Instead of displaying the page to the user, the client extracts the
web-form data (including the hidden nonce/token) which would be
submitted when 'Allow' is clicked. It then forges the appropriate POST
request with the cookies, form data and referrer, and dispatches it,
to finally receive an access token/authorization code in the
redirection.


> CAPTCHA and password entry are two completely difference measures and are 
> rarely interchangeable. CAPTCHA does nothing more than increase the 
> likelihood that the entity on the other side is a human. Any attack prevented 
> by CAPTCHA must be one in which automation and speed are crucial. I still 
> don't understand what it *solves*.

CAPTCHAs are used for human testing and passwords for identity
testing, but in this case they both serve the same purpose of
decreasing the likelihood that the flow is automated.


> Two-factor authentication is good, but completely impractical for most web 
> authorization scenario. You need to remember that the authorization page is 
> used for both the initial grant, but also for delegated login (by far a more 
> frequent use). An access token can be issued almost automatically if the 
> client has been previously authorized.

You're right, sometimes there's a trade-off between better security
and user experience. I think it should eventually be up to the
implementer to choose what is right for their applications' security
requirements. I think it is in the scope of the specification to bring
this issue up for developers to consider.


> I don't understand this "family of attacks".

I don't know how to put it any differently than I already have; simply
a class of attacks (the three scenarios described in this thread are
examples thereof) in which a malicious client takes the role of both
the client and the resource owner.

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

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

[William J. Mills]

+1 for Jame's feedback here.  We need to solve this.




From: "Manger, James H" 
To: Barry Leiba ; "oauth@ietf.org" 
Sent: Thursday, August 18, 2011 4:15 AM
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v

>> *    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.


This is a poor answer.
A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." 
response will either compare it with strings from a OAuth2 JSON-encoded token 
response, or copy it into a request to an authorization server. It needs to 
know if it needs to %-decode the value or not before doing these things. 
Clients cannot be expected to behave differently for different servers in this 
respect.

OAuth2 core (implicitly) allows a scope to use any Unicode char except space 
(as space is used as a delimiter).
Bearer restricts scopes to 93 ASCII chars.
OMA are asking if this is intentional.

If we really want to restrict scope values it would be better done in OAuth2 
core.
If we don't want to restrict values then the bearer spec needs to be able to 
handle any possible scope value by defining an escaping mechanism for scope-v 
(or by not having a scope parameter).

--
James Manger

___
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 comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

> -Original Message-
> From: Niv Steingarten [mailto:nivst...@gmail.com]
> Sent: Thursday, August 18, 2011 11:08 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> Sent: Thursday, August 18, 2011 10:16 AM
> >> To: Eran Hammer-Lahav
> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> Impersonation)
> >>
> > Can you provide another example with the same level of detail as you
> provided below?
> 
> The malicious client sends a request to the authorization endpoint with the
> appropriate parameters, and in return receives the markup of the web-page
> which should be displayed to the user in order to get consent. In addition,
> since the request is launched not via a sandboxed user-agent, the client also
> has access to any 'Set-Cookie'
> HTTP headers.
> 
> Instead of displaying the page to the user, the client extracts the web-form
> data (including the hidden nonce/token) which would be submitted when
> 'Allow' is clicked. It then forges the appropriate POST request with the
> cookies, form data and referrer, and dispatches it,

SCENE MISSING [1]

> to finally receive an access token/authorization code in the redirection.

You skipped the best part!

What do you mean by "dispatches it"? How is the resource owner tricked or 
abused to grant authorization unknowingly? I understand how your proposal 
"fixes" the first half, but not what kind of attack is happening in the second 
half.

EHL

[1] http://www.ibras.dk/montypython/episode34.htm

___
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

[Barry Leiba]

> Chairs - please open an issue for this: "Clarifying reference to refresh 
> tokens
> in section 1.4.3 of -20".

http://trac.tools.ietf.org/wg/oauth/trac/ticket/25

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

Re: [OAUTH-WG] TLS 1.2

[Eran Hammer-Lahav]

> -Original Message-
> From: Rob Richards [mailto:rricha...@cdatazone.org]
> Sent: Tuesday, August 16, 2011 1:34 PM

> The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but
> at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY
> support additional transport-layer mechanisms meeting its security
> requirements.

How about:

The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 
1.2 ([RFC5246]) and its future replacements, and MAY support additional 
transport-layer mechanisms meeting its security requirements.

EHL

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

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

[Niv Steingarten]

On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 11:08 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav 
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> > Can you provide another example with the same level of detail as you
>> provided below?
>>
>> The malicious client sends a request to the authorization endpoint with the
>> appropriate parameters, and in return receives the markup of the web-page
>> which should be displayed to the user in order to get consent. In addition,
>> since the request is launched not via a sandboxed user-agent, the client also
>> has access to any 'Set-Cookie'
>> HTTP headers.
>>
>> Instead of displaying the page to the user, the client extracts the web-form
>> data (including the hidden nonce/token) which would be submitted when
>> 'Allow' is clicked. It then forges the appropriate POST request with the
>> cookies, form data and referrer, and dispatches it,
>
> SCENE MISSING [1]
>
>> to finally receive an access token/authorization code in the redirection.
>
> You skipped the best part!
>
> What do you mean by "dispatches it"? How is the resource owner tricked or 
> abused to grant authorization unknowingly? I understand how your proposal 
> "fixes" the first half, but not what kind of attack is happening in the 
> second half.
>

I might have accidentally skipped the part where the user is already
logged in at the authorization endpoint, so no log-in is required but
rather just allowing/denying access (correction: the first request is
sent using an HTTP framework/WebKit, so no access to cookies). Once it
extracts the data from the web-form, the client has all the
information it needs in order to create an HTTP request and launch it
using the same HTTP framework/WebKit, simulating the "Allow" button.

>
> [1] http://www.ibras.dk/montypython/episode34.htm
>

+1 for more Monty Python references.

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

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Niv Steingarten [mailto:nivst...@gmail.com]
> Sent: Thursday, August 18, 2011 12:12 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> Sent: Thursday, August 18, 2011 11:08 AM
> >> To: Eran Hammer-Lahav
> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> Impersonation)
> >>
> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
> >> 
> >> wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> >> Sent: Thursday, August 18, 2011 10:16 AM
> >> >> To: Eran Hammer-Lahav
> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> >> Impersonation)
> >> >>
> >> > Can you provide another example with the same level of detail as
> >> > you
> >> provided below?
> >>
> >> The malicious client sends a request to the authorization endpoint
> >> with the appropriate parameters, and in return receives the markup of
> >> the web-page which should be displayed to the user in order to get
> >> consent. In addition, since the request is launched not via a
> >> sandboxed user-agent, the client also has access to any 'Set-Cookie'
> >> HTTP headers.
> >>
> >> Instead of displaying the page to the user, the client extracts the
> >> web-form data (including the hidden nonce/token) which would be
> >> submitted when 'Allow' is clicked. It then forges the appropriate
> >> POST request with the cookies, form data and referrer, and dispatches
> >> it,
> >
> > SCENE MISSING [1]
> >
> >> to finally receive an access token/authorization code in the redirection.
> >
> > You skipped the best part!
> >
> > What do you mean by "dispatches it"? How is the resource owner tricked
> or abused to grant authorization unknowingly? I understand how your
> proposal "fixes" the first half, but not what kind of attack is happening in 
> the
> second half.
> >
> 
> I might have accidentally skipped the part where the user is already logged in
> at the authorization endpoint, so no log-in is required but rather just
> allowing/denying access (correction: the first request is sent using an HTTP
> framework/WebKit, so no access to cookies). Once it extracts the data from
> the web-form, the client has all the information it needs in order to create 
> an
> HTTP request 

No - the attacker does not have access to the session cookie. It still needs to 
find a way to make a CSS call.

> and launch it using the same HTTP framework/WebKit,
> simulating the "Allow" button.

This is still just a CSRF attack.

In order to automate the approval action, they attacker has to get the 
user-agent (embedded or not) to make a cross site request which will include 
some session state (cookies or otherwise). If the authorization page is CSRF 
protected, they attacker will not be able to construct such a link.

The nature of the client does not matter. In either case, the client has to 
gain access somehow to the authorization server state stored in the browser.

EHL

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

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

[William J. Mills]

This is, in my opinion, another style of CSRF.  I the attacker present your 
browser (user agent) with a link, and your browser presents a credential 
automatically to the token endpoint, which automatically issues a token to be 
given back to me?  That's a classic CSRF, how to fix it is interesting.  I'm of 
the opinion that the user *should* be pesented with some UI at that point so 
they can make an informed choice about issuing a credential.  Not everyone 
agrees with me though (mostly business folks that want to avoid user 
interaction because it's too scary  and somehow informing the user what 
they are doign is a bad thing).

-bill




From: Niv Steingarten 
To: Eran Hammer-Lahav 
Cc: "oauth@ietf.org" 
Sent: Thursday, August 18, 2011 12:11 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 11:08 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav 
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> > Can you provide another example with the same level of detail as you
>> provided below?
>>
>> The malicious client sends a request to the authorization endpoint with the
>> appropriate parameters, and in return receives the markup of the web-page
>> which should be displayed to the user in order to get consent. In addition,
>> since the request is launched not via a sandboxed user-agent, the client also
>> has access to any 'Set-Cookie'
>> HTTP headers.
>>
>> Instead of displaying the page to the user, the client extracts the web-form
>> data (including the hidden nonce/token) which would be submitted when
>> 'Allow' is clicked. It then forges the appropriate POST request with the
>> cookies, form data and referrer, and dispatches it,
>
> SCENE MISSING [1]
>
>> to finally receive an access token/authorization code in the redirection.
>
> You skipped the best part!
>
> What do you mean by "dispatches it"? How is the resource owner tricked or 
> abused to grant authorization unknowingly? I understand how your proposal 
> "fixes" the first half, but not what kind of attack is happening in the 
> second half.
>

I might have accidentally skipped the part where the user is already
logged in at the authorization endpoint, so no log-in is required but
rather just allowing/denying access (correction: the first request is
sent using an HTTP framework/WebKit, so no access to cookies). Once it
extracts the data from the web-form, the client has all the
information it needs in order to create an HTTP request and launch it
using the same HTTP framework/WebKit, simulating the "Allow" button.

>
> [1] http://www.ibras.dk/montypython/episode34.htm
>

+1 for more Monty Python references.

-- Niv
___
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 comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

We know how to fix CSRF attacks on form submission which this is. The UI 
questions about more about legitimate client interaction and how informed a 
user should be.

EHL

From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, August 18, 2011 12:27 PM
To: Niv Steingarten; Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

This is, in my opinion, another style of CSRF.  I the attacker present your 
browser (user agent) with a link, and your browser presents a credential 
automatically to the token endpoint, which automatically issues a token to be 
given back to me?  That's a classic CSRF, how to fix it is interesting.  I'm of 
the opinion that the user *should* be pesented with some UI at that point so 
they can make an informed choice about issuing a credential.  Not everyone 
agrees with me though (mostly business folks that want to avoid user 
interaction because it's too scary  and somehow informing the user what 
they are doign is a bad thing).

-bill


From: Niv Steingarten mailto:nivst...@gmail.com>>
To: Eran Hammer-Lahav mailto:e...@hueniverse.com>>
Cc: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
Sent: Thursday, August 18, 2011 12:11 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav 
mailto:e...@hueniverse.com>> wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 11:08 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav 
>> mailto:e...@hueniverse.com>>
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten 
>> >> [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> > Can you provide another example with the same level of detail as you
>> provided below?
>>
>> The malicious client sends a request to the authorization endpoint with the
>> appropriate parameters, and in return receives the markup of the web-page
>> which should be displayed to the user in order to get consent. In addition,
>> since the request is launched not via a sandboxed user-agent, the client also
>> has access to any 'Set-Cookie'
>> HTTP headers.
>>
>> Instead of displaying the page to the user, the client extracts the web-form
>> data (including the hidden nonce/token) which would be submitted when
>> 'Allow' is clicked. It then forges the appropriate POST request with the
>> cookies, form data and referrer, and dispatches it,
>
> SCENE MISSING [1]
>
>> to finally receive an access token/authorization code in the redirection.
>
> You skipped the best part!
>
> What do you mean by "dispatches it"? How is the resource owner tricked or 
> abused to grant authorization unknowingly? I understand how your proposal 
> "fixes" the first half, but not what kind of attack is happening in the 
> second half.
>

I might have accidentally skipped the part where the user is already
logged in at the authorization endpoint, so no log-in is required but
rather just allowing/denying access (correction: the first request is
sent using an HTTP framework/WebKit, so no access to cookies). Once it
extracts the data from the web-form, the client has all the
information it needs in order to create an HTTP request and launch it
using the same HTTP framework/WebKit, simulating the "Allow" button.

>
> [1] http://www.ibras.dk/montypython/episode34.htm
>

+1 for more Monty Python references.

-- Niv
___
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] TLS 1.2

[Rob Richards]

On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote:

-Original Message-
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Tuesday, August 16, 2011 1:34 PM
The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but
at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY
support additional transport-layer mechanisms meeting its security
requirements.

How about:

The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 
1.2 ([RFC5246]) and its future replacements, and MAY support additional 
transport-layer mechanisms meeting its security requirements.

EHL




That works

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

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

[Niv Steingarten]

On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 12:12 PM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav 
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 11:08 AM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>> >> 
>> >> wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> >> To: Eran Hammer-Lahav
>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> >> Impersonation)
>> >> >>
>> >> > Can you provide another example with the same level of detail as
>> >> > you
>> >> provided below?
>> >>
>> >> The malicious client sends a request to the authorization endpoint
>> >> with the appropriate parameters, and in return receives the markup of
>> >> the web-page which should be displayed to the user in order to get
>> >> consent. In addition, since the request is launched not via a
>> >> sandboxed user-agent, the client also has access to any 'Set-Cookie'
>> >> HTTP headers.
>> >>
>> >> Instead of displaying the page to the user, the client extracts the
>> >> web-form data (including the hidden nonce/token) which would be
>> >> submitted when 'Allow' is clicked. It then forges the appropriate
>> >> POST request with the cookies, form data and referrer, and dispatches
>> >> it,
>> >
>> > SCENE MISSING [1]
>> >
>> >> to finally receive an access token/authorization code in the redirection.
>> >
>> > You skipped the best part!
>> >
>> > What do you mean by "dispatches it"? How is the resource owner tricked
>> or abused to grant authorization unknowingly? I understand how your
>> proposal "fixes" the first half, but not what kind of attack is happening in 
>> the
>> second half.
>> >
>>
>> I might have accidentally skipped the part where the user is already logged 
>> in
>> at the authorization endpoint, so no log-in is required but rather just
>> allowing/denying access (correction: the first request is sent using an HTTP
>> framework/WebKit, so no access to cookies). Once it extracts the data from
>> the web-form, the client has all the information it needs in order to create 
>> an
>> HTTP request
>
> No - the attacker does not have access to the session cookie. It still needs 
> to find a way to make a CSS call.
>

That's what I said -- "no access to cookies". But since both requests
(the one requesting the auth endpoint and the one simulating the
"allow") are sent from the same user-agent, the cookies are handled by
the user-agent itself. The client just POSTs the request with the
appropriate parameters to the action endpoint of the form.

>> and launch it using the same HTTP framework/WebKit,
>> simulating the "Allow" button.
>
> This is still just a CSRF attack.
>

I think you may be right. I still believe this particular style of
attack on the authorization server is worth mentioning, be it in its
own separate section or under the existing CSRF section (as you
suggested).

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

Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Lu, Hui-Lan (Huilan)]

Eran Hammer-Lahav wrote:
> Added to 2.4.1:
> 
> client_secret
> REQUIRED. The client secret. The client MAY omit the 
> parameter if the
> client secret
> is an empty string.

I would suggest rewording the above as follows:
client_secret 
REQUIRED unless it is an empty string. The client secret.

> Added to 3.2.1:
> 
> A public client that was not issued a client password MAY use the
> 'client_id' request parameter to identify itself when sending
> requests to the token endpoint.

It is difficult to parse the last sentence of 3.2.1: "The security 
ramifications of allowing unauthenticated access by public clients to the token 
endpoint MUST be considered, as well as the issuance of refresh tokens to 
public clients, their scope, and lifetime."

I think it should be rewritten and reference relevant parts of security 
considerations.

Huilan


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

Re: [OAUTH-WG] TLS 1.2

[Lu, Hui-Lan (Huilan)]

+1

Huilan


> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Rob
> Richards
> Sent: Thursday, August 18, 2011 3:46 PM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] TLS 1.2
> 
> On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote:
> >> -Original Message-
> >> From: Rob Richards [mailto:rricha...@cdatazone.org]
> >> Sent: Tuesday, August 16, 2011 1:34 PM
> >> The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but
> >> at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY
> >> support additional transport-layer mechanisms meeting its security
> >> requirements.
> > How about:
> >
> > The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support 
> > TLS
> 1.2 ([RFC5246]) and its future replacements, and MAY support additional 
> transport-
> layer mechanisms meeting its security requirements.
> >
> > EHL
> >
> >
> 
> That works
> 
> Rob
> ___
> 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 comment (Resource Owner Impersonation)

[Eran Hammer-Lahav]

> -Original Message-
> From: Niv Steingarten [mailto:nivst...@gmail.com]
> Sent: Thursday, August 18, 2011 1:04 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> Sent: Thursday, August 18, 2011 12:12 PM
> >> To: Eran Hammer-Lahav
> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> Impersonation)
> >>
> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
> >> 
> >> wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> >> Sent: Thursday, August 18, 2011 11:08 AM
> >> >> To: Eran Hammer-Lahav
> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> >> Impersonation)
> >> >>
> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
> >> >> 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
> >> >> >> To: Eran Hammer-Lahav
> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
> >> >> >> Owner
> >> >> >> Impersonation)
> >> >> >>
> >> >> > Can you provide another example with the same level of detail as
> >> >> > you
> >> >> provided below?
> >> >>
> >> >> The malicious client sends a request to the authorization endpoint
> >> >> with the appropriate parameters, and in return receives the markup
> >> >> of the web-page which should be displayed to the user in order to
> >> >> get consent. In addition, since the request is launched not via a
> >> >> sandboxed user-agent, the client also has access to any 'Set-Cookie'
> >> >> HTTP headers.
> >> >>
> >> >> Instead of displaying the page to the user, the client extracts
> >> >> the web-form data (including the hidden nonce/token) which would
> >> >> be submitted when 'Allow' is clicked. It then forges the
> >> >> appropriate POST request with the cookies, form data and referrer,
> >> >> and dispatches it,
> >> >
> >> > SCENE MISSING [1]
> >> >
> >> >> to finally receive an access token/authorization code in the 
> >> >> redirection.
> >> >
> >> > You skipped the best part!
> >> >
> >> > What do you mean by "dispatches it"? How is the resource owner
> >> > tricked
> >> or abused to grant authorization unknowingly? I understand how your
> >> proposal "fixes" the first half, but not what kind of attack is
> >> happening in the second half.
> >> >
> >>
> >> I might have accidentally skipped the part where the user is already
> >> logged in at the authorization endpoint, so no log-in is required but
> >> rather just allowing/denying access (correction: the first request is
> >> sent using an HTTP framework/WebKit, so no access to cookies). Once
> >> it extracts the data from the web-form, the client has all the
> >> information it needs in order to create an HTTP request
> >
> > No - the attacker does not have access to the session cookie. It still needs
> to find a way to make a CSS call.
> >
> 
> That's what I said -- "no access to cookies".

You only said that about the first request.

> But since both requests (the one
> requesting the auth endpoint and the one simulating the
> "allow") are sent from the same user-agent, the cookies are handled by the
> user-agent itself. The client just POSTs the request with the appropriate
> parameters to the action endpoint of the form.

That's not exactly right.

This entire attack is based on:

1. The presence of some session cookie or other user-agent state to bypass 
active authentication, and
2. The ability of the malicious client to make CSS calls using #1.

Everything else is a red herring because the ability to automate this attack 
and make it more powerful is completely beside the point. If you deploy an 
effective CSRF protection, everything else is a non-issue.

This is why the client type does not matter when it comes to not using CORS. 
The authorization server MUST NOT allow CSS calls on the authorization endpoint 
because that's the actual attack you described - using local state (session 
cookie) to make a CSS call. If the client makes direct calls to the 
authorization endpoint, it cannot impersonate the resource owner.

> >> and launch it using the same HTTP framework/WebKit, simulating the
> >> "Allow" button.
> >
> > This is still just a CSRF attack.
> >
> 
> I think you may be right. I still believe this particular style of attack on 
> the
> authorization server is worth mentioning, be it in its own separate section or
> under the existing CSRF section (as you suggested).

This is not a style of attack but techniques to enhance oth

Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Eran Hammer-Lahav]

> -Original Message-
> From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com]
> Sent: Thursday, August 18, 2011 1:45 PM
> To: Eran Hammer-Lahav; Brian Campbell
> Cc: oauth
> Subject: RE: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> Eran Hammer-Lahav wrote:
> > Added to 2.4.1:
> >
> > client_secret
> > REQUIRED. The client secret. The client MAY omit the
> > parameter if the client secret
> > is an empty string.
> 
> I would suggest rewording the above as follows:
> client_secret
>   REQUIRED unless it is an empty string. The client secret.

"unless its value is an empty string". Do people read this new text to mean 
OPTIONAL if not empty?

> > Added to 3.2.1:
> >
> > A public client that was not issued a client password MAY use 
> > the
> > 'client_id' request parameter to identify itself when sending
> > requests to the token endpoint.
> 
> It is difficult to parse the last sentence of 3.2.1: "The security 
> ramifications of
> allowing unauthenticated access by public clients to the token endpoint
> MUST be considered, as well as the issuance of refresh tokens to public
> clients, their scope, and lifetime."
> 
> I think it should be rewritten and reference relevant parts of security
> considerations.

Text?

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

[OAUTH-WG] [oauth] #24: Resource Owner Impersonation

[oauth issue tracker]

#24: Resource Owner Impersonation

 See discussion thread beginning here:
 http://www.ietf.org/mail-archive/web/oauth/current/msg07225.html

 Torsten proposes text that describes the attack and suggests defenses.

-- 
-+--
 Reporter:  barryleiba@… |   Owner:
 Type:  defect   |  Status:  new   
 Priority:  major|   Milestone:  Deliver OAuth 2.0 spec
Component:  v2   | Version:
 Severity:  Active WG Document   |Keywords:
-+--

Ticket URL: 
oauth 

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

Re: [OAUTH-WG] [oauth] #22: WG last call complete; waiting for new revision (was: In final review before WG last call)

[oauth issue tracker]

#22: WG last call complete; waiting for new revision

Changes (by barryleiba@…):

  * severity:  Active WG Document => In WG Last Call


-- 
-+--
 Reporter:  barryleiba@… |   Owner:  barryleiba@…   
 Type:  state|  Status:  assigned   
 Priority:  information  |   Milestone:  Deliver OAuth 2.0 spec 
Component:  v2   | Version: 
 Severity:  In WG Last Call  |Keywords: 
-+--

Ticket URL: 
oauth 

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

[OAUTH-WG] [oauth] #25: Clarifying reference to refresh tokens in section 1.4.3 of -20

[oauth issue tracker]

#25: Clarifying reference to refresh tokens in section 1.4.3 of -20

 See discussion thread beginning here:
 http://www.ietf.org/mail-archive/web/oauth/current/msg07309.html

 Yaron brings up a point in his review, to which Eran responds with a
 suggestion of removing "(when combined with a refresh token)".  Several
 objections are raised to the removal.

 Eran proposes an alternative here:
 http://www.ietf.org/mail-archive/web/oauth/current/msg07322.html

-- 
-+--
 Reporter:  barryleiba@… |   Owner:
 Type:  defect   |  Status:  new   
 Priority:  major|   Milestone:  Deliver OAuth 2.0 spec
Component:  v2   | Version:
 Severity:  Active WG Document   |Keywords:
-+--

Ticket URL: 
oauth 

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

Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Brian Campbell]

FWIW, I was okay with the text EHL had originally proposed for 21.

>> > client_secret
>> >                 REQUIRED. The client secret. The client MAY omit the
>> > parameter if the client secret
>> >                 is an empty string.
>>
>> I would suggest rewording the above as follows:
>> client_secret
>>       REQUIRED unless it is an empty string. The client secret.
>
> "unless its value is an empty string". Do people read this new text to mean 
> OPTIONAL if not empty?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Lu, Hui-Lan (Huilan)]

> > It is difficult to parse the last sentence of 3.2.1: "The security 
> > ramifications of
> > allowing unauthenticated access by public clients to the token endpoint
> > MUST be considered, as well as the issuance of refresh tokens to public
> > clients, their scope, and lifetime."
> >
> > I think it should be rewritten and reference relevant parts of security
> > considerations.
> 
> Text?
> 
> EHL

Here is my stab:
Allowing unauthenticated access by public clients has security ramifications. 
So does the issuance of refresh tokens to public clients. Such security 
ramifications MUST be considered. See section 10 for further details.

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

Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Lu, Hui-Lan (Huilan)]

I just noticed that some words were missing in my previous post. Here is the 
full text that Eran requested:

Allowing unauthenticated access to the token endpoint by public clients has 
security ramifications. So does
issuing refresh tokens to public clients. Such security ramifications MUST be 
considered. See section 10 for further details.

Huilan


> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lu,
> Hui-Lan (Huilan)
> Sent: Thursday, August 18, 2011 5:47 PM
> To: 'Eran Hammer-Lahav'; Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and 
> identification
> 
> > > It is difficult to parse the last sentence of 3.2.1: "The security 
> > > ramifications of
> > > allowing unauthenticated access by public clients to the token endpoint
> > > MUST be considered, as well as the issuance of refresh tokens to public
> > > clients, their scope, and lifetime."
> > >
> > > I think it should be rewritten and reference relevant parts of security
> > > considerations.
> >
> > Text?
> >
> > EHL
> 
> Here is my stab:
> Allowing unauthenticated access by public clients has security ramifications. 
> So does
> the issuance of refresh tokens to public clients. Such security ramifications 
> MUST be
> considered. See section 10 for further details.
> 
> Huilan
> ___
> 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 comment (Resource Owner Impersonation)

[Niv Steingarten]

How about add something like this as the second paragraph in 10.12:

   The authorization server SHOULD employ measures to prevent CSRF
   attacks on the authorization endpoint. A non-guessable token SHOULD
   be included in requests and form submissions within the authorization
   server's internal authorization flow. This token MUST NOT be
   accessible by the client. In addition, the authorization server may
   make use of HTTP referrer headers in order to verify the origin of
   requests made during the authorization flow.

In addition, I think that:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks, ...

should be changed to:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks against the client's redirection URI, ...

so that the fact that the 'state' parameter protects against CSRF
attacks on the *client*, as opposed to CSRF on the *authorization
server*, is made explicit.

-- Niv


On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 1:04 PM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 12:12 PM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>> >> 
>> >> wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>> >> >> To: Eran Hammer-Lahav
>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> >> Impersonation)
>> >> >>
>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>> >> >> 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> >> -Original Message-
>> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> >> >> To: Eran Hammer-Lahav
>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
>> >> >> >> Owner
>> >> >> >> Impersonation)
>> >> >> >>
>> >> >> > Can you provide another example with the same level of detail as
>> >> >> > you
>> >> >> provided below?
>> >> >>
>> >> >> The malicious client sends a request to the authorization endpoint
>> >> >> with the appropriate parameters, and in return receives the markup
>> >> >> of the web-page which should be displayed to the user in order to
>> >> >> get consent. In addition, since the request is launched not via a
>> >> >> sandboxed user-agent, the client also has access to any 'Set-Cookie'
>> >> >> HTTP headers.
>> >> >>
>> >> >> Instead of displaying the page to the user, the client extracts
>> >> >> the web-form data (including the hidden nonce/token) which would
>> >> >> be submitted when 'Allow' is clicked. It then forges the
>> >> >> appropriate POST request with the cookies, form data and referrer,
>> >> >> and dispatches it,
>> >> >
>> >> > SCENE MISSING [1]
>> >> >
>> >> >> to finally receive an access token/authorization code in the 
>> >> >> redirection.
>> >> >
>> >> > You skipped the best part!
>> >> >
>> >> > What do you mean by "dispatches it"? How is the resource owner
>> >> > tricked
>> >> or abused to grant authorization unknowingly? I understand how your
>> >> proposal "fixes" the first half, but not what kind of attack is
>> >> happening in the second half.
>> >> >
>> >>
>> >> I might have accidentally skipped the part where the user is already
>> >> logged in at the authorization endpoint, so no log-in is required but
>> >> rather just allowing/denying access (correction: the first request is
>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once
>> >> it extracts the data from the web-form, the client has all the
>> >> information it needs in order to create an HTTP request
>> >
>> > No - the attacker does not have access to the session cookie. It still 
>> > needs
>> to find a way to make a CSS call.
>> >
>>
>> That's what I said -- "no access to cookies".
>
> You only said that about the first request.
>
>> But since both requests (the one
>> requesting the auth endpoint and the one simulating the
>> "allow") are sent from the same user-agent, the cookies are handled by the
>> user-agent itself. The client just POSTs the request with the appropriate
>> parameters to the action endpoint of the form.
>
> That's not exactly right.
>
> This entire attack is based on:
>
> 1. The presence of some session cookie

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

[William J. Mills]

I proposed text that I think is more complete in a previous message...




From: Niv Steingarten 
To: Eran Hammer-Lahav 
Cc: "oauth@ietf.org" 
Sent: Thursday, August 18, 2011 4:33 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

How about add something like this as the second paragraph in 10.12:

   The authorization server SHOULD employ measures to prevent CSRF
   attacks on the authorization endpoint. A non-guessable token SHOULD
   be included in requests and form submissions within the authorization
   server's internal authorization flow. This token MUST NOT be
   accessible by the client. In addition, the authorization server may
   make use of HTTP referrer headers in order to verify the origin of
   requests made during the authorization flow.

In addition, I think that:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks, ...

should be changed to:

   The "state" request parameter SHOULD be used to mitigate against CSRF
   attacks against the client's redirection URI, ...

so that the fact that the 'state' parameter protects against CSRF
attacks on the *client*, as opposed to CSRF on the *authorization
server*, is made explicit.

-- Niv


On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav  wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 1:04 PM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> Sent: Thursday, August 18, 2011 12:12 PM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> Impersonation)
>> >>
>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>> >> 
>> >> wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>> >> >> To: Eran Hammer-Lahav
>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >> >> Impersonation)
>> >> >>
>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>> >> >> 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> >> -Original Message-
>> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>> >> >> >> To: Eran Hammer-Lahav
>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
>> >> >> >> Owner
>> >> >> >> Impersonation)
>> >> >> >>
>> >> >> > Can you provide another example with the same level of detail as
>> >> >> > you
>> >> >> provided below?
>> >> >>
>> >> >> The malicious client sends a request to the authorization endpoint
>> >> >> with the appropriate parameters, and in return receives the markup
>> >> >> of the web-page which should be displayed to the user in order to
>> >> >> get consent. In addition, since the request is launched not via a
>> >> >> sandboxed user-agent, the client also has access to any 'Set-Cookie'
>> >> >> HTTP headers.
>> >> >>
>> >> >> Instead of displaying the page to the user, the client extracts
>> >> >> the web-form data (including the hidden nonce/token) which would
>> >> >> be submitted when 'Allow' is clicked. It then forges the
>> >> >> appropriate POST request with the cookies, form data and referrer,
>> >> >> and dispatches it,
>> >> >
>> >> > SCENE MISSING [1]
>> >> >
>> >> >> to finally receive an access token/authorization code in the 
>> >> >> redirection.
>> >> >
>> >> > You skipped the best part!
>> >> >
>> >> > What do you mean by "dispatches it"? How is the resource owner
>> >> > tricked
>> >> or abused to grant authorization unknowingly? I understand how your
>> >> proposal "fixes" the first half, but not what kind of attack is
>> >> happening in the second half.
>> >> >
>> >>
>> >> I might have accidentally skipped the part where the user is already
>> >> logged in at the authorization endpoint, so no log-in is required but
>> >> rather just allowing/denying access (correction: the first request is
>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once
>> >> it extracts the data from the web-form, the client has all the
>> >> information it needs in order to create an HTTP request
>> >
>> > No - the attacker does not have access to the session cookie. It still 
>> > needs
>> to find a way to make a CSS call.
>> >
>>
>> That's what I said -- "no access to cookies".
>
> You only said that about the first request.
>
>> But since both requests (the one
>> requesting the auth endpoint and the one simulating the
>> "allow") ar

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

[Niv Steingarten]

I suppose you're talking about this:
http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is indeed more complete w.r.t. CSRF attacks on the client's
redirection URI, but it does not address CSRF attacks on the
authorization server.

I believe something along the lines of the text I proposed could be
combined in whichever text is eventually decided upon.

-- Niv


On Fri, Aug 19, 2011 at 02:46, William J. Mills  wrote:
> I proposed text that I think is more complete in a previous message...
> 
> From: Niv Steingarten 
> To: Eran Hammer-Lahav 
> Cc: "oauth@ietf.org" 
> Sent: Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
>
> How about add something like this as the second paragraph in 10.12:
>
>   The authorization server SHOULD employ measures to prevent CSRF
>   attacks on the authorization endpoint. A non-guessable token SHOULD
>   be included in requests and form submissions within the authorization
>   server's internal authorization flow. This token MUST NOT be
>   accessible by the client. In addition, the authorization server may
>   make use of HTTP referrer headers in order to verify the origin of
>   requests made during the authorization flow.
>
> In addition, I think that:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks, ...
>
> should be changed to:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks against the client's redirection URI, ...
>
> so that the fact that the 'state' parameter protects against CSRF
> attacks on the *client*, as opposed to CSRF on the *authorization
> server*, is made explicit.
>
> -- Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav 
> wrote:
>>
>>
>>> -Original Message-
>>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> Sent: Thursday, August 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
>>> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> Impersonation)
>>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
>>> wrote:
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> Sent: Thursday, August 18, 2011 12:12 PM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> Impersonation)
>>> >>
>>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>>> >> 
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>>> >> >> To: Eran Hammer-Lahav
>>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> >> Impersonation)
>>> >> >>
>>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>> >> >> 
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >> -Original Message-
>>> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>>> >> >> >> To: Eran Hammer-Lahav
>>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
>>> >> >> >> Owner
>>> >> >> >> Impersonation)
>>> >> >> >>
>>> >> >> > Can you provide another example with the same level of detail as
>>> >> >> > you
>>> >> >> provided below?
>>> >> >>
>>> >> >> The malicious client sends a request to the authorization endpoint
>>> >> >> with the appropriate parameters, and in return receives the markup
>>> >> >> of the web-page which should be displayed to the user in order to
>>> >> >> get consent. In addition, since the request is launched not via a
>>> >> >> sandboxed user-agent, the client also has access to any
>>> >> >> 'Set-Cookie'
>>> >> >> HTTP headers.
>>> >> >>
>>> >> >> Instead of displaying the page to the user, the client extracts
>>> >> >> the web-form data (including the hidden nonce/token) which would
>>> >> >> be submitted when 'Allow' is clicked. It then forges the
>>> >> >> appropriate POST request with the cookies, form data and referrer,
>>> >> >> and dispatches it,
>>> >> >
>>> >> > SCENE MISSING [1]
>>> >> >
>>> >> >> to finally receive an access token/authorization code in the
>>> >> >> redirection.
>>> >> >
>>> >> > You skipped the best part!
>>> >> >
>>> >> > What do you mean by "dispatches it"? How is the resource owner
>>> >> > tricked
>>> >> or abused to grant authorization unknowingly? I understand how your
>>> >> proposal "fixes" the first half, but not what kind of attack is
>>> >> happening in the second half.
>>> >> >
>>> >>
>>> >> I might have accidentally skipped the part where the user is already
>>> >> logged in at the authorization endpoint, so no log-in is required but
>>> >> rather just allowing/denying access (co

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

[William J. Mills]

While I agree in principal, I think there are real world use cases that make 
this more complicated.  If, for example, a user has previously approved access 
to a particular endpoint then we might be willing to re-issue credentials 
without user interaction.  I don't know how we capture this in the right way in 
the spec.




From: Niv Steingarten 
To: William J. Mills 
Cc: Eran Hammer-Lahav ; "oauth@ietf.org" 
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

I suppose you're talking about this:
http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is indeed more complete w.r.t. CSRF attacks on the client's
redirection URI, but it does not address CSRF attacks on the
authorization server.

I believe something along the lines of the text I proposed could be
combined in whichever text is eventually decided upon.

-- Niv


On Fri, Aug 19, 2011 at 02:46, William J. Mills  wrote:
> I proposed text that I think is more complete in a previous message...
> 
> From: Niv Steingarten 
> To: Eran Hammer-Lahav 
> Cc: "oauth@ietf.org" 
> Sent: Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
>
> How about add something like this as the second paragraph in 10.12:
>
>   The authorization server SHOULD employ measures to prevent CSRF
>   attacks on the authorization endpoint. A non-guessable token SHOULD
>   be included in requests and form submissions within the authorization
>   server's internal authorization flow. This token MUST NOT be
>   accessible by the client. In addition, the authorization server may
>   make use of HTTP referrer headers in order to verify the origin of
>   requests made during the authorization flow.
>
> In addition, I think that:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks, ...
>
> should be changed to:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks against the client's redirection URI, ...
>
> so that the fact that the 'state' parameter protects against CSRF
> attacks on the *client*, as opposed to CSRF on the *authorization
> server*, is made explicit.
>
> -- Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav 
> wrote:
>>
>>
>>> -Original Message-
>>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> Sent: Thursday, August 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
>>> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> Impersonation)
>>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
>>> wrote:
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> Sent: Thursday, August 18, 2011 12:12 PM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> Impersonation)
>>> >>
>>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>>> >> 
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>>> >> >> To: Eran Hammer-Lahav
>>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> >> Impersonation)
>>> >> >>
>>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>> >> >> 
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >> -Original Message-
>>> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>>> >> >> >> To: Eran Hammer-Lahav
>>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
>>> >> >> >> Owner
>>> >> >> >> Impersonation)
>>> >> >> >>
>>> >> >> > Can you provide another example with the same level of detail as
>>> >> >> > you
>>> >> >> provided below?
>>> >> >>
>>> >> >> The malicious client sends a request to the authorization endpoint
>>> >> >> with the appropriate parameters, and in return receives the markup
>>> >> >> of the web-page which should be displayed to the user in order to
>>> >> >> get consent. In addition, since the request is launched not via a
>>> >> >> sandboxed user-agent, the client also has access to any
>>> >> >> 'Set-Cookie'
>>> >> >> HTTP headers.
>>> >> >>
>>> >> >> Instead of displaying the page to the user, the client extracts
>>> >> >> the web-form data (including the hidden nonce/token) which would
>>> >> >> be submitted when 'Allow' is clicked. It then forges the
>>> >> >> appropriate POST request with the cookies, form data and referrer,
>>> >> >> and dispatches it,
>>> >> >
>>> >> > SCENE MISSING [1]
>>> >> >
>>> >> >> to finally receive an access token/authorization code 

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

[Eran Hammer-Lahav]

To reiterate Berry's earlier point, we are not going to cover everything in the 
v2 spec. We need to agree on new language for the CSRF section, and add the 
potential attacks on both endpoints. But beyond that, it will probably be best 
to add it to the threat model document - but I will leave that up to the 
editors of that document.

EHL

From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Thursday, August 18, 2011 9:21 PM
To: Niv Steingarten
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

While I agree in principal, I think there are real world use cases that make 
this more complicated.  If, for example, a user has previously approved access 
to a particular endpoint then we might be willing to re-issue credentials 
without user interaction.  I don't know how we capture this in the right way in 
the spec.


From: Niv Steingarten mailto:nivst...@gmail.com>>
To: William J. Mills mailto:wmi...@yahoo-inc.com>>
Cc: Eran Hammer-Lahav mailto:e...@hueniverse.com>>; 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner 
Impersonation)

I suppose you're talking about this:
http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is indeed more complete w.r.t. CSRF attacks on the client's
redirection URI, but it does not address CSRF attacks on the
authorization server.

I believe something along the lines of the text I proposed could be
combined in whichever text is eventually decided upon.

-- Niv


On Fri, Aug 19, 2011 at 02:46, William J. Mills 
mailto:wmi...@yahoo-inc.com>> wrote:
> I proposed text that I think is more complete in a previous message...
> 
> From: Niv Steingarten mailto:nivst...@gmail.com>>
> To: Eran Hammer-Lahav mailto:e...@hueniverse.com>>
> Cc: "oauth@ietf.org" 
> mailto:oauth@ietf.org>>
> Sent: Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
>
> How about add something like this as the second paragraph in 10.12:
>
>   The authorization server SHOULD employ measures to prevent CSRF
>   attacks on the authorization endpoint. A non-guessable token SHOULD
>   be included in requests and form submissions within the authorization
>   server's internal authorization flow. This token MUST NOT be
>   accessible by the client. In addition, the authorization server may
>   make use of HTTP referrer headers in order to verify the origin of
>   requests made during the authorization flow.
>
> In addition, I think that:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks, ...
>
> should be changed to:
>
>   The "state" request parameter SHOULD be used to mitigate against CSRF
>   attacks against the client's redirection URI, ...
>
> so that the fact that the 'state' parameter protects against CSRF
> attacks on the *client*, as opposed to CSRF on the *authorization
> server*, is made explicit.
>
> -- Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav 
> mailto:e...@hueniverse.com>>
> wrote:
>>
>>
>>> -Original Message-
>>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>>> Sent: Thursday, August 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
>>> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> Impersonation)
>>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav 
>>> mailto:e...@hueniverse.com>>
>>> wrote:
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Niv Steingarten 
>>> >> [mailto:nivst...@gmail.com]
>>> >> Sent: Thursday, August 18, 2011 12:12 PM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> Impersonation)
>>> >>
>>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>>> >> mailto:e...@hueniverse.com>>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Niv Steingarten 
>>> >> >> [mailto:nivst...@gmail.com]
>>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>>> >> >> To: Eran Hammer-Lahav
>>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>>> >> >> Impersonation)
>>> >> >>
>>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>> >> >> mailto:e...@hueniverse.com>>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >> -Original Message-
>>> >> >> >> From: Niv Steingarten 
>>> >> >> >> [mailto:nivst...@gmail.com]
>>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM
>>> >> >> >> To: Eran Hammer-Lahav
>>>