Subject: [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

From: The IESG <[email-masked]>
Date: Tue, 29 May 2018 15:20:30 -0700

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices'
  <draft-ietf-oauth-device-flow-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-06-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This OAuth 2.0 authorization flow for browserless and input
   constrained devices, often referred to as the device flow, enables
   OAuth clients to request user authorization from devices that have an
   Internet connection, but don't have an easy input method (such as a
   smart TV, media console, picture frame, or printer), or lack a
   suitable browser for a more traditional OAuth flow.  This
   authorization flow instructs the user to perform the authorization
   request on a secondary device, such as a smartphone.  There is no
   requirement for communication between the constrained device and the
   user's secondary device.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile
 (None - )
    rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF stream)

---

From: Eric Fazendin <[email-masked]>
Date: Wed, 30 May 2018 09:48:50 -0600

Hi, just found a minor typo:

Section 6.1:

*through* their length needs to be longer to maintain a high
   entropy.

Should be:

*though* their length needs to be longer to maintain a high
   entropy.

On Tue, May 29, 2018 at 4:20 PM, The IESG <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 May 2018 13:56:34 -0600

In reading the draft (again) I noticed a couple of things that, while maybe
not substantive, seemed like they were worth raising here in last call:

1:
In Section 3.5
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09#section-3.5> a
new 'expired_token' error code is defined for when the 'device_code' has
expired and the client will need to start the flow over. Shortly after the
new error code definition there is text in that section that says 'If the
verification codes have expired, the server SHOULD respond with the
standard OAuth error "invalid_grant".  Clients MAY then choose to start a
new device authorization session.'

This reads to me like: here's a new error for expired device code but this
other code SHOULD be used for expired device code. Am I confused or
otherwise missing something?

I kinda suspect that the intent is that expired_token can be returned for
codes that are known to be expired while invalid_grant is more of a catch
all for codes that may have expired long enough ago that they have been
purged from server memory/persistence or are otherwise unknown. That's my
guess anyway. But the current text seems somewhat contradictory, which I
think could be clarified/fixed.

2:
In section 5
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09#section-5.5>
about security considerations for Non-confidential Clients there's a
pointer to recommendations from Section 8.9 of [RFC8252]
<https://tools.ietf.org/html/rfc8252#section-8.9>, which is about using the
"state" parameter in the authorization request to protect against cross-app
request forgery.  That doesn't seem right or relevant to the device flow,
does it? Was it intended to point to section 8.5 in RFC8252
<https://tools.ietf.org/html/rfc8252#section-8.5>? Or something else?

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 31 May 2018 07:35:39 +1000

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.

It doesn’t seem that any of these options are appropriate to convey that a
user has refused to grant access to the device.

The Google implementation appears to be using the access_denied error code
from section 4.1.2.1 of RFC6749. While this would seem to be the most
suitable error code, the document does not explicitly indicate it as a
permitted response.

I believe that clarifying the response error code in the condition where a
user has refused access to the client would be beneficial, remove
ambiguity, and promote greater consistency across implementations.

Regards

Andrew Sciberras

---

From: William Denniss <[email-masked]>
Date: Wed, 30 May 2018 15:06:18 -0700

Hi Andrew,

On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras
<[email-masked]> wrote:

Hello
> suitable error code, the document does not explicitly indicate it as a

Actually, this is indicated explicitly I believe:

If the user has approved the grant, the token endpoint responds with a
success response defined in Section 5.1 of [RFC6749]; *otherwise it
responds with an error, as defined in Section 5.2 of [RFC6749].* In
addition to the error codes defined in Section 5.2 of [RFC6749], the
following error codes are specific for the device flow:

> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 31 May 2018 08:18:54 +1000

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/OAuth2ForDe
vices#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.

Andrew

On Thu, May 31, 2018 at 8:06 AM, William Denniss <[email-masked]>
wrote:

> Hi Andrew,
>
> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <[email-masked]> 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?
>>
>>
>> It doesn’t seem that any of these options are appropriate to convey that
>> a user has refused to grant access to the device.
>>
>>
>> The Google implementation appears to be using the access_denied error
>> code from section 4.1.2.1 of RFC6749. While this would seem to be the most
> responds with an error, as defined in Section 5.2 of [RFC6749].*
>
In addition to the error codes defined in Section 5.2 of [RFC6749], the
>> I believe that clarifying the response error code in the condition where
>> a user has refused access to the client would be beneficial, remove

---

From: William Denniss <[email-masked]>
Date: Wed, 30 May 2018 15:27:19 -0700

Hi Andrew,

On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
[email-masked]> wrote:

