From: William Denniss [mailto:wdenn...@google.com] Sent: Tuesday, January 02, 2018 5:38 PM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: oauth@ietf.org 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 <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> 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? [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!
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
