Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 03 January 2018 11:50 UTC

Return-Path: <shollenbeck@verisign.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 579E2126C19 for <oauth@ietfa.amsl.com>; Wed, 3 Jan 2018 03:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 dKvZS0Henuun for <oauth@ietfa.amsl.com>; Wed, 3 Jan 2018 03:50:13 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C27B126579 for <oauth@ietf.org>; Wed, 3 Jan 2018 03:50:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=12676; q=dns/txt; s=VRSN; t=1514980213; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=494AjVBheRSS9BNU/UNZ9ukGDzsKt/Mup6rZ8PAvQkM=; b=jBMmP/euUGGjWNjnot8Sx8KvVvKc0fpdJiQh9eXBGsHMuIcXr6/aIFBJ QGoDA/JCgwBynsaC1sstpQmKz2BRJCxT/lH3ghTcVDZbVb4nFSYXo1nX3 KdlAFdRTlM/FTW6JXMWTy9wT2QBLL7aCzMl0wBWiHCQO9GbWbHSqaZRus h4W3IhGkd2LXbtmQNUFGmkSNY+wadL3UWARQ7Mcp7nd4ln4RACiWit7+m q/ZT/gTmLz2RBUPbZ2SpEJjLKzUt209T2uCof/jZ6txMePOpGFGsdnBYu layDBowzUlMaR4bZNJ/MopwHYzc/qEtiwTcE++jKo7Am5erIJHwSdYRR2 g==;
X-IronPort-AV: E=Sophos;i="5.45,501,1508803200"; d="scan'208,217";a="5552964"
IronPort-PHdr: =?us-ascii?q?9a23=3Ax/SPrB1IHXL8ZzNlsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seMWLvad9pjvdHbS+e9qxAeQG9mDsrQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPfglEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLmiD?= =?us-ascii?q?kJOSMl8G/ZicJwgqBUoBO9qBNw2IPbep2ZOf5kc6/BYd8XR2xMVdtRWSxbBYO8?= =?us-ascii?q?apMCA+QDM+Zfq4n9o0UBrR2lCgayGOzvySdEjWLr06Im1OQhDR3G0AI9FN8Jq3?= =?us-ascii?q?TUrNL1NKMWUe+ryqnH1ivMYO9V2Trm9ojHbAohofCXXbJxfsrRz1MjGB/CjlWV?= =?us-ascii?q?sIHoOS6e2OoKs2ie9eVgVOSvhnYmqw5vvjivyN0gio7ThoIazF3P6CZ3wJ4tKN?= =?us-ascii?q?GlVEJ3e8OoHZleui2AKod7Qs0vT3t2tCs1xbAKoYO3cDQQxJg6xRPTd+aLf5WH?= =?us-ascii?q?7x/gTuqdPDR1iXR4c7ylnRmy61KvyujkW8mx11ZFszRKn8HXtnAIyxzT8s+HSu?= =?us-ascii?q?Zh/ku52TaAyQTT6uZcLE8vj6rbLYMtwro/l5oWq0vDHyv2mELrjK+Kakko5/Kk?= =?us-ascii?q?6/r5bbX8p5+cLI50ig74Mqg0hsO/BuE4PhAPX2id5+u8yKXu8VDlTLlQk/E7kK?= =?us-ascii?q?fUvIrHKckbqKO1GRFZ34ks5hqnCjepytUYnX0JLFJffxKHipDkO0rOIPD/Cfe/?= =?us-ascii?q?h0qjkDFwyP/YIrLhAY7ALmbdn7f7fLZ98E9cyAU1zdxF+51UDbQBLOrpWkDtrN?= =?us-ascii?q?zYEgM5MwuszubgEtp9y58eWWKUD6+YLqzSrVGI6vgoI+mWa48foCz9JOQ95/7y?= =?us-ascii?q?kX85nkcQfKe00pQJbnC4GPVmI16CYXf3jdcBFmAKvgU6TOP0klGNTTlTZ3PhF5?= =?us-ascii?q?47s3t0F46rC4HCXZuFj7uG0yO2WJZRYy8MQgSTHXrucYSfQN8DbyWdJsInmTsB?= =?us-ascii?q?A+uPUYgkgFuOswv+xrxtI+HXvmUjvpX/yJI9s/bTkhU2+Dp+As+e+3+AVWBvn2?= =?us-ascii?q?wOATQx2fYs8gRG1l6f3P0g0LRjHttJ6qYRXw=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2F+AQCJwkxa//SZrQpdGgEBAQEBAgEBAQEIAQEBAYJKgVq?= =?us-ascii?q?BGweECookkRuDS5NfFAOBfgojhRgCGoRVGAEBAQEBAQEBAQECgRCCOCIRS1kBA?= =?us-ascii?q?QEBAQEjAj4sAQEBAQMjCkwQAgEIDQQEAQELCxIDAgICMBQJCAIEDgUIiUJ0sUq?= =?us-ascii?q?CJ4o7AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEDwSDaYRgNoMvAYEpLxg0CYJYM?= =?us-ascii?q?YI0BaNLBgKIAaE0jSeJMgIECwIZAYE8H2yBHW9ID30BgSEFglEDHBmBTngBiCW?= =?us-ascii?q?BFgEBAQ?=
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id w03BoBhT006945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2018 06:50:11 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 3 Jan 2018 06:50:19 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'wdenniss@google.com'" <wdenniss@google.com>
CC: "'oauth@ietf.org'" <oauth@ietf.org>
Thread-Topic: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)
Thread-Index: AQHThBpxELf8pyWbhkmDcfE5dc3/B6NiBzZA
Date: Wed, 3 Jan 2018 11:50:18 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F7F91910D@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <831693C2CDA2E849A7D7A712B24E257F7F8F16EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <CAAP42hCoX9TjM2WtJYFKS1tCGztd4CthdSCzQnuVw8AyJ=jZyA@mail.gmail.com>
In-Reply-To: <CAAP42hCoX9TjM2WtJYFKS1tCGztd4CthdSCzQnuVw8AyJ=jZyA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F7F91910DBRN1WNEXMBX01vc_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bFng8sYe_SsFxWZ0b_g8eyq_ygk>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)
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, 03 Jan 2018 11:50:15 -0000

