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

Nat Sakimura <sakimura@gmail.com> Mon, 06 February 2012 03:57 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 515A121F853A for <oauth@ietfa.amsl.com>; Sun, 5 Feb 2012 19:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
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 zIg09KVGt8z1 for <oauth@ietfa.amsl.com>; Sun, 5 Feb 2012 19:57:08 -0800 (PST)
Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3432021F84F5 for <oauth@ietf.org>; Sun, 5 Feb 2012 19:57:08 -0800 (PST)
Received: by lbbgk8 with SMTP id gk8so1065368lbb.31 for <oauth@ietf.org>; Sun, 05 Feb 2012 19:57:07 -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=wAJEdiG/xVicr/bluGpGpDHMMj36LPK6FG/ivdfl3L4=; b=R0ICN8iK8/YfZZZB0vk49f9DmVh90OwE2uSuWZIeK/xV1IH/06GGd7dVy3En9FplZ8 FwSxr0VU7e6wLnqDY2SN/ojAJLXRlT2hIM2B9qRJ5gGJ1K7A4udWHArcHGX9WqI0zLAT uznY4cR/2X6ti+wbASZ7AWi9Za+ZhrmZvuQK8=
MIME-Version: 1.0
Received: by 10.112.44.101 with SMTP id d5mr4233351lbm.40.1328500627139; Sun, 05 Feb 2012 19:57:07 -0800 (PST)
Received: by 10.152.21.133 with HTTP; Sun, 5 Feb 2012 19:57:07 -0800 (PST)
In-Reply-To: <4F2B2C2C.3010505@alcatel-lucent.com>
References: <CABzCy2B4Dxb8BJe=Z5Sd_n8779JExj0u8n+xH8i9ypuFuwOJeg@mail.gmail.com> <4F2B2C2C.3010505@alcatel-lucent.com>
Date: Mon, 06 Feb 2012 12:57:07 +0900
Message-ID: <CABzCy2BD1jJ1J0CWvd6YmN2+=CkY96SgeHZ8Jk+HsAA9iW4yjA@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: igor.faynberg@alcatel-lucent.com
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: Mon, 06 Feb 2012 03:57:09 -0000

Igor,

Yes. Since it is a normative "MUST" text, it should be crystal clear.

For the second item, personally, I believe that it actually should
depend on the risk profile that the application is exposed to. It
could be such that there are other controls in place, so that it does
not have to be addressed via entropy requirement of the token.
It is especially true for a scenario where limited capability entities
are interacting with a very confined and controlled environment. The
current requirement may inhibit the use of OAuth 2.0 in such an
environment. 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.

=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