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 <[e-mail]>]

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:* [e-mail] <[e-mail]> *On Behalf Of *Naveen Agarwal
> *Sent:* Thursday, May 31, 2018 12:39 AM
> *To:* William Denniss <wdenniss=[e-mail]>
> *Cc:* Brian Campbell <[e-mail]>; [e-mail]; 
> [e-mail]; oauth <[e-mail]>; 
> [e-mail]
> *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=[e-mail] 
> <mailto:wdenniss=[e-mail]>> wrote:
>
>     On Wed, May 30, 2018 at 3:48 PM, Brian Campbell
>     <[e-mail] <mailto:[e-mail]>>
>     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=[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         > Hi Andrew,
>         >
>         > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
>         > [e-mail]
>         <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>>
>         >> wrote:
>         >>
>         >>> Hi Andrew,
>         >>>
>         >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras
>         <[e-mail]
>         <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth