Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10

Nat Sakimura <sakimura@gmail.com> Tue, 07 February 2012 00:58 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF4311E80CB for <oauth@ietfa.amsl.com>; Mon, 6 Feb 2012 16:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igKI6fU4iGED for <oauth@ietfa.amsl.com>; Mon, 6 Feb 2012 16:58:35 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 289EA11E80B5 for <oauth@ietf.org>; Mon, 6 Feb 2012 16:58:31 -0800 (PST)
Received: by lahl5 with SMTP id l5so4203357lah.31 for <oauth@ietf.org>; Mon, 06 Feb 2012 16:58:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yThjaG0gTV4Di9Rm+XHRQA5CWi+RhetL1OKe29qWT3c=; b=tx2m597uzuMgkdzz0BEOJJdylplJYvsWHZAmsMEmsNFVkFopbGlkF8DmDW+7tCd1VT QDRXg0Kg1GLL31yDmeHe/gSWw/hdVcJL06+D+jPd2ETkZbjhjRlOVk+uM3Y8HdG+nVMv AO92Q8YU4Xow/LGtJNPN+oN5jtvo3iqe1yeLg=
MIME-Version: 1.0
Received: by 10.112.44.101 with SMTP id d5mr5510373lbm.40.1328576311168; Mon, 06 Feb 2012 16:58:31 -0800 (PST)
Received: by 10.152.21.133 with HTTP; Mon, 6 Feb 2012 16:58:31 -0800 (PST)
In-Reply-To: <4F3032E9.8050109@lodderstedt.net>
References: <CABzCy2B4Dxb8BJe=Z5Sd_n8779JExj0u8n+xH8i9ypuFuwOJeg@mail.gmail.com> <4F2B2C2C.3010505@alcatel-lucent.com> <CABzCy2BD1jJ1J0CWvd6YmN2+=CkY96SgeHZ8Jk+HsAA9iW4yjA@mail.gmail.com> <4F3032E9.8050109@lodderstedt.net>
Date: Tue, 07 Feb 2012 09:58:31 +0900
Message-ID: <CABzCy2BkfNi4-dW2J_VhNJ9zxP1_LxRfcZm+bXT5d+HFR-Ei9Q@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 07 Feb 2012 00:58:36 -0000

Hi Torsten,

If it were a guideline, it should not have a normative text in it.
Even if it did, it MUST NOT have a "MUST" in the sentence.
But since it has those normative text, I gather that it is normative.

If it were only "SHOULD" or "RECOMMENDED", I would have less problem.
(Though counting only on the entropy is not so good, IMHO.)
So, I would like to see the "MUST" removed at the very least.

Regards,

=nat



On Tue, Feb 7, 2012 at 5:07 AM, Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:
> Hi Nat,
>
>> ...
>>
>> We probably should put some text that gives flexibility
>> in that respect, such as " or put in place the controls that achieves
>> equivalent risk mitigation." etc.
>
>
> One could add this text to nearly any of the guidelines given in Section 10.
> But how do you assess the equivalence of the respective control?
>
> The intention of the security considerations section was to give clear
> guidance even for implementors unfamiliar with security and threat analysis.
> We therefore gave simple guidelines without much explanation of the
> rationale. I think this will work for most implementations. Implementors
> confronted with circumstances which do not allow them to adhere to the
> security considerations should create an appropriate security design based
> on the threat model and security considerations document.
>
> regards,
> Torsten.
>
>
>> =nat
>>
>> On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg
>> <igor.faynberg@alcatel-lucent.com>  wrote:
>>>
>>> Nat,
>>>
>>> Your note made me think (as always), so maybe some text clarification is
>>> indeed in order.
>>>
>>> I have a slightly different understanding of the items you brought up.
>>>  RFC
>>> 1750 is Informational, and I thought (maybe mistakenly?) that it cannot
>>> be
>>> used as a norm in a MUST clause.  Therefore, I assumed that the clause
>>> prescribes the use of cryptographically-strong pseudo-random generators
>>> but
>>> stopped short of listing them.
>>>
>>> The second item, I read as defining the strength, giving the necessary
>>> and
>>> desired bounds for a collision probability of two generated values.
>>>
>>> Igor
>>>
>>>
>>>
>>> On 2/2/2012 4:25 AM, Nat Sakimura wrote:
>>>
>>> hi.
>>>
>>> The rev. 23 has a normative change in section 10.10 as:
>>>
>>> 10.10.  Credentials Guessing Attacks
>>>   [...]
>>>  Generated tokens and other credentials not intended for handling by
>>>    end-users MUST be constructed from a cryptographically strong random
>>>    or pseudo-random number sequence ([RFC1750]) generated by the
>>>    authorization server.
>>>
>>> Does this normative requirement only allows pseudo-random number
>>> sequence described as in Section 6.3 of RFC1750?
>>> Or does it allow something that includes it? I gather that it is the
>>> later,
>>> but the wording "constructed from" sounds a little vague.
>>>
>>> It also states:
>>>
>>>  The probability of any two values being
>>>    identical MUST be less than or equal to 2^(-128) and SHOULD be less
>>>    than or equal to 2^(-160).
>>>
>>> It is "the probability that a randomly generated guessed value being
>>> identical to
>>> the authoritatively generated token or credential value", I suppose.
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en