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

From: William Denniss <[email-masked]>
Date: Fri, 2 Jun 2017 17:43:03 -0700

On Tue, May 23, 2017 at 9:53 AM, Adam Roach <[email-masked]> wrote:

> On 5/23/17 05:09, Alexey Melnikov wrote:
>
> 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.
>
>
> 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.
>
> 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).
>

Thank you Alexey and Adam for the discussion and research!

I've added notes to both the Windows and Linux implementation details
(staged for v12).

> 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.
>

Added the qualifier "on some operating systems" for the next version.

/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: William Denniss <[email-masked]>
Date: Fri, 2 Jun 2017 19:25:44 -0700

On Tue, May 23, 2017 at 10:27 AM, Adam Roach <[email-masked]> wrote:

> 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.
>
> 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.
>
>
> 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
>

In my staged copy
<https://github.com/WilliamDenniss/draft-ietf-oauth-native-apps/pull/9/files>,
I have followed your advice and reversed the recommendation ordering, and
mentioned the caveats that the user's personalisations are not present in
the broker. The lack of password manager support is a very good point. It's
definitely been one of the advantages we've seen by moving to browsers from
web-view.

---

From: Adam Roach <[email-masked]>
Date: Fri, 2 Jun 2017 22:01:21 -0500

On 6/2/17 21:25, William Denniss wrote:
> I have followed your advice and reversed the recommendation ordering, 
> and mentioned the caveats that the user's personalisations are not 
> present in the broker. The lack of password manager support is a very 
> good point. It's definitely been one of the advantages we've seen by 
> moving to browsers from web-view.

Thanks! The new text in the Windows section looks great.

/a

---

From: William Denniss <[email-masked]>
Date: Fri, 9 Jun 2017 16:44:34 -0700

Thanks Adam for your feedback, and reviewing the work in progress! v12
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12> is out now
with those and other IESG review related changes.

---

From: John Bradley <[email-masked]>
Date: Fri, 9 Jun 2017 19:55:35 -0400

The Authors have published a new draft (12) of draft-ietf-oauth-native-apps.

We believe that all IESG comments have now been addressed.

Let us know if anything else is required on our side to progress the document to the RFC Editor.

Regards
John B.