Re: [OAUTH-WG] First look at: draft-ietf-oauth-device-flow

Mike Jones <Michael.Jones@microsoft.com> Mon, 23 April 2018 19:18 UTC

Return-Path: <Michael.Jones@microsoft.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 82D14126B6E for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2018 12:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 NE2IkyQKelaa for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2018 12:17:55 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0612012D946 for <oauth@ietf.org>; Mon, 23 Apr 2018 12:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rHBjWh4a7gwywUpLKeNVz/wfZ77JiJI69x0s01tBVSE=; b=MqZLwGahZD5KDGbMaz5TVyu0Z6RglHFDV+YFk5s0A0FV+bQreqtqhHJPpCW8rzDMCtU2qOEXf09ZeaVXM9qXF+/y1kIrSrmvvMK84AufcJMGptsABbt5aByMHcOZwNDb8kEgkzt1nl+B4jbtc1rP688NLlmJE4H//hM8Lf0wWEk=
Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0422.namprd00.prod.outlook.com (2603:10b6:4:a0::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.746.0; Mon, 23 Apr 2018 19:17:49 +0000
Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::e0eb:d2f7:29c5:1a1b%2]) with mapi id 15.20.0747.000; Mon, 23 Apr 2018 19:17:49 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, John Bradley <ve7jtb@ve7jtb.com>, "draft-ietf-oauth-device-flow@tools.ietf.org" <draft-ietf-oauth-device-flow@tools.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: First look at: draft-ietf-oauth-device-flow
Thread-Index: AQHTrcMK5xJMkV2cYk2pb66wzOmOVqPX4ZsAgDcxzYA=
Date: Mon, 23 Apr 2018 19:17:48 +0000
Message-ID: <DM5PR00MB02962EBC0BA5B8D51C09E57DF5890@DM5PR00MB0296.namprd00.prod.outlook.com>
References: <CABcZeBMgakbA-+xQbVy7TLfdgScFp6gvMaYXz640VbQcsuMN9g@mail.gmail.com> <5aafe3ee.84b2df0a.59648.3412@mx.google.com>
In-Reply-To: <5aafe3ee.84b2df0a.59648.3412@mx.google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-04-23T19:17:47.6620374Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:6::36]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR00MB0422; 7:5rNeSo3rBnKvbNvF2F5JmH49H8x9zXxYUmMt4bpI0MQredtOvScUwnzqQ++nPqdLGS9480mKnN6E/X+5Ib8vxL+NV4dI0pJwjNZsyr0bslRjhwwITLjAk5ljFAdgKcoB6jvzDA0rt0hLCRyZ3dBk1hO402FDwRMjj/hzeOjuqyzcnWFoacmtJLf12z5QG1Mm5uh0Ev/CH8ZUALj2dIWSNZatsTFEFK1kmMuhAPsEvDKXIUhV9Noq7gzQPoSSa+Bx; 20:CRRWvf0oWxvW66lu6zBgL1xoXO7NaWAFhA9901sR6HDHj40mkVFNSuXPaL69J5evO2NjkuJYWEz0EItsqFULP5h56bVd2kVNsq0P0TyjJXDu8EkA3BQd3c+HSUCzo6B8YyzCTfbR0f8VDGX3hsQfIpc1RJGD38x0To3utCQ3A2o=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0422;
x-ms-traffictypediagnostic: DM5PR00MB0422:
authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=microsoft.com;
x-microsoft-antispam-prvs: <DM5PR00MB042211446A100F3C4F024428F5890@DM5PR00MB0422.namprd00.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(156600954879566)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR00MB0422; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0422;
x-forefront-prvs: 06515DA04B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(396003)(39380400002)(25786009)(9326002)(606006)(966005)(72206003)(3660700001)(8936002)(478600001)(8676002)(3280700002)(6306002)(2906002)(33656002)(86612001)(790700001)(6116002)(81166006)(10290500003)(7736002)(5660300001)(9686003)(53546011)(54896002)(76176011)(7696005)(236005)(52396003)(476003)(11346002)(53936002)(446003)(6246003)(22452003)(55016002)(110136005)(74316002)(59450400001)(6506007)(102836004)(5250100002)(316002)(2501003)(46003)(186003)(2201001)(86362001)(2900100001)(6436002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0422; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv;
x-microsoft-antispam-message-info: RDsZverXAo0ErHTwcYV7omUwP8YA13IfWAoR4HVOaXWhUT0/UjWUER9l6oHF3SkyYFpn1of5ssAwvEgf5OJg/cpuUZzXDZ9Q9b6c4Px1gsU2YT452X2wZes6OPOg/9L2fWnHfOaxb5PTXNWZD/E07K+BscNa0J7dLrQGKHxK0zu0vejiURXvuezEgpfDPYN+
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02962EBC0BA5B8D51C09E57DF5890DM5PR00MB0296namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1d37d701-f688-4e25-246f-08d5a94ee70a
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d37d701-f688-4e25-246f-08d5a94ee70a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2018 19:17:49.0277 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0422
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NiZXF5KJUr9ikoaF_RAvkWzkU74>
Subject: Re: [OAUTH-WG] First look at: draft-ietf-oauth-device-flow
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: Mon, 23 Apr 2018 19:18:01 -0000

Hi Ekr,

https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09  Sections 5.2 and 5.3 have been updated as proposed below.

                                                                -- Mike

From: John Bradley <ve7jtb@ve7jtb.com>
Sent: Monday, March 19, 2018 9:23 AM
To: Eric Rescorla <ekr@rtfm.com>; draft-ietf-oauth-device-flow@tools.ietf.org
Subject: RE: First look at: draft-ietf-oauth-device-flow

If an Authorization Server is malicious, then it could man-in-the middle the backchannel flow to another AS.

Note that the device manufacturer must either be the attacker or be using an authorization server that is controlled by an attacker for this attack to be possible.  We can amplify Section 5.2 (Device Trustworthiness) to make this explicit.  In part, the person purchasing the device is counting on it and its business partners to be trustworthy.

As a concrete example, Netflix could man-in-the middle Amazon Prime to get an access token as the user’s device.   For that to work, the user would need to select Netflix on the TV and get back the URI for Amazon Prime video to enter.  They would hopefully notice that they are being sent to the wrong site.

We could expand Section 5.3 (Remote Phishing) to encourage the AS to display information about the device/client so that they would notice if a software client was impersonating a Roku. We currently only talk about informing the user that they are authenticating a device.

This is not the only place in OAuth where we have issues with clients being able to impersonate other clients.  To completely prevent this attack, we would need a client attestation or some form of client credential like a certificate using MTLS for authentication.

Dynamic client registration based on a software statement containing the clients public key would work but raises the deployment bar significantly.

John B.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Eric Rescorla<mailto:ekr@rtfm.com>
Sent: Saturday, February 24, 2018 10:58 PM
To: draft-ietf-oauth-device-flow@tools.ietf.org<mailto:draft-ietf-oauth-device-flow@tools.ietf.org>
Subject: First look at: draft-ietf-oauth-device-flow


I am concerned about the security of this mechanism. In S 5.3 you
describe a phishing attack, but it seems like there is a confused
deputy attack when a user has accounts on two services, A and B, where
A gets the user to authenticate to B for them:


Client                   A                          B

Client Identifier (A) --->
                           Client identifier (B) --->
                           <- Verification URI + Code
<- Verification URI + Code
User authorization --------------------------------->
                           Poll -------------------->
                           <------------ Access Token

The idea here is that A connects to B claiming to be Client
and then gets the authorization information for the Client->B
interaction, which it convinces Client to supply to B along
with its ambient authority.

Is this a real attack? If not, what am I missing?

-Ekr