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

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-device-flow-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/



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

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?

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.)

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?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please use the RFC 8174 boilerplate instead of the RFC 2119 one.

Section 3.2

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

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.

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.

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

Section 5.2

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

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.

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.