Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT)

[William Denniss <[e-mail]>]

Benjamin,

Thank you for the feedback. We just posted version 12 which addresses many
of your feedback points. Replies inline.

On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk <[e-mail]> wrote:

>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Let me preface this by noting that I'm not sure that all of these points
> are actionable; I would, however, like to discuss them.
>
> I'm really unhappy to not see any hard numbers on the entropy needed
> in a user code to provide a reasonable security margin with given
> parameters, and how it compares to the guessability bounds considered best
> practices in general (across protocols).  For example, we think 128-bit
> symmetric keys are okay because an attacker has to put in 2**96 work to
> have a 2**-32 chance of guessing correctly via brute force; the rate
> limiting and finite lifetime on the user code places an artificial limit on
> the amount of work an attacker can "do", so if one uses a 8-character
> base-20 user code (with roughly 34.5 bits of entropy), the rate-limiting
> interval and validity period would need to only allow 5 attempts in order
> to get the same 2**-32 probability of success by random guessing.
> Section 5.1 would be a great place for such text, near the preexisting:
>    The user code SHOULD have enough entropy that when combined with rate
>    limiting and other mitigations makes a brute-force attack infeasible.
>
>
Thank you for the comment, the authors are still considering the right way
to address this feedback.



> We talk about "the authorization server", but any given *user* may have a
> relationship with multiple such ASes.  Can the Introduction make it more
> clear that the AS is associated with the device/client, and as such the
> it may not be the user's most-trusted AS?
>

Sometimes the device is really an app on the device. E.g. a Roku TV device
(a "tv stick") that has several apps. Hulu, where the AS is hulu, and
YouTube, where the AS is YouTube (these are both "first party" use-cases
where the app and the AS are owned by the same entity). The user may also
have a Canon printer, which has a device flow to Google, to authorize it to
print documents (a "third-party" use-case).

I'm not sure exactly what we should say in the introduction to address you
feedback here.

It also seems like a large latent risk with this flow is when the
> verification_uri_complete response is used along with an AS that assumes an
> authenticated user making such a verification request has approved the
> authorization (i.e., without an explicit user interaction to confirm), when
> that AS uses cookies or other persistent state to keep the user
> authenticated across multiple requests.  I could not find any MUST-level
> requirement for user interaction to confirm the device being authorized
> (even in Section 3.3, which covers the regular verificat_uri workflow!);
> please let me know if I missed something.  I would like to see some
> explicit text that (matching the flow described in Section 3.1 that
> requires the user to input the code) explicit user approval of the
> authorization is required.  (I do note that Section 5.3 has text about
> "SHOULD display information about the device.)
>

When verification_uri is used, the user has 2 steps (at least): 1. enter
code, 2. consent to the request. verification_uri_complete skips the first
step, but the presumption is that they would still consent to the request
in the second step. We can make this more clear if it isn't currently.

I'm also unhappy about the text in Section 1 that merely requires of the
> device the ability to "make outbound HTTPS requests", which leaves room for
> an awful lot of sins in certificate validation (and, potentially,
> ciphersuite selection).  Can we get a MUST-level requirement for
> authenticating the server and a cite to RFC 7525?
>

Reference to 7525 has been added.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please use the RFC 8174 boilerplate instead of the RFC 2119 one.
>

Done, thanks!


>
> Section 3.2
>
> The example expires in 30 minutes?  That seems longer than needed; wouldn't
> 5 minutes do?
>

Incidentally, 30 minutes is the value Google returns on the requests, which
was where this example came from.

In general I think it's good to have a reasonable window of time as the
user does need to find another device, open the browser, login to the AS
(possibly recover their passowrd), etc. There are some edge-cases in the
device flow too where if you enter the code right when it expires, you'll
get an error and need to start-over, and the longer the window of
opportunity the less this occurs.


>
> Section 3.3
>
> I agree with directorate reviewer that the MUST NOT requirement for
> displaying the device_code should justify that requirement by discussing
> the consequences of exposure.
>


Text has been updated, now reads:

   It is NOT RECOMMENDED for authorization servers to include the user
   code in the verification URI ("verification_uri"), as this increases
   the length and complexity of the URI that the user must type.  The
   next section documents user interaction with
   "verification_uri_complete", which is designed to carry this
   information.




>
> Section 3.5
>
>    authorization_pending
>       The authorization request is still pending as the end-user hasn't
>       yet completed the user interaction steps (Section 3.3).  The
>       client should repeat the Access Token Request to the token
>       endpoint.
>
> I feel like we want to mention the 'interval' here or some other discussion
> of an inter-request delay.
>

This text has been reorganized, with some duplication removed and I think
it reads better now.


> Also, please clarify "reasonable default polling interval", per multiple
> directorate reviews.
>

Done, we set it to 5s.


>
> Section 5.2
>
> Please clarify the entities involved in "the backchannel flow" that can be
> MITM'd.
>

The authors are still considering text to address this feedback.


>
> Section 5.6
>
> The "short-range" part of a "short-range wireless signal" partially depends
> on how big the receiver's antenna is.  So perhaps we should be careful
> about indicating that this has more security value than it does.
>

Dropped the reference to "short-range wireless signal".


>
> Section 6.1
>
> I'm not sure I understand the usage of "case-insensitive", here -- how
> would the user have an expectation of case-insensitivity?  Perhaps it is
> better to just say "majuscule" or "upper case" or whatever.
>
>
This section was reworded to hopefully address your feedback.

Best,
William