Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT)

Justin Richer <jricher@mit.edu> Sat, 04 July 2015 01:01 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 167BB1A8ADD; Fri, 3 Jul 2015 18:01:38 -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 RvYMxZcRpCOC; Fri, 3 Jul 2015 18:01:34 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B171A923A; Fri, 3 Jul 2015 18:01:32 -0700 (PDT)
X-AuditID: 12074423-f79496d000001e58-cf-5597306bd7dd
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A2.2E.07768.B6037955; Fri, 3 Jul 2015 21:01:31 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t6411Upk031183; Fri, 3 Jul 2015 21:01:30 -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 t6411RVh012059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jul 2015 21:01:28 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_71BA4D47-0848-4A58-86D4-1D919D934F48"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <2C13741E-8B0C-4723-9916-6B41ECDC00B8@mit.edu>
Date: Fri, 3 Jul 2015 21:01:27 -0400
Message-Id: <6A169EAB-83C5-4B9C-B8AE-4A4EE4EE4322@mit.edu>
References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> <AFBE85D9-EA1E-4103-A9F5-BDA2ADC5F0B8@mit.edu> <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> <043650B6-603F-443F-904C-52A265F44501@cooperw.in> <2C13741E-8B0C-4723-9916-6B41ECDC00B8@mit.edu>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUixCmqrZttMD3U4PBSOYvpZ/4yWpzddJvd YsXycosXi3cyW8z4M5HZ4vbclWwWJ9++YnNg9/jy5CWTx5IlP5kCmKK4bFJSczLLUov07RK4 Mm7O3MlesGcLY8XuXy/ZGxj7ZzN2MXJySAiYSMx91M0EYYtJXLi3nq2LkYtDSGAxk8S8B3ug nA2MEosfn2SEcB4wSbSdfAbWziyQIPF7z1cwm1dAT+LR08fsILawQIHE5HMdbCA2m4CqxPQ1 LWArOAWsJf58uQxWzyKgIrG/eQYzxJxvjBLvZ+ZDzLGS+LelnRliWQOTxP33c8CGigANunrs B9BQDqBbZSW+bpWbwCgwC8kZs5CcARHXlli28DUzhG0g8bTzFSumuL7Em3dzmBYwsq1ilE3J rdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIihN2F+UdjH8OKh1iFOBgVOLh/SA8PVSI NbGsuDL3EKMkB5OSKK+xJlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8xE1CONyWxsiq1KB8m Jc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC95geUKNgUWp6akVaZk4JQpqJgxNkOA/Q 8FkgNbzFBYm5xZnpEPlTjIpS4rzbQBICIImM0jy4Xlgae8UoDvSKMK+wPlAVDzAFwnW/AhrM BDRYxHQayOCSRISUVANjV8A288MPZq+TCLT8y9uaPe/DKcmIkvdGl669WndXdK/KqXrLhGQ2 18Agjg6miYf2LDrdr7Oi3dfh4fWsy3+49+7ZlxxoaCvYlFE6iVVTZXldVjnzld0lJ+TbzbJc QxJF5jB0/W0RU97D0/bPXsQmjiFTyZ7x9JqdqhdzeqyfxNZt2JyfdEaJpTgj0VCLuag4EQCu kJdaPgMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/MStgkj8boCk-_XYe4ZY7VGEHhLU>
Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, IESG <iesg@ietf.org>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and 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: <https://mailarchive.ietf.org/arch/browse/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 Jul 2015 01:01:38 -0000

Alissa,

I’ve incorporated your suggested wording changes into the latest version of the document:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-11

Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-11.txt

Hopefully this will be sufficient to clear the DISCUSS. Thanks for your thorough review and feedback!

 — Justin


