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

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 06 February 2012 20:07 UTC

Return-Path: <torsten@lodderstedt.net>
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 2643F21F8739 for <oauth@ietfa.amsl.com>; Mon, 6 Feb 2012 12:07:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 vmedaoCDXzsj for <oauth@ietfa.amsl.com>; Mon, 6 Feb 2012 12:07:10 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6A21F873E for <oauth@ietf.org>; Mon, 6 Feb 2012 12:07:09 -0800 (PST)
Received: from [91.2.94.245] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1RuUqC-0004ka-3j; Mon, 06 Feb 2012 21:07:08 +0100
Message-ID: <4F3032E9.8050109@lodderstedt.net>
Date: Mon, 06 Feb 2012 21:07:05 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Nat Sakimura <sakimura@gmail.com>
References: <CABzCy2B4Dxb8BJe=Z5Sd_n8779JExj0u8n+xH8i9ypuFuwOJeg@mail.gmail.com> <4F2B2C2C.3010505@alcatel-lucent.com> <CABzCy2BD1jJ1J0CWvd6YmN2+=CkY96SgeHZ8Jk+HsAA9iW4yjA@mail.gmail.com>
In-Reply-To: <CABzCy2BD1jJ1J0CWvd6YmN2+=CkY96SgeHZ8Jk+HsAA9iW4yjA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
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 20:07:11 -0000

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
>>
>
>