Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard
George Fletcher <gffletch@aol.com> Thu, 31 May 2018 19:11 UTC
Return-Path: <gffletch@aol.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 3E51C131585 for <oauth@ietfa.amsl.com>; Thu, 31 May 2018 12:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 rF32sDmI5NfJ for <oauth@ietfa.amsl.com>; Thu, 31 May 2018 12:11:15 -0700 (PDT)
Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 DEB44131581 for <oauth@ietf.org>; Thu, 31 May 2018 12:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527793873; bh=AVbRB/Uckvyne/bO5mhbFP2TgSI4ZEpCqWzMTv6GFM8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=KyuDa67P3icwSrsDnV03UJ+/nPwLXCF/B23XBPmYTJyGnfQ7ujMDq10dTy0bH3pDUx6G8mucdu8gJCpA+9Bm+Adrz5qivSjLqEUb8em6pTQQGl/RCLKHoUpQosjdhyDNQxQwHqFw27DsKtpR+hrQLxaiV6wIpkizwCBgCzffRMzFiuZ5BN0h6Hq61nNr/NoKhyGXW5YTxF1M0Zc+f0QwqwScSESb3XL5/Iv3UigaVmUx1c0ZWOrLAVcuRpOYuWQtQJYbSCCGlCCdHE5XxPBjMv2igWXni9AYkJS9dSLLl3HxkrTwyVWbiLwpLcvULRIRphtixyH00/a7/Nte7qb5xA==
X-YMail-OSG: vx96jZwVM1nZBJw4_pZK_BJ.dAYNf.9mX.8ivC9Jpk7YGsecQIBRCw4z3R7_iNN qSQrWL0qaKwBkc_pjy6bBbc9COFRtqNl6lW41aClHzYFZGexIBsGn5WCLbBYI0feAwEuYheqLSAq u2DdMR84Ae9hgJ0cnhZ3_80EmVTU4OTYIpvGcYneuIHeOIflw8NIS9A17EGCBxN9BEWdscxNeWyF R.sOx8fkK6VU3RXPVVnwGe.GFDalgswsQvixU26r_6rBBCVCC0FuwGJRtA.sW1zPQLaZeo1IP1pn PgzOXF8MtduEKEqBCFtbTv5MxkzTcWoGM.w5XhvOjtLmq.rwo86jQowJNfiggGTqKAj4zfj2pjSQ FswJJqD3zNU.KNwJwAS4N_LuBOHQxxYcW_z4T9WkVE8HDkoT2FZJlzC4SWT6oWbTriY8WkPU9LRw CpaF472f12L_IZmMg5itSx5E162tjGwE2HwAsxsPs02Pnsx1gEa4XmqLWSo5fD6n7kgENVfDKM9j hjjz19ez_vVxLycO3cQG.CmH6VfJ6dJCxcv_GH8NdPKXHJ8Q3HHE.q51MgnJ0QI7C8xcVD4jy79K RrkfdmVlpDLHC2_RweRbsnsggLxlMNg1KszA1KsKyii6U8qyR_IoiTK.ZanlcWSfMlKo0HIGaDZH x6Yg8GTnY0z87cPlEx16HETmEdJhSd5RVCqkl
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 31 May 2018 19:11:13 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e903c7e8a040f35db4f2b74cbb6d2c12; Thu, 31 May 2018 19:01:10 +0000 (UTC)
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, Naveen Agarwal <na@ohauth.com>, William Denniss <wdenniss=40google.com@dmarc.ietf.org>
Cc: "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, oauth <oauth@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-oauth-device-flow@ietf.org" <draft-ietf-oauth-device-flow@ietf.org>
References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> <CAEqOSkfwdn-+1zFBgpgk3Mr6HYy-OvKNdVRKZtdP9c6HVHC60Q@mail.gmail.com> <CAAP42hAA8FC8B8bhDdCAg=5TnDjZXr76UiMLNABEG23GRFdeyQ@mail.gmail.com> <CAEqOSkcquQ4GXhhOV30TsOEYSV5fuG_PtO7TFo_pE_zVAJd0zA@mail.gmail.com> <CAAP42hBznvLPe8JLy1HYxFQ2bWxGW5mbpa8hcAv6K8jM3EkQxw@mail.gmail.com> <CA+k3eCQ5xxj4nCUBvQn1QwUEL-ouLiZgean02rFwEjC6dcz9mw@mail.gmail.com> <CAAP42hAwPdvNX1Hr=dvPwghQcP_iHvbHvS_aXtKGf1uGfLidSw@mail.gmail.com> <CAKtfFtc973xykAjSjqpX3edwoX2M1Ay1m4x69AyV=C-ZArTzmQ@mail.gmail.com> <SN6PR00MB0301BA58FEB996D8BA88373DF5630@SN6PR00MB0301.namprd00.prod.outlook.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <b0cef203-2d41-0c42-b240-9e7e53dd1b7f@aol.com>
Date: Thu, 31 May 2018 15:01:08 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <SN6PR00MB0301BA58FEB996D8BA88373DF5630@SN6PR00MB0301.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------7B595F595053802EA1A23BAB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4QwrikPbgzdBLLOzPgZbOLZ3LAY>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard
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: Thu, 31 May 2018 19:11:19 -0000
I second the request to enhance the security considerations section to address any known issues identified with the flow (e.g. phishing, client impersonation, etc). The polling/state issues are likely not at the same scale for other providers, as they are for Google, so I think this flow still has future value. Thanks, George On 5/31/18 2:20 PM, Mike Jones wrote: > > Naveen, I have to disagree with your recommendation that we not finish > this work. People have been using variants of the device flow for > years. Standardizing it will improve interoperability. Also, > standardizing it will make the security considerations for using it > commonly available to implementers – whereas currently people are > mostly operating in the dark or based on their own intuitions of > what’s safe and what’s not. > > If you believe that there are specific things we should add to the > security considerations, please say what they are, and we can do so. > But saying “stop and wait for something else that isn’t defined yet” > isn’t a helpful or realistic position to take. > > -- Mike > > *From:* nvnagr@gmail.com <nvnagr@gmail.com> *On Behalf Of *Naveen Agarwal > *Sent:* Thursday, May 31, 2018 12:39 AM > *To:* William Denniss <wdenniss=40google.com@dmarc.ietf.org> > *Cc:* Brian Campbell <bcampbell@pingidentity.com>; ietf@ietf.org; > draft-ietf-oauth-device-flow@ietf.org; oauth <oauth@ietf.org>; > oauth-chairs@ietf.org > *Subject:* Re: [OAUTH-WG] Last Call: > <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for > Browserless and Input Constrained Devices) to Proposed Standard > > I have a general concern on making the device flow a standard as this > suffers from a number of issues that are quite fatal. At Google we > have limited this flow to be used for very basic/limited scopes as > phishing concerns are very real. Also the protocol suffers from > clients polling (overloading the servers) and server having to keep a > large amount of state. I think this protocol is close to its useful > end of life (at Google) and we are working on alternatives with > stronger client attestation that also mitigate other issues. > Separately, we have seen a lot more abusers/hackers use OAuth in > various forms to attack users. > > I don't know how many IDPs have implemented this flow but by making it > a standard, a lot more people will implement it and I'm sure they will > not be able to avoid the issues that are highlighted. > > Sorry, I know it has taken a lot of work to get the document to his > stage so my comments may feel too harsh and I apologize. Please do > know that I have been quite involved in this protocol from the > beginning and we have gone through a lot of pain and have been > discussing shutting this down fairly regularly. So this is to start > the conversation if we think this protocol is for the future or just > something from our past that we want to see it documented as a standard. > > Thanks > > Naveen > > On Wed, May 30, 2018 at 5:06 PM, William Denniss > <wdenniss=40google.com@dmarc.ietf.org > <mailto:wdenniss=40google.com@dmarc.ietf.org>> wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell > <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> > wrote: > > I realize this is somewhat pedantic but I don't think > referencing 4.1.2.1 > works given how RFC 6749 set things up. Rather I believe that > the device > flow needs to define and register "access_denied" as a valid > token endpoint > response error code (it's not a token endpoint response error > per RFC 6749 > sec 5.2 nor has it been registered https://www.iana.org/assignmen > ts/oauth-parameters/oauth-parameters.xhtml#extensions-error > <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>). > Also > invalid_grant is a a token endpoint response error from RFC > 6749 sec 5.2 so > that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 > <https://tools.ietf.org/html/rfc6749#section-4.1.2> defines > errors returned > from the authorization endpoint. But the device flow errors > are from the > token endpoint. > > Yes, that's true. It's still the token endpoint, so 5.2 does in > fact apply, it's just we're mixing in authorization-style actions > which were not previously considered/used for that endpoint. > > Do you have any proposed text to resolve this? > > > On Wed, May 30, 2018 at 4:27 PM, William Denniss < > wdenniss=40google.com@dmarc.ietf.org > <mailto:40google.com@dmarc.ietf.org>> wrote: > > > Hi Andrew, > > > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > > andrewsciberras@pingidentity.com > <mailto:andrewsciberras@pingidentity.com>> wrote: > > > >> Hi William > >> > >> You are right that the document explicitly indicates which > error codes > >> may be returned. However I think it's ambiguous as to which > error within > >> Section 5.2 of RFC6749 would apply in the scenario of a > user not granting > >> access. > >> > >> I think that this ambiguity is highlighted further by the > Google > >> implementation (https://developers.google.com > >> /identity/protocols/OAuth2ForDevices#step-6-handle- > >> responses-to-polling-requests > >> > <https://developers..google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests > <http://google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests>>) > >> not adhering to the explicit statement of the document and > electing to use > >> a (more appropriate) error code that exists outside of > section 5.2.. > >> > >> > > > > Oh, I see what you mean now. Yes, given this is an > authorization request, > > not a token request, the errors from Section 4.1.2.1 > > <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more > relevant. > > > > I believe it was the authors intention to reference that set > of errors, so > > I will plan to update the doc to reference 4..1.2.1 > instead. Good catch! > > > Thank you. > > > > > >> > >> On Thu, May 31, 2018 at 8:06 AM, William Denniss > <wdenniss@google.com <mailto:wdenniss@google.com>> > >> wrote: > >> > >>> Hi Andrew, > >>> > >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras > <andrewsciberras@pingidentity.com > <mailto:andrewsciberras@pingidentity.com>> wrote: > >>> > >>> Hello > >>>> > >>>> > >>>> Do we feel that the document should be more specific in > addressing how > >>>> the authorization service should respond to a device > access token request > >>>> when the user has refused to grant access to the device? > >>>> > >>>> > >>>> The document currently indicates in section 3.5 that a > success response > >>>> defined in section 5.1 of RFC6749, an error as defined in > section 5.2 of > >>>> RFC6749 (this includes invalid_request, invalid_client, > invalid_grant, > >>>> unauthorized_client, unsupported_grant_type, and > invalid_scope), or a new > >>>> device flow error code (authorization_pending, slow_down, and > >>>> expired_token) may be returned in a response to a device > token request > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Last Call: <draft-ietf-oauth-device-fl… The IESG
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Eric Fazendin
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Brian Campbell
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Andrew Sciberras
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… William Denniss
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Andrew Sciberras
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… William Denniss
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… William Denniss
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Brian Campbell
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… William Denniss
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Naveen Agarwal
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Brian Campbell
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… Mike Jones
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… George Fletcher
- Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-devic… William Denniss