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 tha
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
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
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 interna
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
c
> > 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 thi
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:
>> clie
#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
#22: WG last call complete; waiting for new revision
Changes (by barryleiba@…):
* severity: Active WG Document => In WG Last Call
--
-+--
Reporter: barryleiba@… | Owner: barryleiba@…
#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.
--
-+--
Rep
> -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-L
> -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, 2
+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 wr
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 i
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 ca
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],
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
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 interestin
> -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,
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 ca
> -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 trans
> 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
> -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,
+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 th
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 ca
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:
>
>> 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. S
> 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: t
> -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
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: [O
+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;
(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 eno
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 is
> -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 pr
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
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)
>
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
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 obj
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://ww
> >> 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 To
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 red
>> *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
>> 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 previo
>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
+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
>> 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,
Authoriz
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: Era
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...@telek
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
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;
51 matches
Mail list logo
