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
>