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 >> > >
- [OAUTH-WG] Clarification request on draft-ietf-oa… Nat Sakimura
- Re: [OAUTH-WG] Clarification request on draft-iet… Igor Faynberg
- Re: [OAUTH-WG] Clarification request on draft-iet… Nat Sakimura
- Re: [OAUTH-WG] Clarification request on draft-iet… Torsten Lodderstedt
- Re: [OAUTH-WG] Clarification request on draft-iet… Nat Sakimura