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
- [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Nat Sakimura
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Nat Sakimura
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Nat Sakimura
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 torsten
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Bill Mills
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-spop-10 Naveen Agarwal