Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
From: [email-masked]
To: Nat Sakimura <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 18 Feb 2015 14:36:27 +0100
List-Id: OAUTH WG <oauth.ietf.org>

Hi Nat, 

as far as I understand, the length of at least 32 octets is justified
for S256 only. So limiting the MUST to S256 would be ok (from my
perspective). I consider a general MUST (which also applies to plain) a
to strong requirement. 

kind regards,
Torsten. 

Am 18.02.2015 10:50, schrieb Nat Sakimura: 

> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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 [1]
>>>>>> 
>>>>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth [2]
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth [2]

Links:
------
[1] http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
[2] https://www.ietf.org/mailman/listinfo/oauth