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

[Hollenbeck, Scott]

From: William Denniss [mailto:wdenn...@google.com]
Sent: Tuesday, January 02, 2018 5:38 PM
To: Hollenbeck, Scott 
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 
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) 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

Re: [OAUTH-WG] Token scanning attacks in RFC 7662

[Neil Madden]

On 3 Jan 2018, at 07:07, Vladimir Dzhuvinov  wrote:
> 
> 
> On 02/01/18 19:01, Neil Madden wrote:
>> How does authentication address the problem?
> Authentication increases the effective entropy. An attacker fist has to be 
> break the client secret, then successfully guess the token.


Authentication of parties using the introspection endpoint doesn’t increase 
entropy. If I have a 1 in 2^128 chance of correctly guessing an access token 
before you add authentication to the endpoint, then I still have the same 
probability of success afterwards. You’ve just made it harder for me to check 
my answers. But I can just try and actually use the token to see if it works. 
If access token guessing is a problem for token introspection, then it is a 
problem for essentially every part of the OAuth 2.0 ecosystem.

There is also the issue that attackers may have valid credentials anyway. If 
this attack is valid in the first place, then it is also valid to consider a 
malicious RS trying to compromise tokens for a different resource server. 
Unless you have a completely closed environment where all valid parties trust 
each other, then authentication doesn’t make much difference.

But the token scanning attack is already ruled out by the entropy requirements 
on access tokens. For example, suppose your application produces access tokens 
at a rate of 1 million per second, and they each last for 2 years. You will 
have a maximum of just over 63 trillion access tokens in circulation (~2^46). 
Assuming an attacker doesn’t care about which access token they compromise, 
then with the minimum entropy requirements of 128 bits they will require effort 
of approximately 2^(128-46) = 2^82 to guess any one of those access tokens. 
That should still be beyond the likely capabilities of anybody to achieve in a 
2 year timespan. If you use the recommendation for 160-bit entropy, then they 
have effort of 2^114, which is comfortably beyond practical for the foreseeable 
future. (All assuming that you do not leak tokens by other means).

It is not a bad idea to require authentication on the token introspection 
endpoint, for other reasons mentioned in this thread. So I don’t think the RFC 
is wrong to recommend it, or even require it. But the stated rationale seems 
incorrect to me.

Regards,

Neil


signature.asc
Description: Message signed with OpenPGP
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth