Subject: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10

From: Nat Sakimura <[email-masked]>
Date: Thu, 2 Feb 2012 18:25:10 +0900

hi.

The rev. 23 has a normative change in section 10.10 as:

10.10.  Credentials Guessing Attacks
  [...]
 Generated tokens and other credentials not intended for handling by
   end-users MUST be constructed from a cryptographically strong random
   or pseudo-random number sequence ([RFC1750]) generated by the
   authorization server.

Does this normative requirement only allows pseudo-random number
sequence described as in Section 6.3 of RFC1750?
Or does it allow something that includes it? I gather that it is the later,
but the wording "constructed from" sounds a little vague.

It also states:

 The probability of any two values being
   identical MUST be less than or equal to 2^(-128) and SHOULD be less
   than or equal to 2^(-160).

It is "the probability that a randomly generated guessed value being
identical to
the authoritatively generated token or credential value", I suppose.

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 02 Feb 2012 19:37:00 -0500

Nat,

Your note made me think (as always), so maybe some text clarification is 
indeed in order.

I have a slightly different understanding of the items you brought up.  
RFC 1750 is Informational, and I thought (maybe mistakenly?) that it 
cannot be used as a norm in a MUST clause.  Therefore, I assumed that 
the clause prescribes the use of /cryptographically-strong/ 
pseudo-random generators but stopped short of listing them.

The second item, I read as defining the strength, giving the necessary 
and desired bounds for a collision probability of two generated values.

Igor

On 2/2/2012 4:25 AM, Nat Sakimura wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 6 Feb 2012 12:57:07 +0900

Igor,

Yes. Since it is a normative "MUST" text, it should be crystal clear.

For the second item, personally, I believe that it actually should
depend on the risk profile that the application is exposed to. It
could be such that there are other controls in place, so that it does
not have to be addressed via entropy requirement of the token.
It is especially true for a scenario where limited capability entities
are interacting with a very confined and controlled environment. The
current requirement may inhibit the use of OAuth 2.0 in such an
environment. We probably should put some text that gives flexibility
in that respect, such as " or put in place the controls that achieves
equivalent risk mitigation." etc.

=nat

On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg
<[email-masked]> wrote:
> I have a slightly different understanding of the items you brought up.  RFC
> 1750 is Informational, and I thought (maybe mistakenly?) that it cannot be
> used as a norm in a MUST clause.  Therefore, I assumed that the clause
> prescribes the use of cryptographically-strong pseudo-random generators but
> stopped short of listing them.
>
> The second item, I read as defining the strength, giving the necessary and
> desired bounds for a collision probability of two generated values.
>
> Igor
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 06 Feb 2012 21:07:05 +0100

Hi Nat,

> ...
> We probably should put some text that gives flexibility

One could add this text to nearly any of the guidelines given in Section 
10. But how do you assess the equivalence of the respective control?

The intention of the security considerations section was to give clear 
guidance even for implementors unfamiliar with security and threat 
analysis. We therefore gave simple guidelines without much explanation 
of the rationale. I think this will work for most implementations. 
Implementors confronted with circumstances which do not allow them to 
adhere to the security considerations should create an appropriate 
security design based on the threat model and security considerations 
document.

regards,
Torsten.

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 7 Feb 2012 09:58:31 +0900

Hi Torsten,

If it were a guideline, it should not have a normative text in it.
Even if it did, it MUST NOT have a "MUST" in the sentence.
But since it has those normative text, I gather that it is normative.

If it were only "SHOULD" or "RECOMMENDED", I would have less problem.
(Though counting only on the entropy is not so good, IMHO.)
So, I would like to see the "MUST" removed at the very least.

Regards,

=nat

On Tue, Feb 7, 2012 at 5:07 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> One could add this text to nearly any of the guidelines given in Section 10.
> But how do you assess the equivalence of the respective control?
>
> guidance even for implementors unfamiliar with security and threat analysis.
> We therefore gave simple guidelines without much explanation of the
> rationale. I think this will work for most implementations. Implementors
> confronted with circumstances which do not allow them to adhere to the
> security considerations should create an appropriate security design based
> on the threat model and security considerations document.
>
> regards,
> Torsten.
>
>
>> =nat
>>
>>>  RFC
>>> and