Re: [OAUTH-WG] draft-ietf-oauth-spop-10
Nat Sakimura <n-sakimura@nri.co.jp> Wed, 18 February 2015 09:50 UTC
Return-Path: <sakimura@gmail.com>
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 980EC1A8711 for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 01:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 D-S61l1c2Rix for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF891A873C for <oauth@ietf.org>; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id gq1so91201obb.2 for <oauth@ietf.org>; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=YHg0CWDgkuup8LNIRJ0cVfs6Gw4QPREQaMiGKa/6FbQ=; b=ZrbxSYgPSxw8w6KrPeb3t9R+C6anbY5u1ibCyvaHBtS4gYKtq7gqacHUqxAK8iYGXH wgZ06d2dpSADJPXiipyGiQnSURjQBekDHoX6dEI1p/Ik5yRc9g3k2+j/3Lgwp0Fy2Z2r nO0Zo3kaSMegJcvwfpB+CbsH1uGWJl5JZKYe1actfNZgEYI9auo9R0eBkQOAjY8egTju slzrzZwIGSSf7mjQ9xhl9jtmIvopfLQcUlbHJUgTQzX/EcdmFQ3x0qfni9JdiZkgCH+n FW5LGJdWZyOsYC2oVlttgxnoSHKCEcHQ2tBop/VBS+sMSqlUzf1m52v4I13rng37Y+TA lzQQ==
X-Received: by 10.60.230.6 with SMTP id su6mr21576435oec.44.1424253010074; Wed, 18 Feb 2015 01:50:10 -0800 (PST)
MIME-Version: 1.0
References: <54E372C1.8040204@gmx.net> <20150218131359.19dae026d3e459813e21dc55@nri.co.jp> <54E450B2.7020409@gmx.net> <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp> <54E45F22.8060902@gmx.net>
From: Nat Sakimura <n-sakimura@nri.co.jp>
Date: Wed, 18 Feb 2015 09:50:08 +0000
Message-ID: <CABzCy2D1izfTA-ji28XX-rJg=BsSiXgnkNvCWn0Puz2_pCiG1A@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="001a1136400abc63ec050f59beaa"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/fYnvpHOkHStkL6q3w9Vp3aV5g3c>
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:50:13 -0000
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 > >>>> > >>>> 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-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