Re: [secdir] review of draft-ietf-oauth-introspection-09

Justin Richer <jricher@MIT.EDU> Tue, 23 June 2015 00:51 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525411B3132 for <secdir@ietfa.amsl.com>; Mon, 22 Jun 2015 17:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UFOIris6-8wd for <secdir@ietfa.amsl.com>; Mon, 22 Jun 2015 17:51:21 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8701B3121 for <secdir@ietf.org>; Mon, 22 Jun 2015 17:51:20 -0700 (PDT)
X-AuditID: 12074422-f79d26d0000026d6-0c-5588ad8868ad
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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 97.1C.09942.88DA8855; Mon, 22 Jun 2015 20:51:20 -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 t5N0pJGu028825; Mon, 22 Jun 2015 20:51:19 -0400
Received: from macbook-pro.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 t5N0pFID003545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 20:51:16 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_077D0EE3-C433-4520-9551-870F21D5FFB1"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5
From: Justin Richer <jricher@MIT.EDU>
In-Reply-To: <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu>
Date: Mon, 22 Jun 2015 20:51:14 -0400
Message-Id: <5C315402-F952-43C6-A72C-DFADBF1E779B@mit.edu>
References: <556CACEC.2030501@bbn.com> <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> <55707A56.5000105@bbn.com> <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsUixCmqrduxtiPU4OI5IYuVk3awWyzdeY/V YuNsRosPCx+yOLB4TD0f6rF40342jyVLfjJ5LP/6gCWAJYrLJiU1J7MstUjfLoErY+bPVraC L7cZKzbuOcfYwHh+A2MXIyeHhICJxJcj75ggbDGJC/fWs3UxcnEICSxmklh67Qc7hLORUaL9 8TKozGMmiY3LVrGDtAgLWEg83veTBcTmFdCTePT0MVgHs8AURol/RxvZIOZKSFyd/RusiE1A VWL+yltg+zgFrCWuvnkEdgcLULxr3xKwocwCJRJzp79ihBhqJbFy6j5GiM3zGSXWnIDYJiIg L/Ht2FYgmwNogazE161yExgFZyG5YxayO2aBzU2S2DHzNBOErS2xbOFrZghbU2J/93IWTHEN ic5vE1khbHmJ7W/nQMUtJRbPvAFVbytxq28B1Ew7iUfTFrEuYORexSibklulm5uYmVOcmqxb nJyYl5dapGuql5tZopeaUrqJERSv7C5KOxh/HlQ6xCjAwajEw1swuSNUiDWxrLgy9xCjJAeT kijvqjVAIb6k/JTKjMTijPii0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYR36hygOt6UxMqq1KJ8 mDJpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxtIAsEi1LTUyvSMnNKENJMHJyHGCU4 eICGnwSp4S0uSMwtzkyHyJ9iVJQS5y0FSQiAJDJK8+B6YWn2FaM40FvCvO9WA1XxAFM0XPcr oMFMQIO/5LaBDC5JREhJNTBa+T2uPP1scVOI+gmNl2KBv7ku7ldsdL+TICYy04rxJ6tDH/th /hmWshe/2/z+17AxvPaE4OLAn0+F/p87UZq5IWamQUo98+KbwQEa92flOpoHWOxPXcvwgCvL a5KfZLLTi6nstcYxr2IuHs+cxxsnf3rWZLMfsxwbdSTZmUJfNV7XbHX8wq/EUpyRaKjFXFSc CACHPPR/jgMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/I_T7ZjZCRsvH8-fjAR5kRFklQDo>
Cc: secdir <secdir@ietf.org>
Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 00:51:25 -0000

