Telechat Review of draft-ietf-oauth-native-apps-11
review-ietf-oauth-native-apps-11-genart-telechat-davies-2017-05-23-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-oauth-native-apps-11
Reviewer: Elwyn Davies
Review Date: 2017-05-23
IETF LC End Date: 2017-05-16
IESG Telechat date: 2017-05-25

Summary: (still) Almost ready.  Thanks for the responses to my last call review
of -10 which have addressed several of the comments.  It seems to me that there
still some issues with ensuring the selection of, and hence the connection to,
 the browser providing access to the authorization services is secure (this was
referred to in my previous review but only (IMO)pary addressed).  This feels
like a considerable problem but I am neither a deep security expert or OAuth
expert so I may be wrong.  My old fogey soul is deeply offended by this new
fangled usage of 'app' which is still in my book an abbreviation, but I guess I
have to bow to the changing times and the acknowledgment that 'app' is now
dignified by an appearance in the OED. >shame<.  Still, given that RFC 6749
lives on the other side of the app/application divide, I think that the
examples in the abstract and the beginning of s1 should match with RFC 6749
which uses 'native application(s).'    There are also a couple more nits that I
missed on the previous pass. [BTW UI is indeed a well-known abbreviation but
given it is only used once it might be worh expanding it.]

I understand that -12 has been submitted but had not been placed in the public
repository as of 9pm  UTC on 2017/05/23 (Tuesday evening my time).

Major issues:
Possibly 2nd minor issue  is actually major.

Minor issues:
Relationship between (web) browser, (operating) system and user choice of
browser: The terminology definition of 'browser' in s3:
   "browser" The default application launched by the operating system to handle
   "http"
                      and "https" scheme URI content.
The terminology of 'system browser' used in version 10 of the draft has been
removed but the term 'default application' could still be interpreted as a
system choice.  As far as I know, although some operating systems have a
preinstalled browser which will be the 'default browser', this is a commercial
decision and users usually have the option to install an alternative browser
and instruct the OS to use this as the application used to handle http/https
content.  I suggest that 'user selected application' would be clearer than
'default application'.  In particular Linux installations have no default
application - the user/installer has to separately install a browser and set it
as the default.

Security implications of browser application selection and activation:
[This could possibly be consdiered as a major issue.]
AFAIK the choice of application that is invoked to handle http/https content is
a user choice made on a per-user configuration that does not require special
privileges.  Typically a browser application will allow a user to select it as
default http/https content when it is first run by a given user and the choice
can be changed at the user's whim subsequently.  However there is no
requirement to involve the user.  A user-level application could (AFAICS)
happily hijack the configuration and install itself as selected browser without
any user intervention.  Apart from the obvious possibility of DoS, I am not
sufficiently expert in the details of OAuth to know what the consequences of a
bad actor installing a malicious pseudo-browser, potentially acting as a MiTM
or otherwise, might be.  It strikes me that a user of OAuth might be concerned
that the browser acting as intermediary was what s/he thought it was.

Nits/editorial comments:
Abstract:  'Native apps' needs a reference to Section 9 of RFC 6749.  I note
that there they are (still) called 'native applications'.  Suggest you postpone
introducing the shorthand 'native apps' to section 1 and indicate that the
browser is a web browser. Thus: OLD:
   OAuth 2.0 authorization requests from native apps should only be made
   through external user-agents, primarily the user's browser.  This
   specification details the security and usability reasons why this is
   the case, and how native apps and authorization servers can implement
   this best practice.
NEW:
   OAuth 2.0 authorization requests from native applications, as described
   in Section 9 of RFC 6749, should only be made through external user-agents,
   primarily the user's web browser.  This specification details the security
   and usability reasons why this is the case, and how native applications and
   authorization servers can implement this best practice.
END

s1, para 1: In line with the above: s/native apps/native applications
(hereafter known as 'native apps')/

s1, para 2: s/browser/web browser/

s1, last para: 'AppAuth' needs a reference (a pointer to Appendix B would
provide something suitable I think).

s3:  Needs a definition for 'redirect URI' pointing to RFC 6749 (possibly to
Section 3.1.2 there).

s4.1, Figure 1: Rather nitty but the equivalence of authz and authorization
should be noted.

s7.1: Are there any references that an interested reader could follow to find
more info?

s7.2: Again reference(s) would help.  While the draft writes of operating
systems I can only find one (android). Is this in fact correct?  Is there an
expectation that this will become more generally implemented?  If not making
this a firm requirement is somewhat dubious.

s7.1 and s7.2: It might be useful to mention that s8.1 describes means to
protect against bad actors installing malicious URI claiming apps. (And also
helps with s7.3 I believe).