Subject: Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)

From: William Denniss <[email-masked]>
Date: Tue, 2 Jan 2018 14:38:12 -0800

On Mon, Nov 27, 2017 at 6:32 AM Hollenbeck, Scott <[email-masked]>
wrote:

> I have reviewed draft-ietf-oauth-device-flow-07. Just one comment
> regarding Section 5.1:
>
> Would it be possible to suggest some minimally acceptable entropy value?
> The text says "The user code SHOULD have enough entropy that when combined
> with rate limiting makes a brute-force attack infeasible", but just how
> much entropy is enough?
>

There are a few challenges with requiring a minimum entropy of the
user_code due to the fact it's user-visible. Normally we would just set a
nice high number (like OAuth did
<https://tools.ietf.org/html/rfc6749#section-10.10>) and that would be
fine, as normally a few extra bytes on the token is no problem. With the
user_code however, the longer it is the harder it is to use. My expectation
is that the authorization server would determine their own acceptable
amount of entropy, trading off security for usability and taking into
account the expiry time of the code, and any brute-force mitigations they
have in place such as rate limiting.

Do you have any text to suggest?

> A related question: the last call made me wonder if there are any plans to
> add a device flow for OpenID Connect. Does anyone know if such a thing is
> in the works?
>

The Google implementation of the device flow already supports OpenID
Connect. Just add "openid" to the scopes in the request as you normally
would, and you'll get an ID Token on the response.

There isn't any effort that I'm aware of to document this. We could do it I
guess if there was demand, it would be quite a short document.

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 3 Jan 2018 11:50:18 +0000

From: William Denniss [mailto:[email-masked]]
Sent: Tuesday, January 02, 2018 5:38 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 Device Flow LC Comment (and OpenID Connect)

On Mon, Nov 27, 2017 at 6:32 AM Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

   I have reviewed draft-ietf-oauth-device-flow-07. Just one comment regarding Section 5.1:

   Would it be possible to suggest some minimally acceptable entropy value? The text says "The user code SHOULD have enough entropy that when combined with rate limiting makes a brute-force attack infeasible", but just how much entropy is enough?

   There are a few challenges with requiring a minimum entropy of the user_code due to the fact it's user-visible. Normally we would just set a nice high number (like OAuth did<https://tools.ietf.org/html/rfc6749#section-10.10>) and that would be fine, as normally a few extra bytes on the token is no problem. With the user_code however, the longer it is the harder it is to use. My expectation is that the authorization server would determine their own acceptable amount of entropy, trading off security for usability and taking into account the expiry time of the code, and any brute-force mitigations they have in place such as rate limiting.

   [SAH] I agree that there’s not a singular recommendation to be made here. Since that’s the case it’s appropriate to provide guidance that describes the trade-offs to be made by an implementer. The text you wrote above does that nicely, so I would suggest something like this:

   “There are trade-offs to be considered in determining just how much entropy is “enough”. With the user_code, the longer it is the harder it is to use. The authorization server can thus determine their own acceptable amount of entropy, trading off security for usability and taking into account the expiry time of the code and any brute-force mitigations they have in place such as rate limiting.”

   A related question: the last call made me wonder if there are any plans to add a device flow for OpenID Connect. Does anyone know if such a thing is in the works?

   The Google implementation of the device flow already supports OpenID Connect. Just add "openid" to the scopes in the request as you normally would, and you'll get an ID Token on the response.

   There isn't any effort that I'm aware of to document this. We could do it I guess if there was demand, it would be quite a short document.

   [SAH] Thanks!