[OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 24 May 2017 03:12 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ACC126C7A; Tue, 23 May 2017 20:12:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-native-apps@ietf.org, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, oauth-chairs@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149559553461.28492.8246838477291927765.idtracker@ietfa.amsl.com>
Date: Tue, 23 May 2017 20:12:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gqCY3x-E3sLYuxr-3cCwdvkVXSw>
Subject: [OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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 03:12:15 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-oauth-native-apps-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-oauth-native-apps-11.txt

S 7.
   To fully support this best practice, authorization servers MUST
   support the following three redirect URI options.  Native apps MAY
   use whichever redirect option suits their needs best, taking into
   account platform specific implementation details.

It's not entirely clear from this text what "support" means. Would
just echoing whatever redirect URI the client provided count as
support?


S 7.2.

   App-claimed HTTPS redirect URIs have some advantages in that the
   identity of the destination app is guaranteed by the operating
   system.  For this reason, they SHOULD be used in preference to the
   other redirect options for native apps where possible.

You should probably be clearer on who this guarantee is provided to.
And I assume this SHOULD is directed to app authors?

   Claimed HTTPS redirect URIs function as normal HTTPS redirects from
   the perspective of the authorization server, though as stated in
   Section 8.4, it is REQUIRED that the authorization server is able to
   distinguish between public native app clients that use app-claimed
   HTTPS redirect URIs and confidential web clients.

S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?


S 8.1.
   As most forms of inter-app URI-based communication send data over
   insecure local channels, eavesdropping and interception of the
   authorization response is a risk for native apps.  App-claimed HTTPS
   redirects are hardened against this type of attack due to the
   presence of the URI authority, but they are still public clients and
   the URI is still transmitted over local channels with unknown
   security properties.

I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?