[OAUTH-WG] Genart telechat review of draft-ietf-oauth-native-apps-11
Elwyn Davies <firstname.lastname@example.org> Tue, 23 May 2017 23:20 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03151293FF; Tue, 23 May 2017 16:20:04 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Elwyn Davies <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Date: Tue, 23 May 2017 16:20:04 -0700
Subject: [OAUTH-WG] Genart telechat review of draft-ietf-oauth-native-apps-11
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 23:20:05 -0000
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).
- [OAUTH-WG] Genart telechat review of draft-ietf... Elwyn Davies
- Re: [OAUTH-WG] [Gen-art] Genart telechat review... Alissa Cooper