Stephen,

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 4, 2015, at 4:14 PM, Justin Richer <jricher@MIT.EDU> wrote:
> 
> Stephen,
> 
>> On Jun 4, 2015, at 12:18 PM, Stephen Kent <kent@bbn.com <mailto:kent@bbn.com>> wrote:
>> 
>> Justin,
>> 
>> 
>>> Stephen, thanks for the review. Comments inline.
>>> 
>>>> ...
>>>> The text says:
>>>> 
>>>> 
>>>> The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.
>>>> 
>>>> 
>>>> It might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.
>>>> 
>>> 
>>> This language was imported from the soon-to-be-published OAuth Dynamic Registration drafts, including the forward reference. We don’t want to repeat the requirement text.
>> I didn't review the dynamic registration docs, or I would have made the same comment there :-).
>> 
>> If you don't want to repeat requirements text, then I suggest you might re-word the sentence
>> I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous.
> 
> The section pointed to in the forward reference in that sentence has the details. If you have a better way to word this, please suggest text.
> 
>> 
>> 
>>> ...
>>>> 
>>>> How does a protected resource know which other parameters an introspection endpoint requires/accepts?
>>>> 
>>>> 
>>>> 
>>> 
>>> We’re assuming it would be either an extension or deployment-specific.
>> an extension to what?
>> 
> 
> An extension to this specification that defines other parameters and their meanings.
> 
>> it seems that a primary motivation for this document is to fix problems that arose
>> because of inadequate specifications for OAuth token syntax. In that light, this description
>> of "other parameters" seems to perpetuate this sort of problem.
> 
> I wouldn’t call OAuth having “inadequate” token syntax specification, it has *no* token syntax, and that’s on purpose. This specification actually doesn’t define a token syntax, either, but it defines a web API for getting token information regardless of the token syntax. The token itself can still be a signed JWT, or a UUID, or a random hex blob; OAuth doesn’t care, and that’s a good thing.
> 
> 
>>> 
>>> 
>>>> 
>>>> This section mandates (MUST) protection against “unauthorized token scanning” but mandates no standard way to do so. [Also, when would a scanning “attack” be authorized ;-)]
>>>> 
>>>> 
>>> 
>>> Is there something more specific we can recommend here? Perhaps in the security considerations section.
>> yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be
>> done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919).
> 
> OK, we’ll try to add some more examples.
> 
> Cute reference.
> 
>>> 
>>> And the attack could actually take place where an authorized protected resource goes fishing for other valid tokens. The attack isn’t authorized, but the client is … and yes that’s not what we meant but I’m sticking to it.  ;)
>> so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will
>> make most security experts cringe. is cringing a goal?
> 
> We can change the wording to reduce the cringe level.
> 
>>> 
>>>> ...
>>>> IANA must only accept registry updates from the Designated Expert(s)
>>>> 
>>>> and should direct all requests for registration to the review mailing
>>>> 
>>>> list.
>>>> 
>>>> 
>>>> How about:
>>>> 
>>>> 
>>>> IANA MUST accept registry updates only from the Designated Expert(s)
>>>> 
>>>> and SHOULD direct all requests for registration to the review mailing
>>>> 
>>>> list.
>>>> 
>>> 
>>> 
>>> This text was imported from a template, I’d be glad to change it if there’s a better one.
>> one should not assume that a doc that has made it through the RFC approval process
>> is perfect.
>>> 
>>>> 
>>>> Section 3.1.1
>>>> 
>>>> 
>>>> If a proposed Name matches one already registered as per 7519, ought it not have an “equivalent” (vs. “comparable”) definition if it is to be accepted?
>>>> 
>>>> 
>>>> 
>>> 
>>> It really is comparable, since the contexts are pretty different.
>> if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable?
> 
> Besides, if we simply prohibit reuse of the name, we’ll have similar-but-confusing names, like “expires” vs. “exp”, in the two different places. The meanings are close enough, with the details being context-specific, that the names should be the same. Previously it was the same registry, but that was causing even more confusion.
> 
>>> 
>>>> 
>>>> Section 4
>>>> 
>>>> 
>>>> The text lists four checks to be performed by an authorization server, yet the introduction to this list says “For instance:” A more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with “If the token …” isn’t that a sufficient caveat?
>>>> 
>>>> 
>>>> 
>>> 
>>> This is not a normative requirement, since everything is contextual to the nature of the tokens issued by the authorization server.
>> so you're saying that there is no set of checks that every authorization server
>> can be expected to perform? not even token expiration?
>> 
> 
> That’s correct. Not all tokens expire, so it doesn’t make sense to mandate checking for expiration. Every recommendation here is something that at least one known implementation of this protocol already does in the wild, but not every implementation does every check because it simply doesn’t make sense to do so. That’s why the checks are phrased as “if the token” and the list is given as a “for instance” example of what to do. We would also expect a server implementation to implement any other checks that it might have in store, like “is my database online and can I find the token in the these-are-valid-tokens table”.
> 
>  — Justin
> 
>> 
>> Steve
>> 
>