Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)

Justin Richer <jricher@mit.edu> Wed, 22 April 2015 01:31 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 925731A006F; Tue, 21 Apr 2015 18:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Nl0WBn9Rq-eP; Tue, 21 Apr 2015 18:31:04 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2C61A0069; Tue, 21 Apr 2015 18:31:03 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-cd-5536f9d62c72
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.69.03359.6D9F6355; Tue, 21 Apr 2015 21:31:02 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t3M1V123013398; Tue, 21 Apr 2015 21:31:01 -0400
Received: from artemisia.richer.local (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 t3M1UvVZ008785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Apr 2015 21:30:59 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8AFF8BA8-4E33-4F5F-8469-9D5035A72CA7"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu>
Date: Tue, 21 Apr 2015 21:30:57 -0400
Message-Id: <82268A04-588C-4D43-A638-8D99E76727DD@mit.edu>
References: <20150406214830.8764.52235.idtracker@ietfa.amsl.com> <B52367E6-370F-4681-B4F5-F06C90F86959@yahoo.com> <89B75F57-55D8-4137-9F1C-9BD7C71AC855@nostrum.com> <BY2PR03MB4429FC8FABE03426B27663EF5FD0@BY2PR03MB442.namprd03.prod.outlook.com> <7CD93E42-BDD7-456F-8445-AE233A2897B7@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixG6nonvtp1mowZ+z8hbzO0+zW0z7+ZrN YsaficwWe6d9YrG4PXclm8XJt6/YLN4sPM7qwO6xZMlPJo/WHX/ZPWbtfMLiMWvWYaYAligu m5TUnMyy1CJ9uwSujNffdjAVHMytuPfzBFsD452YLkZODgkBE4nN354xQdhiEhfurWfrYuTi EBJYzCQx+exzFghnI6PE7u4vUM5DJokTc3+xgLQwCyRIvPoxlRHE5hUwkJh76gvYKGGBJIkF M1aBxdkEVCWmr2kBinNwcApYSzy86A0SZgEJb9jJDjKTWeAUk8SKWVeh5lhJTFp9nwli2SIm ibUr7rKBJEQElCW2Pb7FCjJIQkBeomdT+gRGgVlIzpiF5AyIuLbEsoWvmSFsTYn93ctZMMU1 JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQLzezRC81pXQTIyhyOCV5djC+Oah0 iFGAg1GJh3fFBNNQIdbEsuLK3EOMkhxMSqK8fB/MQoX4kvJTKjMSizPii0pzUosPMUpwMCuJ 8C5dAJTjTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJIAygI1ChalpqdW pGXmlCCkmTg4QYbzAA1fB1LDW1yQmFucmQ6RP8WoKCXOOw8kIQCSyCjNg+uFJbZXjOJArwjz HgGp4gEmRbjuV0CDmYAGx20zARlckoiQkmpgXPAned/dk10T3vdMab4RHNy7TP3gPIcZ5+Zp vrJNm1M15wWP5r3H55u2sbwpsL8bdeaex3UD3aSmT932v47vX/D1QMkPJj6PF8vnm79k+2z2 2zDi5YXXp9VYv9kcPcm2ZH65ia38GqajIU+3rD2YMsPs7rG9d9SfdOX9y3YKPmX/1tnnyiK3 WAUlluKMREMt5qLiRACqROBVRwMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hQsP9J2WG39_vBjVNGGqXQ6jNVU>
Cc: "draft-ietf-oauth-dyn-reg@ietf.org" <draft-ietf-oauth-dyn-reg@ietf.org>, Ben Campbell <ben@nostrum.com>, Phil Hunt <phil.hunt@yahoo.com>, "<oauth@ietf.org>" <oauth@ietf.org>, The IESG <iesg@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>
Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)
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: Wed, 22 Apr 2015 01:31:07 -0000

Ben et. al,

We’ve incorporated feedback into the latest draft:

  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28 <http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-28>

Hopefully this addresses all of the comments below. Thank you for your review!

 — Justin

