As I stated in my message. I think for plain having there be a MUST at 256 bits would be overkill.
For plain given it is single use like the code is we should probably match it to the entropy required for code. In RFC 6749 we say The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). So to be consistent I would make plain "MUST be between 16 and 32 octets” I don’t remember precisely , but I may be the one responsible for the for the 2^(-128) value for code. That was a bit higher than needed if people can really only use code once. However the reality is that not all AS properly revoke code after it is used. That is really hard in a clustered environment. (There is more than one large one so I am not picking on anyone in particular) Knowing that in reality an attacker might be able to make a limited number attacks before a code time expires there is a fudge factor in the 128bit code to still make it plausibly unguessable even in that case. The same factor would apply to code_verifier other wise I would say 8 octets would be sufficient. John B. > On Feb 18, 2015, at 1:50 AM, Nat Sakimura <n-sakim...@nri.co.jp> wrote: > > Is there anyone who has problems changing it to a MUST? > On 2015年2月18日(水) at 18:48 Hannes Tschofenig <hannes.tschofe...@gmx.net > <mailto:hannes.tschofe...@gmx.net>> wrote: > I think that the "controlled environment" is a risky idea. I believe we > should definitely go for a MUST. > > On 02/18/2015 10:26 AM, Nat Sakimura wrote: > > Hi Hannes, > > > > The reason I have put SHOULD there instead of MUST is > > that there may be a valid reason not to in a controlled > > environment, and it does not interfere the interoperability. > > The deployment may opt to use other control than entropy, > > and SHOULD allows it while MUST does not. > > > > Having said that, if the WG is OK with a MUST there, > > I am fine with incorporating the proposed change. > > > > Cheers, > > > > Nat > > > > > > On Wed, 18 Feb 2015 09:43:30 +0100 > > Hannes Tschofenig <hannes.tschofe...@gmx.net > > <mailto:hannes.tschofe...@gmx.net>> wrote: > > > >> Hi Nat, > >> > >> thanks for the quick response. > >> > >> I was hoping to see a statement like "The code verifier MUST have > >> enough entropy to make it impractical to guess the value." in the > >> text rather than the SHOULD. Given all the other statements in the > >> draft I am not sure what the should actually means. Under what > >> conditions would an implementer not provide enough entropy to make > >> guessing impractical? > >> > >> Ciao > >> Hannes > >> > >> On 02/18/2015 05:13 AM, Nat Sakimura wrote: > >>> Hi Hannes, > >>> > >>> I hereby confirm that I have submit the draft in full conformance > >>> with the provisions of BCP 78 and BCP 79. > >>> > >>> Re: Security Consideration (7.1) and section 4.1 > >>> > >>> The first part of the 7.1 is a non-normative prose explaining that > >>> the implementers got to make sure that the code verifier is hard to > >>> guessed or modeled. In a way, this is laying out the basic security > >>> property requirment on the code verifier. > >>> > >>> Then, it goes onto the implementation guideance that one need to > >>> use a cryptographic random number generator instead of relying on a > >>> rand() in some language that are not cryptographically random to > >>> generate 32-octet sequence. The same text is in 4.1 as well. > >>> > >>> We did not copy "code verifier SHOULD have enough entropy to make > >>> it impractical to guess the value" here because that looked > >>> needlessly repeating, but if you want, I have no objection in > >>> adding it to 7.1. > >>> > >>> Alternatively, in 7.1, after explaining the rationale, we can just > >>> point to 4.1 for the control and implementation guidance. > >>> > >>> Re: 32-octet > >>> > >>> We chose it because we are using SHA256 in generating the code > >>> challange. Having more entropy does not help us here, while having > >>> less octets increases the risk. > >>> > >>> Best, > >>> > >>> Nat > >>> > >>> > >>> > >>> On Tue, 17 Feb 2015 17:56:33 +0100 > >>> Hannes Tschofenig <hannes.tschofe...@gmx.net > >>> <mailto:hannes.tschofe...@gmx.net>> wrote: > >>> > >>>> Hi Nat, John, Naveen, > >>>> > >>>> thanks a lot for your work on the document. > >>>> > >>>> I still need responses to this mail to complete the shepherd > >>>> writeup: > >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html > >>>> <http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html> > >>>> > >>>> I definitely need the IPR confirmation. > >>>> > >>>> It would also be helpful to have someone who implemented the > >>>> specification as it currently is. I asked Brian and Thorsten for > >>>> clarification regarding their statements that they implemented > >>>> earlier versions of the spec. > >>>> > >>>> As a final remark I still believe that the text regarding the > >>>> randomness is still a bit inconsistent. Here are two examples: > >>>> > >>>> 1) In the Security Consideration you write that "The security model > >>>> relies on the fact that the code verifier is not learned or > >>>> guessed by the attacker. It is vitally important to adhere to > >>>> this principle. " > >>>> > >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD > >>>> have enough entropy to make it impractical to guess the value. It > >>>> is RECOMMENDED that the output of a suitable random number > >>>> generator be used to create a 32-octet sequence." > >>>> > >>>> There is clearly a long way from a SHOULD have enough entropy to > >>>> the text in the security consideration section where you ask for > >>>> 32 bytes entropy. > >>>> > >>>> It is also not clear why you ask for 32 bytes of entropy in > >>>> particular. > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>> > >>> > >> > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
