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

[Nat Sakimura <[e-mail]>]

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
<[e-mail]> wrote:
> Hi Nat,
>
>> ...
>>
>> 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.
>
>
> 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.
>
>
>> =nat
>>
>> On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg
>> <[e-mail]>  wrote:
>>>
>>> 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:
>>>
>>> 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
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>



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