Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 22 May 2017 13:27:08 -0700

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.

---

From: William Denniss <[email-masked]>
Date: Mon, 22 May 2017 15:14:06 -0700

Adam,

Thank you for reviewing the draft.

> document;

Two years ago when I posted version 00 of the draft, nearly every native
app OAuth interaction in the wild violated that MUST. It was quite a large
problem, and we've been working in the OAuth community for a while to get
to this point, and I do believe there is a strong consensus to publish.

I see this BCP not only as a single MUST of what you shouldn't do, but also
as a valuable document detailing exactly how to meet that requirement,
which is non-trivial. Given how widespread the old practice was, I think
it's worth very clearly detailing why the old way is bad (e.g. Section
8.7), and giving as much information as possible for how to do it the right
way which is the goal of the document.

in which case, I would encourage somewhat more detail around
> removed for other reasons, described below).

One of the problems with the old way of doing things is that it was hard to
tell the good actors from the bad – they all used the same techniques. So I
do actually see value in naive UA filtering as even though the bad actor
can lie, it becomes a provable lie.

Thanks for your feedback here, I'll take another look and see if we can
build in some of your suggestions.

________
> that existing standards be reviewed to ensure they... use IPv6

Good points. Version 11 added an IPv6 example, and a discussion around
IPv4/6 compatibility. I believe with that we are now conformance with the
IAB guidelines.

While I agree with your statement in principle that all hosts should
support already IPv6 loopback, in practice I was dealing with a case
recently where some code that was written assuming local IPv6 availability
broke when a user had explicitly disabled IPv6 on their machine. It seems
users can still get away without IPv6 for now, meaning IPv6 loopback
availability is not completely guaranteed.

Due to this, I think documenting an approach where clients can support IPv6
only, IPv4 only, and both being available is probably best for now (and 7.3
in v11 does that in the last paragraph).  It looks like that approach we
took in v11 does follow the IAB recommendations for mixed environments.

> on its face, and should be removed or clarified.

Will be removed in the next update. Thank you.

> treat [::1] identical to 127.0.01 for this purpose as well.

The expectation here was that the client would register both I guess. That
said, they'd be no harm in treating them as identical for that purpose, so
that's good advice. I'll revise.

> authentication servers must be extra vigilant in detecting and avoiding

I'll revise this, I agree the claim is a little too aspirational.

> that embed a web view can simply extract authentication-related material

Yes, they can do that too (and I agree it's a simpler attack
implementation). I'll include in the next revision. I'll keep in the
keystroke logging text, as it's another vector, and people tend to have a
visceral reaction when learning this.

> means "Android Implicit Intents."

Fixed in the next update, thanks.

> browser, so as to obtain the advantages described in section 4.

My understanding of the Web Authentication Broker is that it is effectively
a special-case browser designed for authentication. There is a single
cookie-jar which is retained and used with all apps that use the Web
Authentication Broker in "SSO mode". So logins are shared, and the
advantages of Section 4 apply.  It's a separate cookie-jar from the main
browser, which would imply a minimum of two sign-ins on the device (so not
quite "single" at a device level), but I'm not sure if this is enough to
disqualify it.

My goal here is to simply document the current state of the art of the
platforms, and I felt that the Web Authentication Broker qualified as an
external user agent per the BCP.  The user interface is arguably quite nice
too, which mitigates some of the downsides of using a special
authentication "browser" with a separate cookie jar.

I'm open to suggestions on this section.

Thanks again for your comments.

Best,
William

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 May 2017 10:24:12 +0100

Hi William,

> Will be removed in the next update. Thank you.

Actually, I disagree with Adam on this, because what he says is OS specific. So I think the text is valuable and should stay.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 May 2017 11:09:18 +0100

On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:
> Hi William,
> 
> On 22 May 2017, at 23:14, William Denniss <[email-masked]> wrote:>>> 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.
>>> 
>> 
> Actually, I disagree with Adam on this, because what he says is OS
> specific. So I think the text is valuable and should stay.> 
In particular, I think SO_REUSEADDR socket option is widely implemented,
both on Windows and Linux.

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 11:53:08 -0500

