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

William Denniss <wdenniss@google.com> Mon, 13 March 2017 16:48 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 287BE129872 for <oauth@ietfa.amsl.com>; Mon, 13 Mar 2017 09:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 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, 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 fh5rSP1AJekv for <oauth@ietfa.amsl.com>; Mon, 13 Mar 2017 09:48:48 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 4D73B12985B for <oauth@ietf.org>; Mon, 13 Mar 2017 09:48:45 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id y76so227434720qkb.0 for <oauth@ietf.org>; Mon, 13 Mar 2017 09:48:45 -0700 (PDT)
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=7ZjFQCGI/U/xciR+X+KZOvFASyl2fw8B0CZVqxR1r8A=; b=ixdRpwEpJxRsfNF2z0uI7jmcMkos8AjhrgyZVHuI54DBVpL/LYAJr1pJD22KwDt9Fj /5vXDJ+IggkwE9jJdnbEXbTB2xm7Ss+DtDD19QDeeKlsGwoUieg+FGMWjUroFFsEFNQn 97OY8/yJggBdf2Hx2nvZmSD6C22MLC97+siIfWFaTY3tYYp/DMThvp45ai96EAF+F0TZ jUICd4YgKukbzC05wpTHojYpun0JU1JSmPX7IThy9wx9t0fRsYrIR3sxF1Rk05jrzeJF pxM8qcGKEy58jJPTSwB+SGiZ+CPDt73hIkxQsTxqfcBtAsUhqJRJEqEHAEl3yM6PNSGh 2VZw==
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=7ZjFQCGI/U/xciR+X+KZOvFASyl2fw8B0CZVqxR1r8A=; b=b+p/jGyFm1hRfxn/D4XzuX5fDIpwfqzaCm/NmP1XXtZgzjovxSfbB8U0prwtVflfkH 60hXV4k7zq5lkhdeQ7C4gFcUOgmm07tmw60JgXb90t5AhqwUKjLGs0cMKjvEylD5VvoW FJnzjL6y4q0i+O3pQEP5SdBuf2sQ5DLEzBTc601cl8Y+oEV5EYkL9kdNZ7XuZqAIRrZq MlC/UKr9FWQGX5Uz7LHbdrhG/nVAEcJgAmsg5Lf+wItIYF15RH2YTzu9l81NnNxLAWYx l4HQQbVIJcZ9uhbvNhany84aghXy+u6a3vVZniSkrKNHnPG9G6NpX+gPK0RxnDZDO1+/ v2ig==
X-Gm-Message-State: AMke39nfy1GsFPhkKGZimG1ONi9T5SaQsE73mvPsPN2bhpLgUt+NWNlE6GXX34KAWofJz4tSCQcK/MozZYsRVeMj
X-Received: by 10.55.139.70 with SMTP id n67mr29737975qkd.286.1489423724107; Mon, 13 Mar 2017 09:48:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.36.203 with HTTP; Mon, 13 Mar 2017 09:48:23 -0700 (PDT)
In-Reply-To: <fa44cd7ea1c740ec8fd244ebd57f79d7@HE101654.emea1.cds.t-internal.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> <CAAP42hDyRzVGT3P5pL5afb6GVBFV7mYFcwLvYp0djEJ60yBgBQ@mail.gmail.com> <fa44cd7ea1c740ec8fd244ebd57f79d7@HE101654.emea1.cds.t-internal.com>
From: William Denniss <wdenniss@google.com>
Date: Mon, 13 Mar 2017 09:48:23 -0700
Message-ID: <CAAP42hCcoD59c3P=SShDKm8_4N-rvWjjxL=5XLD6+m=4yuu5JQ@mail.gmail.com>
To: Axel.Nennker@telekom.de
Content-Type: multipart/alternative; boundary=94eb2c088490ff40dc054a9f7b74
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SlWfe1gBaZxCGz01e3GDw_CZfGE>
Cc: "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: Mon, 13 Mar 2017 16:48:51 -0000

Thanks! I've corrected that in my local copy.

On Mon, Mar 13, 2017 at 1:35 AM, <Axel.Nennker@telekom.de> wrote:

> Hi,
>
>
>
> There is an extra “where” in this Terminology definition:
>
>
>
> "reverse domain name notation"  A naming convention based on the
>
>       domain name system, but where where the domain components are
>
>       reversed, for example "app.example.com" becomes "com.example.app".
>
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-09
>
>
>
> cheers
>
> Axel
>
>
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Tuesday, March 07, 2017 9:35 PM
> *To:* John Bradley
>
> *Cc:* internet-drafts@ietf.org; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
>
>
>
> 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%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM
> 3OruoK%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%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nmi%
> 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%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%
> 2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%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%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru0Vm4%
> 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%7Ceff092e6b2894ace8f8408d464cda4d5%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=
> 14GztZLY%2BnQNbhR5bqjS7cRYUSlotpr6JXtFXpduGuI%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
>
>
>