Re: [OAUTH-WG] [Gen-art] Genart telechat review of draft-ietf-oauth-native-apps-11

[Alissa Cooper <[e-mail]>]

Elwyn, thanks for your reviews of this document. I think the notion of what is meant by default browser as specified in this document matches the expectations of those likely to be consuming the document, so I don’t see a need for changes there. I have balloted No Objection.

Authors, thanks for your engagement with Elwyn’s previous review.

Alissa

> On May 23, 2017, at 7:20 PM, Elwyn Davies <[e-mail]> wrote:
> 
> 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).
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art