On 5/23/17 05:09, Alexey Melnikov wrote:
>> On 22 May 2017, at 23:14, William Denniss <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>
>> specific. So I think the text is valuable and should stay.
>>
> In particular, I think SO_REUSEADDR socket option is widely 
> implemented, both on Windows and Linux.
>

Okay, after doing a lot of digging, this appears to be much more 
complicated than it should be [1]. Linux (as of 3.9) does allow multiple 
_listeners_ on a single IP/Address pair (and does load balancing among 
them o_O), but only if they're both using SO_REUSEADDR ("don't do that 
then" would be good advice). Windows allows the kind of hijacking 
described in the document unless SO_EXCLUSIVEADDRUSE is set (and it 
might be good advice in this document to suggest setting it).

So I'm okay with the paragraph staying in, although I would like to see 
it qualified with "on some operating systems", and would like to see a 
note (probably in section B.3) recommending the use of 
SO_EXCLUSIVEADDRUSE on listening sockets.

/a

____

[1] The most comprehensive explanation of facts on the ground that I 
could find is 
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 12:27:09 -0500

William --

Thanks for your quick responses! I have only one follow-up (beyond my 
response to the thread that Alexey started):

On 5/22/17 17:14, William Denniss wrote:
> My understanding of the Web Authentication Broker is that it is 
> effectively a special-case browser designed for authentication. There 
> is a single cookie-jar which is retained and used with all apps that 
> use the Web Authentication Broker in "SSO mode". So logins are shared, 
> and the advantages of Section 4 apply.  It's a separate cookie-jar 
> from the main browser, which would imply a minimum of two sign-ins on 
> the device (so not quite "single" at a device level), but I'm not sure 
> if this is enough to disqualify it.
>
> platforms, and I felt that the Web Authentication Broker qualified as 
> an external user agent per the BCP.  The user interface is arguably 
> quite nice too, which mitigates some of the downsides of using a 
> special authentication "browser" with a separate cookie jar.

Some of this comes down to user experience and some of it comes down to 
user choice. I'm going to speak using first-person pronouns here, but 
please be aware that I'm speaking from the point of view of a 
significant body of users.

For the user experience side of things: users of Firefox and Chrome will 
commonly take advantage of cross-machine, cross-platform password 
synchronization built into those browsers, and the recommendation you're 
giving in this document defeats those pretty soundly. Thinking all the 
way through the user experience you're promoting, here's what this would 
look like to me:

 1. Native app has a button I can use to [link an account, authenticate
    myself, etc]
 2. I click that button, and the Web Authentication Broker opens
 3. I manually open Firefox, go to options->security, and click on
    "saved logins"
 4. I type in the name of the authenticating website, click on "Show
    Passwords," and enter my master password
 5. I copy and paste the (long, randomly-generated) password for the
    authenticating website into the Web Authentication Broker

That's... pretty friction-laden, especially when you consider that 
opening the authentication flow in my native browser would take maybe 
one or two clicks instead. The situation for Chrome users is 
approximately as bad.

The other part of this recommendation (and I think this is a bigger 
issue) is that I, as a user, have made a pretty conscious decision about 
the browser I want to use for these kinds of things, based in part on 
the way I know various browsers handle things like analytics and 
privacy, and based in part on the speed with which browser security 
exploits are patched. I'm going to presume that the Web Authentication 
Broker acts in every way that I care about like either Edge or Explorer 
(probably Edge), which is likely to fall outside the envelope of what 
I'm okay with in a browser. I don't mean this as a major knock on Edge; 
I just have certain preferences in this area, and it's a choice that I 
feel I should be allowed to make and have respected when possible.

This section is written in a way that reads very much like "use the Web 
Authentication Broker when possible, and fall back on the user's 
explicitly selected and preferred browser only as a last resort." This 
circumvents the user agency I describe above, which gives me more than a 
little cause for concern.

For these two reasons, I would like to see the recommendation in this 
section pretty much reversed: calling to to the browser registered with 
the operating system should be preferred so as to respect user agency, 
followed by a note that using the Microsoft Web Authentication Browser 
in SSO Mode qualifies as using an External Browser as described in this 
document, although it has the three drawbacks of:

 1. Not integrating with cookie storage for the user's preferred browser.
 2. Not integrating with password management for the user's preferred
    browser.
 3. Bypassing user choice regarding various browser attributes, such as
    privacy and security properties.

/a