Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management

Justin Richer <jricher@mit.edu> Sat, 04 April 2015 11:14 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD931B2AE9 for <oauth@ietfa.amsl.com>; Sat, 4 Apr 2015 04:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF1QN8_3JE0I for <oauth@ietfa.amsl.com>; Sat, 4 Apr 2015 04:14:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD5F1A8752 for <oauth@ietf.org>; Sat, 4 Apr 2015 04:14:49 -0700 (PDT)
X-AuditID: 1209190d-f79676d000000da0-28-551fc7a8cde0
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.38.03488.8A7CF155; Sat, 4 Apr 2015 07:14:48 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t34BEgVd001967; Sat, 4 Apr 2015 07:14:43 -0400
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t34BEf6a019821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 4 Apr 2015 07:14:42 -0400
Message-ID: <551FC796.1060605@mit.edu>
Date: Sat, 04 Apr 2015 07:14:30 -0400
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@mit.edu>
References: <D26B0844-431B-4A14-8B9F-BAF1A2D55444@mit.edu> <alpine.GSO.1.10.1504032112300.22210@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1504032112300.22210@multics.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrLviuHyowaRGXYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+7v9YwFMwQqtqx9y9TAOIW3i5GTQ0LARGLlntUsELaYxIV7 69m6GLk4hAQWM0kcO9XGCuFsYJRYtv0QO4Rzi0li26pOsBZeATWJc6+bmEBsFgFViYPXjjKC 2GxA9vQ1LWBxUYEoiYlfD0HVC0qcnPkEzBYRUJJYfLaFDcRmFlCX6P29khXEFhawlti55R9Y jZBAgcTKt/eAFnNwcAo4Sez9GQJRbiYxb/NDZghbXqJ562zmCYyCs5BsmIWkbBaSsgWMzKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCg1WSdwfju4NKhxgFOBiVeHg3BMuH CrEmlhVX5h5ilORgUhLlvbkaKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd+VKoBxvSmJlVWpR PkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgRvyDGgRsGi1PTUirTMnBKENBMHJ8hw HqDhsiA1vMUFibnFmekQ+VOMilLivKUgCQGQREZpHlwvLJm8YhQHekWYdy1IFQ8wEcF1vwIa zAQ0eMNksMEliQgpqQbGJTe79bwfhihI/lW7a8HCy9DoV1k8YQLfry6XrN2Md1Y2HnlRzv7l wPV3oXMjOET+70439TbqkxdabPVw6uVjfqm3EutDXRujzyqWPWiLTfxVsfVR3dJHyalne9g+ HNx5TeJu6nKLnocF2qx3WNYvqWno/qmXI/Nwwoe7ITKLX9eceDFj+fx3SizFGYmGWsxFxYkA 4HXLfwEDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/zIZLxdCquYXg3EpYFFIGRvlTxIc>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Apr 2015 11:14:52 -0000


On 4/3/2015 9:15 PM, Benjamin Kaduk wrote:
> On Fri, 3 Apr 2015, Justin Richer wrote:
>
>> In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 <https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12>) there’s a clause that’s causing some consternation in the general review:
>>
>>     Since the client configuration endpoint is an OAuth 2.0 protected
>>     resource, it SHOULD have some rate limiting on failures to prevent
>>     the registration access token from being disclosed though repeated
>>     access attempts.
>>
>> A comment has been raised arguing that this text isn’t helpful to
>> implementors as it doesn’t tell them what kind of rate limiting to do or
>> how to accomplish it. It has also been pointed out that there’s not an
>> obvious need for this recommendation if there’s enough entropy in the
>> registration access token to begin with.
>>
>> The suggestion has been made to drop the above text, and potentially to
>> add a reference to the sections on token complexity in 6750 §5.2 and
>> 6819 §5.1.4.2.2. My suggested text in that regard is:
>>
>> Since possession of the registration access token authorizes the holder
>> to potentially read, modify, or delete a client’s registration
>> (including its credentials such as a client_secret), the registration
>> access token MUST contain sufficient entropy such as described in
>> [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2.
>>
>> I would add this as the last sentence to the first paragraph in the
>> security considerations section.
>>
>> What does the WG think of this suggested change?
> I think it's a fine change, in general.  But I also saw the discussion on
> the other list, so maybe I'm biased.
>
> In specific, RFC 6750 does not include the word "entropy", and we might
> want to explicitly mention that "sufficient" means "sufficient to prevent
> a random guessing attack".
>
> -Ben

I think that's a reasonable addition, thanks!

  -- Justin