[OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
Adam Roach <adam@nostrum.com> Mon, 22 May 2017 20:27 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE426128896; Mon, 22 May 2017 13:27:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149548482877.9096.13896958451655712801.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 13:27:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1gAqHXoqzMW9uYavDqOECreKq0U>
Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 22 May 2017 20:27:09 -0000
Adam Roach has entered the following ballot position for draft-ietf-oauth-native-apps-11: No Objection 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 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-native-apps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General ======= The thesis of this document seems to be that bad actors can access authentication information that gives them broader or more durable authorization than is intended; and appears to want to mitigate this predominantly with a single normative statement in a BCP telling potential bad actors to stop doing the one thing that enables their shenanigans. For those familiar with the animated series "The Tick," it recalls the titular character yelling "Hey! You in the pumps! I say to you: stop being bad!" -- which, of course, is insufficient to achieve the desired effect. I see that there is nevertheless "strong consensus" to publish the document; in which case, I would encourage somewhat more detail around what the rest of the ecosystem -- and the authentication server in particular -- can do to mitigate the ability of such bad actors. Specifically, section 8.1 has a rather hand-wavy suggestion that authorization endpoints "MAY take steps to detect and block authorization requests in embedded user agents," without offering up how this might be done. The problem is that that the naïve ways of doing this (UA strings?) are going to be easy to circumvent, and the more advanced ones (say, instructing users to log in using a non-OAuth flow if the auth endpoint detects absolutely no cookies associated with its origin) will have interactions that probably warrant discussion in this document. (For example, such an approach -- while potentially effective -- would interact very poorly with the "SSO mode" described in section B.3; although I think that recommending the use of "SSO mode" should be removed for other reasons, described below). ________ Specific comments follow The terminology section makes distinctions about cookie handling and content access in generic definitions (embedded versus external UAs, for example) but doesn't do the same for specific technologies. It is probably worthwhile noting that the "in-app browser tab" prevents apps from accessing cookies and content, while the "web-view" does not (I had to infer these facts from statements much later in the document). Section 7.3 gives examples of IPv4 and IPv6 addresses for loopback. While I'm sympathetic to the deployment challenges inherent in getting entire network paths to upgrade to IPv6, this text discusses loopback exclusively, which means that only the local operating system needs to support IPv6. Since all modern operating systems have supported IPv6 for well over a decade, I suggest that the use of IPv4 addresses for this purpose should be explicitly deprecated, so as to avoid unnecessary transition pain in the future. Minimally, the example needs to be replaced or supplemented with an IPv6 example, as per <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>: "We recommend that existing standards be reviewed to ensure they... use IPv6 examples." Section 8.1 makes the statement that "Loopback IP based redirect URIs may be susceptible to interception by other apps listening on the same loopback interface." That's not how TCP listener sockets work: for any given IP address, they guarantee single-process access to a port at any one time. (Exceptions would include processes with root access, but an attacking process with that level of access is going to be impossible to defend against). While mostly harmless, the statement appears to be false on its face, and should be removed or clarified. Section 8.4 indicates that loopback redirect URIs are allowed to vary from their registered value in port number only. If you decide not to deprecate the use of IPv4 loopback, I imagine that servers should also treat [::1] identical to 127.0.01 for this purpose as well. Section 8.7 claims that users are likely to be suspicious of a sign-in request when they should have already been signed in, and goes on to claim that they will distinguish between completely-logged-out states and logged-in-but-needing-reauth states, and may even take evasive action based on associated suspicion. Based on what I know of user research for security indicators, the chances of these statements being true for any non-trivial portion of any user population is basically zero. I propose that this section simply highlight that this is effectively an intractable problem from the client end, without any illusions that users have the ability to distinguish between the two circumstances, and that authentication servers must be extra vigilant in detecting and avoiding these kinds of attacks. Section 8.11, third paragraph talks about keystroke logging; in practice, the attack here is far easier than that, as I believe that applications that embed a web view can simply extract authentication-related material directly from the DOM. Section B.2 uses the phrase "Android Implicit Intends" where I believe it means "Android Implicit Intents." Section B.3 describes the use of a "Web Authentication Broker" in SSO mode, which provides an isolated authentication context. If the section 8.7 text regarding user detection of nefarious application behavior in the form of web-view embedding is not removed, this needs a very clear treatment of how users might be expected to distinguish between that behavior and the SSO mode behavior. On casual examination, it seems that there would be no way to do so. I'll note that this BCP also promotes the "already logged in" behavior as being a key benefit to OAuth (cf. the third paragraph of Section 4), which the described behavior seems to mostly defeat. I would strongly suggest either removing discussion of using this mode, or deprecating it in favor of the user's preferred web browser, so as to obtain the advantages described in section 4.
- [OAUTH-WG] Adam Roach's No Objection on draft-iet… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Alexey Melnikov
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Alexey Melnikov
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… Adam Roach
- Re: [OAUTH-WG] Adam Roach's No Objection on draft… William Denniss
- [OAUTH-WG] IESG Comments addressed John Bradley