Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>>>>
>>>
>>>
>>
> 
>