[OAUTH-WG] Genart telechat review of draft-ietf-oauth-native-apps-11

[Elwyn Davies <[e-mail]>]

Reviewer: Elwyn Davies
Review result: Almost Ready

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