> On Apr 7, 2015, at 8:51 PM, Justin Richer <jricher@MIT.EDU> wrote:
> 
>> Section 2:
>> 
>> The software_version "SHOULD change on any update identified with the
>> same software_id" --why not MUST? What happens if this doesn't happen?
>> 
> 
> I agree with Mike that the SHOULD is more realistic, especially because the definition of “version” isn’t something that we can really lock down a lot from the spec’s perspective.
> 
> What we can do though is add some text, as Ben suggests, that says why the SHOULD ought to be applied in the common case and what kinds of exceptions there are. I’ll try to work something out based on the discussion threads here and add it to the draft.
> 
> To the other issues:
> 
>> 
>> "Extensions and profiles MAY expand this list.." -- That seems more like
>> a statement of fact than a normative requirement.
>> 
> 
> Noted, we’re just trying to say that there are others items that could be in there. We can change the “MAY” to “can”.
> 
>> 3.2.1:
>> 
>> client_id "SHOULD NOT be currently valid for any other registered
>> client": Why not MUST? What happens if it is valid for another client?
> 
> We’ve got some text on re-use of the client_id in the security considerations section.
> 
> 
>> 
>> 4.1 and 4.2 allow the designated expert to accept preliminary
>> registrations if they are confident a spec will be published. Shouldn't
>> this follow the normal processes for preliminary registrations? Is there
>> a way to walk back registrations if the spec isn't published after all?
> 
> I’ll defer to others’ expertise on the right text for the IANA section, this was imported from another example spec.
> 
>> 
>> section 5:
>> 
>> 4th paragraph after bullet list: "... authorization server needs to take
>> steps to
>>   mitigate this risk...":  Other statements like this have been
>> normative. Is there a reason this one is not?
> 
> No specific reason that I recall, except that there’s not a specific step that we prescribe. We can make that a MUST.
> 
>> 
>> 2nd paragraph from end: "... treat the new registration as being
>> suspect": ... and do what?
>> 
>> 
> 
> 
> Good catch, I think that thought is unfinished. It’s up to the AS in the end, but it should probably reject the registration.
> 
> — Justin
> 
>> On Apr 7, 2015, at 3:09 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>> I think that the current SHOULD is more realistic.  In the real world, particularly while developing and testing, people will have many iterations of pre-release software for a given version, all of which will likely be identified with the intended version number before the final release of that version of the software is made.
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Tuesday, April 07, 2015 11:11 AM
>> To: Phil Hunt
>> Cc: The IESG; oauth-chairs@ietf.org; draft-ietf-oauth-dyn-reg@ietf.org; Justin Richer
>> Subject: Re: Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with COMMENT)
>> 
>> On 7 Apr 2015, at 13:03, Phil Hunt wrote:
>> 
>>> Section 2:
>>>> 
>>>> The software_version "SHOULD change on any update identified with the
>>>> same software_id" --why not MUST? What happens if this doesn't
>>>> happen?
>>> 
>>> 
>>> The group didn’t necessarily agree to make software_version mandatory
>>> to provide. Thus the word, SHOULD seemed appropriate to indicate that
>>> if used it SHOULD change from version to version. That said, I am ok
>>> with MUST (e.g. if software_version is used, it MUST change...).
>>> 
>>> In answer to your question what happens: this is not so much a
>>> security issue (in the traditional sense of an attacker), but rather a
>>> regular software versioning/maintenance issue. The idea is that some
>>> client software updates may prove to be buggy (or have performance
>>> issues) and service providers may want to be able to refuse some
>>> versions of client software while accepting others (e.g. 2.5 is broken
>>> and causes DoS issues, while 2.5.1 is acceptable).  If a version is
>>> not provided, than an AS’s only choice is to ban all versions and
>>> force the client developer to use or obtain a different software_id
>>> for future registrations.
>> 
>> Thanks for the response. I can live with either a SHOULD or a MUST, but if the SHOULD stays, it would be good to add a sentence or two to the effect of the above paragraph. That being said, "If used, it MUST change" seems to be more precise if that fits the WG intent.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth