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> 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> 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 >>>> >>>> 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 >>>> >>> >>> >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
