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 770961A924E for ; Wed, 18 Feb 2015 06:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 DPtD6W7gHTlN for ; Wed, 18 Feb 2015 06:05:06 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26B41A912D for ; Wed, 18 Feb 2015 06:04:56 -0800 (PST) Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVOScCLIpA43m+suHpELg3fPLWTWIHiK2@postini.com; Wed, 18 Feb 2015 06:04:57 PST Received: by iecar1 with SMTP id ar1so1339156iec.11 for ; Wed, 18 Feb 2015 06:04:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eCZ2eEWgCYom3nFDNGnjXWxYQacGdU3O/vbsbaD0RmU=; b=ggdzS0zoCB7YftGNRAGg7sMPDqXGYY8lv9CUdQE3kTlm/DvRfaztwnZ+AOkEM1Rw7m HMofCctUc2uIXr+nW7ZK0SxvJ7SkkcJzOuKPy/jn96AU41NwdeoDF8/7i7BpQZBZhGXV uIDUsSd437EXI3aUE5DQtJDoIuD2M2NG5tfeAi0sfll0ugbOwgSBudEokhXD0bWRoifC ML8HRDsWckrgENm3s4YhI7D6fQ9rAU4anbFZBWkmsoXt8rCc7xaD7DwqK58hwKKCpBam 20DlNw7XqpQI9H6qCfV+WvmN7VAGthbsvHRcYZMP7HZZkqqxC1Iu9lifhi1KDDE4wrWf I8Sw== X-Received: by 10.107.129.138 with SMTP id l10mr43770269ioi.37.1424268296266; Wed, 18 Feb 2015 06:04:56 -0800 (PST) X-Gm-Message-State: ALoCoQmZ+PFy86RqZBBkBWODr9NUQoTi3ZlEcCVb2cPeNPNbKxd5w7XJAFwJgWqHdXFZdmslmasDXiKXLWx3Sp4rew55i3jaq2DntMQCQEz5CXUdhtXdvwkvsmtTBEpXSUyGRKjSVs3N X-Received: by 10.107.129.138 with SMTP id l10mr43770249ioi.37.1424268296060; Wed, 18 Feb 2015 06:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.107.105 with HTTP; Wed, 18 Feb 2015 06:04:24 -0800 (PST) In-Reply-To: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net> References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net> <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net> From: Brian Campbell Date: Wed, 18 Feb 2015 07:04:24 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a113f9ba2da1c0c050f5d4d31 Archived-At: Cc: oauth , Naveen Agarwal 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 14:05:11 -0000 --001a113f9ba2da1c0c050f5d4d31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to agree with Torsten here - similar sentiments were (maybe not well) expressed a few weeks ago: http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html On Wed, Feb 18, 2015 at 6:36 AM, wrote: > 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=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=B0=B4) at 18:48 Hannes Tschofen= ig > 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 >> >>>> >> >>>> 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 > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113f9ba2da1c0c050f5d4d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree with Torsten here - similar sentiments wer= e (maybe not well) expressed a few weeks ago: http://www.ietf.org/mail-ar= chive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM, = <torsten@lodderstedt.net> wrote:

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)= . I consider a general MUST (which also applies to plain) a to strong requi= rement.

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 environmen= t" is a risky idea. I believe we
should definitely go for a MUST.<= br>
On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> Hi Hannes,
= >
> The reason I have put SHOULD there instead of MUST is
&g= t; that there may be a valid reason not to in a controlled
> environ= ment, and it does not interfere the interoperability.
> The deployme= nt may opt to use other control than entropy,
> and SHOULD allows it= while MUST does not.
>
> Having said that, if the WG is OK w= ith 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.tschofenig@g= mx.net> wrote:
>
>> Hi Nat,
>>
>&g= t; 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
>&g= t; text rather than the SHOULD. Given all the other statements in the
&= gt;> 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 here= by confirm that I have submit the draft=C2=A0 in full conformance
>&= gt;> with the=C2=A0 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 e= xplaining that
>>> the implementers got to make sure that the = code verifier is hard to
>>> guessed or modeled. In a way, thi= s 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 cryptogra= phic random number generator instead of relying on a
>>> rand(= ) in some language that are=C2=A0 not cryptographically random to
>&= gt;> generate 32-octet sequence. The same text is in 4.1 as well.
&g= t;>>
>>> We did not copy "code verifier SHOULD have= enough entropy to make
>>> it impractical to guess the value&= quot; here because that looked
>>> needlessly repeating, but i= f you want, I have no objection in
>>> adding it to 7.1.
&= gt;>>
>>> Alternatively, in 7.1, after explaining the ra= tionale, we can just
>>> point to 4.1 for the control and impl= ementation guidance.
>>>
>>> Re: 32-octet
>= ;>>
>>> We chose it because we are using SHA256 in gener= ating the code
>>> challange. Having more entropy does not hel= p us here, while having
>>> less octets increases the risk. >>>
>>> Best,
>>>
>>> Nat=
>>>
>>>
>>>
>>> On Tue= , 17 Feb 2015 17:56:33 +0100
>>> Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
>>>
>>>> Hi Nat, John, N= aveen,
>>>>
>>>> thanks a lot for your work= on the document.
>>>>
>>>> I still need re= sponses 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.
>&= gt;>>
>>>> It would also be helpful to have someone w= ho implemented the
>>>> specification as it currently is. I= asked Brian and Thorsten for
>>>> clarification regarding = their statements that they implemented
>>>> earlier version= s 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 "T= he security model
>>>> relies on the fact that the code ver= ifier is not learned or
>>>> guessed by the attacker.=C2=A0= It is vitally important to adhere to
>>>> this principle. = "
>>>>
>>>> 2) In Section 4.1 you, how= ever, write: "NOTE: code verifier SHOULD
>>>> have eno= ugh entropy to make it impractical to guess the value.=C2=A0 It
>>= ;>> is RECOMMENDED that the output of a suitable random number
&g= t;>>> generator be used to create a 32-octet sequence."
&= gt;>>>
>>>> There is clearly a long way from a SHO= ULD have enough entropy to
>>>> the text in the security co= nsideration section where you ask for
>>>> 32 bytes entropy= .
>>>>
>>>> It is also not clear why you as= k for 32 bytes of entropy in
>>>> particular.
>>&= gt;>
>>>> Ciao
>>>> Hannes
>>&= gt;>
>>>
>>>
>>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/oauth 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001a113f9ba2da1c0c050f5d4d31--