Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-device-flow-10

[Robert Sparks]

Answering your question inline:


On 8/1/18 6:55 PM, William Denniss wrote:

Robert,

Thank you for your valuable feedback. Version 12 incorporates your 
feedback. Replies inline:


On Mon, Jun 11, 2018 at 9:20 AM, Robert Sparks > wrote:


Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

>.

Document: draft-ietf-oauth-device-flow-10
Reviewer: Robert Sparks
Review Date: 2018-06-11
IETF LC End Date: 2018-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC, but
with nits to
consider

Nits/editorial comments:

In 3.5 "the client MUST use a reasonable default polling interval"
is not
testable. Who determines "reasonable"? At the very least, you
should add some
text about how to determine what "reasonable" is for a given
device, and add
some text that says don't poll faster than earlier responses
limited you to.
For example, if the response at step B in the introductory diagram
had an
explicit interval of 15, but a slow-down response to an E message
didn't have
an explicit interval, you don't want them to default to, say 5
seconds (because
that's what the example in section 3.2 said, so it must be
reasonable).


Thanks for the feedback, version 12 specifies a default of 5s.

In 3.3, you say the device_code MUST NOT be displayed or
communicated. Is there
a security property that's lost if there is? Or is this just
saying "Don't
waste space or the user's time"?


It's just a waste of the user's time. This text has been modified.


The last paragraph of section 6.1 feels like a recipe for false
positives, and
for bug-entrenched code. Please reconsider it.


I've reworded it a bit, but it's actually an important usability 
consideration so I do want to keep it in some form.


You need line-folding in the example in section 3.2


Can you clarify what you mean by this?
There was a line in a previous version (I thought I saw it in -10, but 
right now I only see it in -09) that was too long to be published as-is 
in an RFC. It looks like it's fixed in -12.




Best,
William


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

[OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-device-flow-12: (with DISCUSS)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-oauth-device-flow-12: 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:
--

Thanks to the authors for addressing my comments and half of my DISCUSS.
This final issue appears to remain unaddressed:

§3.1:

>  The client initiates the flow by requesting a set of verification
>  codes from the authorization server by making an HTTP "POST" request
>  to the device authorization endpoint.  The client constructs the
>  request with the following parameters, encoded with the "application/
>  x-www-form-urlencoded" content type:

This document needs a normative citation for this media type.

My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as this
appears to be the most recent stable description of how to encode this media
type. I'd love to hear rationale behind other citations being more appropriate,
since I'm not entirely happy with the one I suggest above (given that it's been
superseded by HTML 5.2); but every other plausible citation I can find is even
less palatable (with HTML 5.2 itself having the drawback of not actually
defining how to encode the media type, instead pointing to an unstable,
unversioned document).




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

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

[William Denniss]

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Device Flow for Browserless and Input 
Constrained Devices
Authors : William Denniss
  John Bradley
  Michael B. Jones
  Hannes Tschofenig
Filename: draft-ietf-oauth-device-flow-12.txt
Pages   : 20
Date: 2018-08-01

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-oauth-device-flow-11: No Objection

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/



--
COMMENT:
--

Major Comment:

I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I have a
slightly different spin on it. The device polls the server while waiting on the
user to take action. Users are notoriously slow about that sort of thing. They
might plug in a device then walk away for hours, days, or forever.  Now,
consider that we are talking about IoT devices, so there may be millions of
them. If they are fate shared in some way (imagine shipping day for a new
popular product, or a software update that forces reauthorization, or a server
coming back online after getting whacked the last time around), there could be
millions of them trying this at the roughly the same time.

Given all that, I think the draft really needs to give more detailed guidance
on what sort of refresh rates, maximum attempts, expirations, back off
patterns, etc might be reasonable from both network congestion and server
overload perspectives.

Other Substantive Comments:

§3.1: What sort of events are expected to trigger the flow? In particular, I
wonder if there should be guidance to make it unlikely to start the process by
accident. For example, if the authorization process is kicked off by a device
simply being plugged into power, a user might plug it in then walk away before
realizing they had more to do. (See my major comment).

§3.3: What sort of bad thing could happen if the device_code is communicated to
a user? Do implementers need to worry about people  guessing device-codes?

§3.3, last paragraph: The "NOT RECOMMENDED" seems overly strong, given that the
next section describes a perfectly good way to do exactly that. Maybe something
like "NOT RECOMMENDED unless the device uses a non-textual mechanism for
conveying the URL and code, such as that described in ..." would make sense?

§5.4: Are devices expected to know the operating environment in advance of
deployment?

Editorial Comments:

§1, 3rd paragraph: The first sentence is hard to parse due the list of long,
complex phrases. Please consider breaking into simpler sentences.

§2: There are lower case instances of normative keywords.  Please consider
using the updated boilerplate from RFC8174.


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