Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

William Denniss <wdenniss@google.com> Tue, 07 March 2017 20:35 UTC

Return-Path: <wdenniss@google.com>
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 28B34129473 for <oauth@ietfa.amsl.com>; Tue, 7 Mar 2017 12:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.485
X-Spam-Level:
X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 XqEAFx8sWCmq for <oauth@ietfa.amsl.com>; Tue, 7 Mar 2017 12:35:44 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F59F129428 for <oauth@ietf.org>; Tue, 7 Mar 2017 12:35:44 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id p64so24618869qke.1 for <oauth@ietf.org>; Tue, 07 Mar 2017 12:35:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jfKbNA7/Y1hl+ihbtRXdUcaRykwgtVe9QXP+gJokqG0=; b=C0wxzi0OTcGRXeL+tU7y1fCM5j5okfv2JLNudM2pgYHCwg+Opn+l75xy3213pYKG2j DZUZZ/RAUu4mSGvIrKX1A/laMEo4/QrCzHV8+Bo2y6x4d0OdzcPpTYWsJU/i9DNiY/wK feCNm1OU0+n7HJqqBuhQI+Mou5pj7NaErR/y8geDvSwLv8wRkJ5RhJKduXspg7XgJxxP FvvtQ/rldPdogsTFefkfqnmnLcoSgP5UflfbQ+g6Rlvuk8tYft9yUEs7iNOervBqcl6S P16GcU9tQ0hd1473MCKPNl+YcmdIPkldDoLwFTgD4fT92requ7/ycqogQ4PkyXcbTyhl jn7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jfKbNA7/Y1hl+ihbtRXdUcaRykwgtVe9QXP+gJokqG0=; b=HYu7ArDbIG1XZ4iv338ef0jSlhjq3C6wzb553TkQPQi4mPG3HuSTC9eBc2REbxFmo1 9eM+OD9Mj28gnqXG8F1qNlLm3xnVga4vNHNE+yxyWcQIvz6JhbG5pvF6aVU9sazVQErF LqvkznpQw0onspNzM2o6YkyyVUb1x+0YLvPyFumzvUDhIetMXH+28XoHRLm6CRAB/jUE NfHBJ4FNs64kfLxNvwAnvnjW58MzJukTYMIZx73NXXN4OLGIoA2cHnkDW9+ffauJA/x6 oJldwMIghx4IVlTPl5MdjHgrfgWLxpEoqHM5j2D+xo3SJWdwip9LOaqv++UbQJszZ96O b0AQ==
X-Gm-Message-State: AMke39nairUZyJ6E2isT62TcYEU9p4+fVKz4v8YrtQ5CjTAbeiOtrVrXjYvU5UMcVX7TORwsIJ8Bm7gNtnvu5MLU
X-Received: by 10.55.41.232 with SMTP id p101mr2753376qkp.186.1488918942904; Tue, 07 Mar 2017 12:35:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.36.203 with HTTP; Tue, 7 Mar 2017 12:35:22 -0800 (PST)
In-Reply-To: <C16D1076-1CF0-4A76-BFC4-35E35E420799@ve7jtb.com>
References: <148852246909.30907.6836735739794656654.idtracker@ietfa.amsl.com> <CAAP42hArHN5cgLqnWKyPXBrcdYXDbYuft5BinNTFtm4LNaL3yg@mail.gmail.com> <a6596083-6a19-e644-403c-4c1686eba492@gmx.net> <94286D03-D721-41C2-A4DD-D2BC05A6B37F@ve7jtb.com> <SN1PR0301MB2029E928A385D315D37EBFABA62F0@SN1PR0301MB2029.namprd03.prod.outlook.com> <C16D1076-1CF0-4A76-BFC4-35E35E420799@ve7jtb.com>
From: William Denniss <wdenniss@google.com>
Date: Tue, 7 Mar 2017 12:35:22 -0800
Message-ID: <CAAP42hDyRzVGT3P5pL5afb6GVBFV7mYFcwLvYp0djEJ60yBgBQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a11473f96b166a5054a29f44d
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vlA9iqsLJw52IV-KsTkDfGtuEgY>
Cc: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 07 Mar 2017 20:35:47 -0000

That's an important distinction. It's not a "web-view vs browser" question,
but an "embedded user-agent vs external user-agent" question.  If something
is named "webview" but has all the attributes of an external use-agent,
then it's still an external user-agent for the purpose of the BCP.

