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>om>; ietf@ietf.org; 
> draft-ietf-oauth-device-flow@ietf.org; oauth <oauth@ietf.org>rg>; 
> 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