Adam Roach
2017-05-22 20:27:08 UTC
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.
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.