I tried to be careful to always use the term "embedded user-agent"
following the nomenclature of RFC6749, e.g. title of Section 8.1. Webview
is referenced in a few places, for example Sec 8.1 says "In typical
web-view based implementations of embedded user-agents", as most embedded
user-agents do happen to use technology called webview – but there's no
normative text that means something named "webview" but that is actually an
external user-agent can't be used.

External user-agent is defined in the spec as such:

   "external user-agent"  A user-agent capable of handling the
      authorization request that is a separate entity to the native app
      making the request (such as a browser), such that the app cannot
      access the cookie storage or modify the page content.



Earlier versions were not as careful with the terms, but it was tightened
up and clarified for this very reason.

Regarding the Windows broker, it is explicitly mentioned as an external
user agent in the implementation details appendix (emphasis added):

 Universal Windows Platform (UWP) apps can use the Web Authentication
   Broker API in SSO mode as an *external user-agent* for authorization
   flows…


I've had the same experiance as you John, and have not seen U2F work on any
implementation of webview that I've used (including iOS, Android, and
Windows using the old-style embedded IE control).

+1 to update the BCP when and if the best current practice changes. I
believe it does accurately capture the best current practice as of today.

On Tue, Mar 7, 2017 at 12:08 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> That is theory that CTAP should let web-views work.
>
> I just ran a test on the current shipping Android build. U2F is only
> working from the View controller and system browser.
> Web-view is not currently exposing CTAP.
>
> I believe that is also the case on iOS, but haven't built a app to test it.
>
> This first version of the BCP doesn’t go into advanced issues around Web
> Auth/Fido in detail.  We know that currently WebView/View controller/Token
> Agent work with existing CTAP implementations.
>
> Once we have systems deployed that can use CTAP from a web view we can
> update the BCP.
>
> We may also have a definitional problem, we consider the Windows token
> broker in SSO mode to fit the model of a view controller/Web View in that
> it is sandboxed from the app , rather than considering it a web-view.   I
> know that the token broker can support WebAuthentication (CTAP 2) in recent
> RS2 builds of Win 10.
>
> John B.
>
>
> On Mar 7, 2017, at 5:16 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>
> Not true John, the CTAP support that is current would support the web-view
> w/o any changes
>
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org <oauth-bounces@ietf.org>] On
> Behalf Of John Bradley
> Sent: Monday, March 6, 2017 12:16 PM
> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> Cc: internet-drafts@ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
>
> On fido I can tell you that for security reasons U2F wont work from a
> web-view currently.
>
> Once we move to Web Auth (Fido 2) where the OS provides a API for apps to
> call to get the token it will work but the tokens are audianced to the app
> based on its developer key and bundle_id so that a app cant ask for a token
> for a different site to do correlation.
>
> It is true that Fido UAF currently requires a web-view to work as the
> authenticator is effectively compiled in to each application, and that
> application has access to the private keys on most platforms (Samsung knox
> being the only exception to that that I know of where the keys are managed
> by a common API to hardware key storage, but they are scoped like U2F as
> well)
>
> So for the most part it is true and that unless you use the browser to get
> the Fido token the audience is for the app.
> Example  Salesforce creates native app that may use enterprise SSO via
> SAML, and the enterprise may use Fido as a authentication factor.
> If they use the webview + fido API approach the app can only get a token
> for SalesForce based on its signing key.  It could fire up the web-view and
> do U2F authentication with the enterprise after Salesforec has redirected
> the user.  However it will give every enterprise a token audience to
> Salesforce with a salesforce specific key.   If there is a second app for
> say Slack if they do the same thing the enterprise would get a slack
> audienced token and a slack key forcing a separate registration.
>
> The recommended alternative is that the app use a custom tab for the user
> to SalesForce and that redirect to the enterprise.
> The enterprise gets the same token/key with the correct audience from all
> apps on the device using the browser or custom tab.
> The user may not need to signin a second time, and if they do there Fido
> token will not need to be re-registerd.
>
> The Fido API approach really only works for first party apps like PayPal
> if the the app is not doing federation and paypal is doing the
> authentication for there own app.
>
> Token binding private keys have similar issues.   The pool of private keys
> will probably not be shared between apps, and not between the app and the
> browser (Win 10 may be an exception but it is not documented yet)
>
> In the case of using AppAuth with token binding the browser maintains the
> keys so the enterprise would be able to see the same key and use the same
> cookies across all AppAuth Apps.
>
> You can include token binding in your app, however the token bindings and
> cookies are going to be sand boxed per app.
> Depending on implementation the app gets access to the cookie, but perhaps
> not to the private token binding key.  (At least I don't think it will in
> Android embedded webview).
>
> We could expand on this later in an update to the BCP once Web
> Authentication and Token Binding are final.
>
> There are still some unknowns, but in general for any sort of
> SSO/Federation 3rd party app I don’t see recommending anything other than a
> custom tab/ view controller/ external browser.
>
> William can take the formatting question:)
>
> John B.
>
> On Mar 6, 2017, at 4:41 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
> wrote:
>
> Hi William, Hi John,
>
> I just re-read version -8 of the document again.
>
> Two minor remarks only.
>
> Editorial issue: Why do you need to introduce a single sub-section
> within Section 7.1. (namely Section 7.1.1)?
>
> Background question: You note that embedded user agents have the
> disadvantage that the app that hosts the embedded user-agent can
> access the user's full authentication credential. This is certainly
> true for password-based authentication mechanisms but I wonder whether
> this is also true for strong authentication techniques, such as those
> used by FIDO combined with token binding. Have you looked into more
> modern authentication techniques as well and their security implication?
>
> Ciao
> Hannes
>
> On 03/03/2017 07:39 AM, William Denniss wrote:
>
> Changes:
>
> – Addresses feedback from the second round of WGLC.
> – Reordered security consideration sections to better group related topics.
> – Added complete URI examples to each of the 3 redirect types.
> – Editorial pass.
>
>
>
> On Thu, Mar 2, 2017 at 10:27 PM, <internet-drafts@ietf.org
> <mailto:internet-drafts@ietf.org <internet-drafts@ietf.org>>> wrote:
>
>
>   A New Internet-Draft is available from the on-line Internet-Drafts
>   directories.
>   This draft is a work item of the Web Authorization Protocol of the IETF.
>
>           Title           : OAuth 2.0 for Native Apps
>           Authors         : William Denniss
>                             John Bradley
>           Filename        : draft-ietf-oauth-native-apps-08.txt
>           Pages           : 20
>           Date            : 2017-03-02
>
>   Abstract:
>      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.
>
>
>   The IETF datatracker status page for this draft is:
>   https://na01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-
> native-apps%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Cef
> f092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7a
> eFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-native-apps%2F&data=02%7C0
> 1%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dc
> SViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0>
>
>   There's also a htmlized version available at:
>   https://na01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-native-
> apps-08&data=02%7C01%7Ctonynad%40microsoft.com%7Ceff092e6b28
> 94ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nm
> i%2FXPER8hyKBDvP%2FAVCw%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Fdraft-ietf-oauth-native-apps-08&data=02%7C01%7Ct
> onynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=pFJdiZd2ni
> SxiuXtThG8OE32rjHxoJ8U0jsoCmiaqKc%3D&reserved=0>
>
>   A diff from the previous version is available at:
>   https://na01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-
> native-apps-08&data=02%7C01%7Ctonynad%40microsoft.com%7Cef
> f092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%2F9vSFph4dt
> eZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-native-apps-08&data=02%
> 7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=0J
> OejYI%2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0>
>
>
>   Please note that it may take a couple of minutes from the time of
>   submission
>   until the htmlized version and diff are available at tools.ietf.org
>   <https://na01.safelinks.protection.outlook.com/?url=http%
> 3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.
> com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91a
> b2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru
> 0Vm4%2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0>.
>
>   Internet-Drafts are also available by anonymous FTP at:
>   ftp://ftp.ietf.org/internet-drafts/
>   <ftp://ftp.ietf.org/internet-drafts/>
>
>   _______________________________________________
>   OAuth mailing list
>   OAuth@ietf.org <mailto:OAuth@ietf.org <OAuth@ietf.org>>
>   https://na01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%
> 7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d4
> 64cda4d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244
> 281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSlotpr6JXtFXpd
> uGuI%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micro
> soft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7c
> RYUSlotpr6JXtFXpduGuI%3D&reserved=0>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micros
> oft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cR
> YUSlotpr6JXtFXpduGuI%3D&reserved=0
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsof
> t.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSl
> otpr6JXtFXpduGuI%3D&reserved=0
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>