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

Igor Faynberg <> Thu, 18 August 2011 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7CF221F8B5F for <>; Thu, 18 Aug 2011 08:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.424
X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id slHP0EG9Lk6D for <>; Thu, 18 Aug 2011 08:48:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EEA3721F8B53 for <>; Thu, 18 Aug 2011 08:48:37 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id p7IFnV3l015023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Thu, 18 Aug 2011 10:49:31 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id p7IFnVre010230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Thu, 18 Aug 2011 10:49:31 -0500
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id p7IFnTqs021791; Thu, 18 Aug 2011 10:49:30 -0500 (CDT)
Message-ID: <>
Date: Thu, 18 Aug 2011 11:49:28 -0400
From: Igor Faynberg <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2011 15:48:39 -0000

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


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.
>> -----Original Message-----
>> From: [] On Behalf
>> Of Torsten Lodderstedt
>> Sent: Friday, August 12, 2011 7:56 AM
>> To:
>> 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.<to be determined>  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 mailing list
> _______________________________________________
> OAuth mailing list