> implementation (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.

---

From: William Denniss <[email-masked]>
Date: Wed, 30 May 2018 15:31:41 -0700

Hi Brian,

On Wed, May 30, 2018 at 12:56 PM, Brian Campbell <[email-masked]

> In reading the draft (again) I noticed a couple of things that, while
> maybe not substantive, seemed like they were worth raising here in last
> call:
>
>
> 1:
> In Section 3.5
> <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09#section-3.5>
> a new 'expired_token' error code is defined for when the 'device_code' has

I agree that the way it's documented "expired_token" would be for when you
know it's expired, whereas "invalid_grant" is a more generic catch all. I
think this section needs to be revisited to clear up this ambiguity. Before
proposing a solution, I want to investigate a little what the existing
implementations are doing around this case.

2:
> <https://tools.ietf.org/html/rfc8252#section-8.9>, which is about using
> the "state" parameter in the authorization request to protect against
> cross-app request forgery.  That doesn't seem right or relevant to the
> device flow, does it? Was it intended to point to section 8.5 in RFC8252
Good catch.

That text was introduced in 04, https://tools.ietf.org/html/
draft-ietf-oauth-device-flow-04#section-5.4 and Section 8.9 of the 07 draft
version of native apps at the time was "Client Authentication
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.9>",
which is now Section 8.5 of RFC8252.  I will update this draft to point to
Section 8.5, per the original intent.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 May 2018 16:48:22 -0600

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.

On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=[email-masked]> wrote:

>> 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
>> 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.
>>
>>
>
> I will plan to update the doc to reference 4..1.2.1 instead.  Good catch!
> Thank you.
>
>
>>
>>>> It doesn’t seem that any of these options are appropriate to convey
>>>> that a user has refused to grant access to the device.
>>>>
>>>>
>>>> I believe that clarifying the response error code in the condition
>>>> where a user has refused access to the client would be beneficial, remove
>>>> review, use, distribution or disclosure by others is strictly prohibited..
>> review, use, distribution or disclosure by others is strictly prohibited..

---

From: William Denniss <[email-masked]>
Date: Wed, 30 May 2018 17:06:28 -0700

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <[email-masked]>
wrote:

> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>
> ).  Also
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?

> >> <https://developers..google.com/identity/protocols/OAuth2For
> Devices#step-6-handle-responses-to-polling-requests>)
> >>>> expired_token) may be returned in a response to a device token request
>

---

From: Naveen Agarwal <[email-masked]>
Date: Thu, 31 May 2018 00:38:59 -0700

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=[email-masked]> wrote:

>
> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <
> [email-masked]> wrote:
>
> 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
>> >> a (more appropriate) error code that exists outside of section 5.2..
>> >>
>> >>
>> >

---

From: Brian Campbell <[email-masked]>
Date: Thu, 31 May 2018 10:49:35 -0600

> Do you have any proposed text to resolve this?

Sure, here's a crack at some text/changes:

Add this to the list of error codes in section 3.5.:

        "access_denied
               The end-user denied the authorization request."

And add this to section 7.2.1.:

  "o  Error name: access_denied
   o  Error usage location: Token endpoint response
   o  Related protocol extension: [[ this specification ]]
   o  Change controller: IETF
   o  Specification Document: Section 3.5 of [[ this specification ]]"

I might also slightly change this text in section 3.5:

"In addition to the error codes defined in Section 5.2 of [RFC6749],
   the following error codes are specific for the device flow:"

to

"In addition to the error codes defined in Section 5.2 of [RFC6749],
   the following error codes are specified by the device flow:"

so that the wording doesn't read as prohibiting the error codes from being
used outside the device flow (access_denied from the token endpoint might
well be useful for other grant types).

And add "Andrew Sciberras" to the Acknowledgements.

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 May 2018 18:20:14 +0000

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: [email-masked] <[email-masked]> On Behalf Of Naveen Agarwal
Sent: Thursday, May 31, 2018 12:39 AM
To: William Denniss <wdenniss=[email-masked]>
Cc: Brian Campbell <[email-masked]>; [email-masked]; [email-masked]; oauth <[email-masked]>; [email-masked]
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=[email-masked]<mailto:wdenniss=[email-masked]>> wrote:

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

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.

On Wed, May 30, 2018 at 4:27 PM, William Denniss <
wdenniss=[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi William
>>
>> <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>>)
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hello
>>>>
>>>>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Thu, 31 May 2018 15:01:08 -0400

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:* [email-masked] <[email-masked]> *On Behalf Of *Naveen Agarwal
> *Sent:* Thursday, May 31, 2018 12:39 AM
> *To:* William Denniss <wdenniss=[email-masked]>
> *Cc:* Brian Campbell <[email-masked]>; [email-masked]; 
> [email-masked]; oauth <[email-masked]>; 
> [email-masked]
> *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
>
> 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=[email-masked] 
> <mailto:wdenniss=[email-masked]>> wrote:
>
>     On Wed, May 30, 2018 at 3:48 PM, Brian Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>). 
>         Also
>     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.
>
>         wdenniss=[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         > Hi Andrew,
>         >
>         > [email-masked]
>         <mailto:[email-masked]>> wrote:
>         >
>         >> Hi William
>         >>
>         <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>>)
>         >> On Thu, May 31, 2018 at 8:06 AM, William Denniss
>         <[email-masked] <mailto:[email-masked]>>
>         >> wrote:
>         >>
>         >>> Hi Andrew,
>         >>>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         >>>
>         >>> Hello
>         >>>>
>         >>>>
>     [email-masked] <mailto:[email-masked]>