Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E661A049C for ; Wed, 18 Feb 2015 05:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3INNbvLY4t3A for ; Wed, 18 Feb 2015 05:36:32 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D181A874A for ; Wed, 18 Feb 2015 05:36:32 -0800 (PST) Received: from [80.67.16.136] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1YO4nk-0001Fs-0k; Wed, 18 Feb 2015 14:36:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_88f42f6cdf4a4948d571e13ef8175469" Date: Wed, 18 Feb 2015 14:36:27 +0100 From: torsten@lodderstedt.net To: Nat Sakimura In-Reply-To: References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net> Message-ID: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org, naa@google.com Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:36:36 -0000 --=_88f42f6cdf4a4948d571e13ef8175469 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 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 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 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth [2] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > 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 --=_88f42f6cdf4a4948d571e13ef8175469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Nat,

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

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=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4)= at 18:48 Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
I think that the "controlled environme= nt" 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 i= s
> 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 tha= t, if the WG is OK with a MUST there,
> I am fine with incorporati= ng the proposed change.
>
> Cheers,
>
>= Nat
>
>
> On Wed, 18 Feb 2015 09:43:30 +0100 > Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
>> Hi Nat,=
>>
>> thanks for the quick response.
>>= ;
>> I was hoping to see a statement like "The code verifier MU= ST have
>> enough entropy to make it impractical to guess the v= alue." in the
>> text rather than the SHOULD. Given all the oth= er statements in the
>> draft I am not sure what the should act= ually means. Under what
>> conditions would an implementer not = provide enough entropy to make
>> guessing impractical?
&= gt;>
>> Ciao
>> Hannes
>>
>= > On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>>> Hi Hann= es,
>>>
>>> I hereby confirm that I have subm= it the draft  in full conformance
>>> with the  pr= ovisions of BCP 78 and BCP 79.
>>>
>>> Re: Se= curity 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 i= s hard to
>>> guessed or modeled. In a way, this is laying o= ut the basic security
>>> property requirment on the code ve= rifier.
>>>
>>> Then, it goes onto the implem= entation guideance that one need to
>>> use a cryptographic = random number generator instead of relying on a
>>> rand() i= n some language that are  not cryptographically random to
>&g= t;> generate 32-octet sequence. The same text is in 4.1 as well.
&= gt;>>
>>> We did not copy "code verifier SHOULD have e= nough entropy to make
>>> it impractical to guess the value"= here because that looked
>>> needlessly repeating, but if y= ou 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-octe= t
>>>
>>> We chose it because we are using SH= A256 in generating the code
>>> challange. Having more entro= py does not help us here, while having
>>> less octets incre= ases the risk.
>>>
>>> Best,
>>&g= t;
>>> Nat
>>>
>>>
>&= gt;>
>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>= ;> Hannes Tschofenig <ha= nnes.tschofenig@gmx.net> wrote:
>>>
>>>= ;> Hi Nat, John, Naveen,
>>>>
>>>> t= hanks a lot for your work on the document.
>>>>
>= ;>>> I still need responses to this mail to complete the shepherd<= br /> >>>> writeup:
>>>> http://www.ietf.or= g/mail-archive/web/oauth= /current/msg14100.html
>>>>
>>>> I definitely need the IPR = confirmation.
>>>>
>>>> It would also b= e helpful to have someone who implemented the
>>>> specif= ication as it currently is. I asked Brian and Thorsten for
>>&g= t;> clarification regarding their statements that they implemented
= >>>> earlier versions of the spec.
>>>>
>>>> As a final remark I still believe that the text regardin= g the
>>>> randomness is still a bit inconsistent. Here a= re two examples:
>>>>
>>>> 1) In the Se= curity Consideration you write that "The security model
>>>&= gt; relies on the fact that the code verifier is not learned or
>&= gt;>> guessed by the attacker.  It is vitally important to adher= e to
>>>> this principle. "
>>>>
= >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifie= r 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 use= d 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 entrop= y in
>>>> particular.
>>>>
>&g= t;>> Ciao
>>>> Hannes
>>>>
= >>>
>>>
>>
>
>
<= br /> _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or=
g/mailman/listinfo/oauth

 

 
--=_88f42f6cdf4a4948d571e13ef8175469--