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

torsten@lodderstedt.net Wed, 18 February 2015 13:36 UTC

Return-Path: <torsten@lodderstedt.net>
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 <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; 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 <torsten@lodderstedt.net>) 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 <n-sakimura@nri.co.jp>
In-Reply-To: <CABzCy2D1izfTA-ji28XX-rJg=BsSiXgnkNvCWn0Puz2_pCiG1A@mail.gmail.com>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net> <CABzCy2D1izfTA-ji28XX-rJg=BsSiXgnkNvCWn0Puz2_pCiG1A@mail.gmail.com>
Message-ID: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/dPqj9glA0qyRUoZo8yyThk4UaO4>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2015 13:36:36 -0000

 

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 <hannes.tschofenig@gmx.net> 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 <hannes.tschofenig@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.tschofenig@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 [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