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 protected]> 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 >> <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
