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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 18 February 2015 09:47 UTC

Return-Path: <hannes.tschofenig@gmx.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 E88451A86FC for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 01:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Q1b-tYjhzF1m for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 01:47:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725AB1A702C for <oauth@ietf.org>; Wed, 18 Feb 2015 01:47:56 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MOSNd-1YRZTP19vh-005pwx; Wed, 18 Feb 2015 10:47:50 +0100
Message-ID: <54E45F22.8060902@gmx.net>
Date: Wed, 18 Feb 2015 10:45:06 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nat Sakimura <n-sakimura@nri.co.jp>
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
In-Reply-To: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA"
X-Provags-ID: V03:K0:b3d/t4SsgDZBGWPOiTHpErX9B1ZzVJDSImj2H+WNcxeslhLe6H2 kjn6A/K7SQAOnNTg7/2JdeVITrj+H/u+TBGyYXnYH0+Z2FlhMHrvKHhMsuhC2iPIJ8kKSwC KPbrOQS+Z5ULU9JhvBCPvjZvoudvy3gkSogiVa8TxcUedD1P1841SqEZRq2KVTkzLsQkhqV a2GogLt+3CPpPAOhxMDDg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/wAzByu1QNa0qxrFhST8-CW7zAWM>
Cc: "oauth@ietf.org" <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 09:47:59 -0000

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
>>>>
>>>> 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
>>>>
>>>
>>>
>>
> 
>