From: William Denniss [mailto:wdenniss@google.com]
Sent: Tuesday, January 02, 2018 5:38 PM
To: Hollenbeck, Scott <shollenbeck@verisign.com>
Cc: oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)



On Mon, Nov 27, 2017 at 6:32 AM Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote:

   I have reviewed draft-ietf-oauth-device-flow-07. Just one comment regarding Section 5.1:

   Would it be possible to suggest some minimally acceptable entropy value? The text says "The user code SHOULD have enough entropy that when combined with rate limiting makes a brute-force attack infeasible", but just how much entropy is enough?



   There are a few challenges with requiring a minimum entropy of the user_code due to the fact it's user-visible. Normally we would just set a nice high number (like OAuth did<https://tools.ietf.org/html/rfc6749#section-10.10>) and that would be fine, as normally a few extra bytes on the token is no problem. With the user_code however, the longer it is the harder it is to use. My expectation is that the authorization server would determine their own acceptable amount of entropy, trading off security for usability and taking into account the expiry time of the code, and any brute-force mitigations they have in place such as rate limiting.



   Do you have any text to suggest?



   [SAH] I agree that there’s not a singular recommendation to be made here. Since that’s the case it’s appropriate to provide guidance that describes the trade-offs to be made by an implementer. The text you wrote above does that nicely, so I would suggest something like this:



   “There are trade-offs to be considered in determining just how much entropy is “enough”. With the user_code, the longer it is the harder it is to use. The authorization server can thus determine their own acceptable amount of entropy, trading off security for usability and taking into account the expiry time of the code and any brute-force mitigations they have in place such as rate limiting.”



   A related question: the last call made me wonder if there are any plans to add a device flow for OpenID Connect. Does anyone know if such a thing is in the works?



   The Google implementation of the device flow already supports OpenID Connect. Just add "openid" to the scopes in the request as you normally would, and you'll get an ID Token on the response.



   There isn't any effort that I'm aware of to document this. We could do it I guess if there was demand, it would be quite a short document.



   [SAH] Thanks!