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=40aol.com@xxxxxxxxxxxxxx>]

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@xxxxxxxxx <nvnagr@xxxxxxxxx> On Behalf Of Naveen Agarwal
Sent: Thursday, May 31, 2018 12:39 AM
To: William Denniss <wdenniss=40google.com@xxxxxxxxxxxxxx>
Cc: Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx>; ietf@xxxxxxxx; draft-ietf-oauth-device-flow@xxxxxxxx; oauth <oauth@xxxxxxxx>; oauth-chairs@xxxxxxxx
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@xxxxxxxxxxxxxx> wrote:

 

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <bcampbell@xxxxxxxxxxxxxxxx> 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).  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@xxxxxxxxxxxxxx> wrote:

> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> andrewsciberras@xxxxxxxxxxxxxxxx> 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>)
>> 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@xxxxxxxxxx>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <andrewsciberras@xxxxxxxxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth