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

Alissa Cooper <alissa@cooperw.in> Wed, 24 May 2017 15:51 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577DE129B9C; Wed, 24 May 2017 08:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=grbF0r1z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oSP/0Dj0
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7laQfhUTx1XL; Wed, 24 May 2017 08:51:23 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6913D129B84; Wed, 24 May 2017 08:51:23 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CF13A20B70; Wed, 24 May 2017 11:51:22 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 24 May 2017 11:51:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lJszP1hqAlxHdDz3b7 OvfXHUHIy0pvld8M/psP3UbMk=; b=grbF0r1zCLBfbHjCIhAEPTMphOn54QQZ5G yjtP1GGGLctK/jNnEIrMXqtByXg7EeU+5BY/TNgCKJLfZjytJ111om1l76OYxfuu 5DDZnL7pb0MI0aU6rCLyiuQNJGg15W0elFKtmqHr7Wbi3X3XPwP6yFlsmFvLkG9V 7UJzppM+vHQONn+VG4SY18iVQmSDLQeDy3e/7pnW7k6lWOQGeL01FqWRqu5x6ja3 X2/OraFImZh181bDh/kgXAHsBsmgd+HpedTAwFvjMRs59A5ddsnjo9gpubVuHV4+ z93TkxsvxCv0JaO7UKrhfTZMOJ5wzdcYJPfwKBg2DOzrYAveAQBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lJszP1hqAlxHdDz3b7OvfXHUHIy0pvld8M/psP3UbMk=; b=oSP/0Dj0 3u85Cb2TgRxt8rOlgQNOz4O99QI6Uer3a7/9C2w2LX8MUHjWKmJ461H7TEfjEymz V757wAQs6IJSL73c6yfmraEg9NYJhHQG02Tvl/vrpK46JhU0e1MrNXhzqSy/fLzF 989EkKZEFuYzy5So2jz+KLWY6x5ohfsFhOutPsTz5GEc7I/Ih/inPdYkS9Aoo358 Q6HU/PjJan47FXd+MTW8zNVTfj3WxEBuc/21bvIx5DhnIaG5ja6P9P9TKfgIX8r5 zX3rOKL5W+IJi5EWNoPa9Jux0CoKsRowY8pWUD5rZZHXI1tfo+8ozsfXWWhOclTM O8q/ZgFj4poncg==
X-ME-Sender: <xms:-qslWQl18c_iYoowePPuXuDTjEU7o9zz19ldIJFuEwa4wBMZ00lzhA>
X-Sasl-enc: tqioOHLFjlUvFXvrsDZe0lXZ3i1PRXf7Q5af8QqkJFsp 1495641082
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id AC40C7E1FB; Wed, 24 May 2017 11:51:21 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <149558160461.28455.9901952519540975154@ietfa.amsl.com>
Date: Wed, 24 May 2017 11:51:19 -0400
Cc: "gen-art >> General area reviewing team" <gen-art@ietf.org>, draft-ietf-oauth-native-apps.all@ietf.org, oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2A87DA6-5B79-4392-9F51-5507F868EC3D@cooperw.in>
References: <149558160461.28455.9901952519540975154@ietfa.amsl.com>
To: Elwyn Davies <elwynd@dial.pipex.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/C5cZrkF7iyME10Eb7jdxmQZniW4>
Subject: Re: [OAUTH-WG] [Gen-art] Genart telechat review of draft-ietf-oauth-native-apps-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 15:51:25 -0000

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 <elwynd@dial.pipex.com>; 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art