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

Brian Campbell <bcampbell@pingidentity.com> Wed, 18 February 2015 14:05 UTC

Return-Path: <bcampbell@pingidentity.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 770961A924E for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 06:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 DPtD6W7gHTlN for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 06:05:06 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26B41A912D for <oauth@ietf.org>; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKVOScCLIpA43m+suHpELg3fPLWTWIHiK2@postini.com; Wed, 18 Feb 2015 06:04:57 PST
Received: by iecar1 with SMTP id ar1so1339156iec.11 for <oauth@ietf.org>; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eCZ2eEWgCYom3nFDNGnjXWxYQacGdU3O/vbsbaD0RmU=; b=ggdzS0zoCB7YftGNRAGg7sMPDqXGYY8lv9CUdQE3kTlm/DvRfaztwnZ+AOkEM1Rw7m HMofCctUc2uIXr+nW7ZK0SxvJ7SkkcJzOuKPy/jn96AU41NwdeoDF8/7i7BpQZBZhGXV uIDUsSd437EXI3aUE5DQtJDoIuD2M2NG5tfeAi0sfll0ugbOwgSBudEokhXD0bWRoifC ML8HRDsWckrgENm3s4YhI7D6fQ9rAU4anbFZBWkmsoXt8rCc7xaD7DwqK58hwKKCpBam 20DlNw7XqpQI9H6qCfV+WvmN7VAGthbsvHRcYZMP7HZZkqqxC1Iu9lifhi1KDDE4wrWf I8Sw==
X-Received: by 10.107.129.138 with SMTP id l10mr43770269ioi.37.1424268296266; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
X-Gm-Message-State: ALoCoQmZ+PFy86RqZBBkBWODr9NUQoTi3ZlEcCVb2cPeNPNbKxd5w7XJAFwJgWqHdXFZdmslmasDXiKXLWx3Sp4rew55i3jaq2DntMQCQEz5CXUdhtXdvwkvsmtTBEpXSUyGRKjSVs3N
X-Received: by 10.107.129.138 with SMTP id l10mr43770249ioi.37.1424268296060; Wed, 18 Feb 2015 06:04:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.107.105 with HTTP; Wed, 18 Feb 2015 06:04:24 -0800 (PST)
In-Reply-To: <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
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> <8b765b012cb7bf7ac3c6c203307d6d86@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 18 Feb 2015 07:04:24 -0700
Message-ID: <CA+k3eCREHF816=s99CJfmH5FcD=sQV+fErAujy1XQM-wDQw5-w@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=001a113f9ba2da1c0c050f5d4d31
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SXHaTEDOgXE1qBKBmowVfsM7ljY>
Cc: oauth <oauth@ietf.org>, Naveen Agarwal <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 14:05:11 -0000

I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM, <torsten@lodderstedt.net> wrote:

>  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
>> >>>>
>> >>>> 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 mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>