> On Jul 3, 2015, at 3:16 PM, Justin Richer <jricher@MIT.EDU> wrote:
> 
> Hi Alissa,
> 
> Thanks for the wording suggestions. Both of those sound reasonable to me, so I’ll pull them into an updated draft shortly. I’ll post back here when it’s been published.
> 
>  — Justin
> 
>> On Jul 3, 2015, at 2:47 PM, Alissa Cooper <alissa@cooperw.in <mailto:alissa@cooperw.in>> wrote:
>> 
>> Hi Justin,
>> 
>> Thanks for addressing my comments. One more note below.
>> 
>> On Jun 22, 2015, at 5:51 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> 
>>> Alissa,
>>> 
>>> I’ve uploaded a new draft that should address your comments below:
>>> 
>>> Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-10>
>>> 
>>> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10.txt>
>>> 
>>> Please let me know if you have any further questions,
>>>  — Justin
>>> 
>>>> On Jun 11, 2015, at 5:00 PM, Justin Richer <jricher@MIT.EDU <mailto:jricher@MIT.EDU>> wrote:
>>>> 
>>>> Hi Alissa, thanks for your review. Responses are inline.
>>>> 
>>>>> On Jun 8, 2015, at 9:40 AM, Alissa Cooper <alissa@cooperw.in <mailto:alissa@cooperw.in>> wrote:
>>>>> 
>>>>> Alissa Cooper has entered the following ballot position for
>>>>> draft-ietf-oauth-introspection-09: Discuss
>>>>> 
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>> 
>>>>> 
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>> 
>>>>> 
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/>
>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> = Section 2.1 =
>>>>> "The endpoint MAY allow other parameters to provide further context to
>>>>>  the query.  For instance, an authorization service may need to know
>>>>>  the IP address of the client accessing the protected resource in
>>>>>  order to determine the appropriateness of the token being presented."
>>>>> 
>>>>> How does the protected resource know whether it needs to include such
>>>>> additional parameters or not?
>>>>> What is meant by the "appropriateness" of
>>>>> the token? 
>>>>> 
>>>>> In general if we're talking about a piece of data that could be sensitive
>>>>> like client IP address, it would be better for there to be specific
>>>>> guidelines to direct protected resources as to when this information
>>>>> needs to be sent. I note that Section 5 basically says such
>>>>> considerations are out of scope, but if this specific example is to be
>>>>> provided here then they seem in scope to me.
>>>> 
>>>> We are trying to leave the door open to extensions and adaptations of this protocol, specifically around the protected resource passing along information about the client’s request. The AS might be able to help the RS detect funny business on the client’s behalf (i.e., whether it’s appropriate for the client to presenting the token in this context) if it has that information. 
>>>> 
>>>> The example isn’t supposed to be normative or pull extra considerations into scope of this protocol but instead to point out where it could go.
>> 
>> 
>> I think there are two more changes that could make this crystal clear. 
>> 
>> In 2.1:
>> s/The definition of any other parameters/The definition of this or any other parameters/
>> 
>> In 5:
>> s/such information could have additional privacy considerations/such information could have additional privacy considerations that extension specifications should detail./
>> 
>> Thanks,
>> Alissa
>> 
>>>> 
>>>> Do you have a suggestion for rewording this? Perhaps it would be best to move all of this language to the security considerations section, as it’s more guidance for what extensions to this spec would need to think about as opposed to what pure implementations of this spec would need.
>>>> 
>>>>> 
>>>>> = Section 5 =
>>>>> "One way to limit disclosure is to require
>>>>>  authorization to call the introspection endpoint and to limit calls
>>>>>  to only registered and trusted protected resource servers."
>>>>> 
>>>>> I thought Section 2.1 made authorization to call the introspection
>>>>> endpoint mandatory. This makes it sound like it's optional. Which is it?
>>>> 
>>>> Thanks for this catch. Authorization used to be optional, and it looks like we missed updating this text. I’ll fix that in the next revision.
>>>> 
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> = Section 1.1 =
>>>>> There is no reference to RFC2119 here, which may be okay but most
>>>>> documents include it if they use normative language (I think).
>>>>> 
>>>> 
>>>> Not sure how that happened, this should have been included by the xml2rfc tooling, I’ll look into it.
>>>> 
>>>>> = Section 2 =
>>>>> "The
>>>>>  definition of an active token is up to the authorization server, but
>>>>>  this is commonly a token that has been issued by this authorization
>>>>>  server, is not expired, has not been revoked, and is within the
>>>>>  purview of the protected resource making the introspection call."
>>>>> 
>>>>> Is "within the purview" a term of art for OAuth 2.0? Is there a more
>>>>> specific way to describe what is meant here? Also, I note that in the
>>>>> description of the "active" member in Section 2.2, this criterion is not
>>>>> listed. It seems like these should be aligned.
>>>> 
>>>> It is not a term of art in OAuth, and I can change that to “is able to be used at the protected resource” if that’s clearer. I will also add that to the list of checks about the active value, thanks.
>>>> 
>>>>> 
>>>>> = Section 2.2 =
>>>>> "Note that in order to avoid disclosing too much of the
>>>>>  authorization server's state to a third party, the authorization
>>>>>  server SHOULD NOT include any additional information about an
>>>>>  inactive token, including why the token is inactive."
>>>>> 
>>>>> Seems like this should be a MUST NOT unless there's some reason for
>>>>> providing anything other than active set to false. Same comment applies
>>>>> in Section 4.
>>>> 
>>>> That’s why it’s SHOULD — which translates, roughly, to “do it this way unless you’ve got a really, really good reason not to”.
>>>> 
>>>>> 
>>>>> = Section 2.3 =
>>>>> It seems like there is another error condition and I'm wondering if its
>>>>> handling needs to be specified. Per my question in Section 2.1, if it's
>>>>> possible that the request is properly formed but is missing some
>>>>> additional information that the authorization server needs to evaluate
>>>>> it, should there be an error condition specified for that case?
>>>>> 
>>>> 
>>>> Not by this specification, since there isn’t a mechanism for the protected resource to figure out automatically what to do next. If there’s a future extension specifying this extra information, it can define its own value.
>>>> 
>>>> — Justin
>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth