Re: [OAUTH-WG] SPOP: Code Challenge Discussion

John Bradley <ve7jtb@ve7jtb.com> Thu, 04 December 2014 15:15 UTC

Return-Path: <ve7jtb@ve7jtb.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 308941A0183 for <oauth@ietfa.amsl.com>; Thu, 4 Dec 2014 07:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 qQ9FvWAIJutn for <oauth@ietfa.amsl.com>; Thu, 4 Dec 2014 07:15:03 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836931AD40E for <oauth@ietf.org>; Thu, 4 Dec 2014 07:14:58 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id a1so14641348wgh.19 for <oauth@ietf.org>; Thu, 04 Dec 2014 07:14:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Z50YLSeTBJeR+/BPDTDGxGZkUNQJjWnvxaFYWPnAWz8=; b=YtEHzmAjagFrpw1KLivPDLmxNs5nCDngHfy4obBNspu7fmRsEHu3dzSZyJZu0cXFRl ndGlz8PdJ7ztwg52O/+EcME9SMnifCsqF3pntxyaH6Keus4S1vA3Vo2h1CsZyTpkyyMi f33yOfb04WANfLB7BF901A+EM+zfKGbfbkx6d+tOKxmSe8d3m/VMvdFfsNSjyvvr1O+o BegVTat45PukdIwQzFyt8yjyZFFefdj25tg0WhJIQn8Vzv5qY8SosDXVzaW6MH/1ncm7 CLUC5OfZxDJDOoHcN9jigYiimY6PMEJywlZ8vjULWPEWM10xoB4x/nrZoyuzsd9OmouJ xX/g==
X-Gm-Message-State: ALoCoQlQHaGe5I2QmpPzZYMATeODpiAwVB5kHXxoAQEPiGUqhVZN+g5cPfxIBiY4Nnhfe2Y0Wt97
X-Received: by 10.195.11.38 with SMTP id ef6mr16681306wjd.68.1417706097086; Thu, 04 Dec 2014 07:14:57 -0800 (PST)
Received: from [10.47.81.9] (host86-187-113-78.range86-187.btcentralplus.com. [86.187.113.78]) by mx.google.com with ESMTPSA id ry19sm40881433wjb.3.2014.12.04.07.14.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:14:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0F4C488D-6DD5-4840-83D1-0A3EDB823CFA"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54806A8A.207@gmx.net>
Date: Thu, 04 Dec 2014 12:14:52 -0300
Message-Id: <FE78EBF9-5FBB-442B-9854-B99BBB39AC92@ve7jtb.com>
References: <547EF145.5030501@gmx.net> <778679063.4544892.1417630207273.JavaMail.yahoo@jws10617.mail.bf1.yahoo.com> <54802E48.4050509@gmx.net> <E8F1EC3C-078C-4B4E-B91F-9EBEFDD30E0B@ve7jtb.com> <54806A8A.207@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W4QAic0RN0e20r-a9OXiy1gk1wM
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] SPOP: Code Challenge Discussion
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: Thu, 04 Dec 2014 15:15:05 -0000

How about 126bits/21 octets a must and 256bits/42 octets a SHOULD on platforms that can support it?

We are talking about prng output, on a phone or computer there is not going to be a performance difference.
You have a point for very small devices. 

People are going to be using system functions more likely than writing there own prng (thank god).
We can mention RFC 4086 but it may send people in the wrong direction.

John B.

> On Dec 4, 2014, at 11:07 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> Thanks for pointing me to Section 7.1.
> 
> To avoid this SHOULD and RECOMMENDED language I would suggest that you
> say that "The code_verifier value MUST have randomly generated with at
> least 128-bits of entropy. Guidelines for producing high quality random
> numbers can be found in RFC 4086."
> 
> 256-bit is nice as well but far exceeds what is currently recommended
> and might actually be difficult on certain types of devices (I am
> thinking more about the IoT space here).
> 
> On 12/04/2014 11:56 AM, John Bradley wrote:
>> Hannes,
>> 
>> 7.1 is talking about the generation of the code verifier you are thinking of the code challenge, that is the output of the hash. 
>> 
>> The verifier is the value that is hashed 32 octets is 256bits,  so you are recommending half the entropy already recommended. 
>> 
>> Also see the text in 4.1 
>> 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.  The
>>   Octet sequence is then BASE64URL encoded to produce a 42-octet URL
>>   safe string to use as the code verifier.
>> 
>> If "It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence." is not clear then we need to work on that.
>> 
>> John B.
>> 
>>> On Dec 4, 2014, at 6:50 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>> 
>>> Hi Bill,
>>> 
>>> I actually wasn't quite sure what this sentence meant.
>>> 
>>> What I want is that the input to the hash is a 128-bit (or larger)
>>> random number. The output will be determined by the hash function and,
>>> in case of SHA-256 (as suggested in the document) that output will be
>>> 32-octets.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> 
>>> On 12/03/2014 07:10 PM, Bill Mills wrote:
>>>> Quoting from 7.1 
>>>> 
>>>> "It is RECOMMENDED that the output of a suitable random number 
>>>> generatorbe used to create a 32-octet sequence."
>>>> 
>>>> So the spec is already recommending 256 bits of randomness, is that
>>>> language not clear enough?
>>>> 
>>>> 
>>>> On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig
>>>> <hannes.tschofenig@gmx.net> wrote:
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> I am trying to figure out how to progress the SPOP document and
>>>> therefore I read through the discussion about the code challenge, see
>>>> 
>>>> I wanted to share my view about this topic.
>>>> 
>>>> As a summary, the mechanism works as follows:
>>>> 
>>>> C: Compute code_verifier:=rand()
>>>> C: Compute code_challenge:=func(code_verifier)
>>>> 
>>>> (For this discussion, the function func() is SHA-256.)
>>>> 
>>>> C: Send(Authz Request + code_challenge,S)
>>>> 
>>>> S: store code_challenge
>>>> S: Send(Authz Grant,C)
>>>> 
>>>> C: Send(Access Token Request || code_verifier, S)
>>>> 
>>>> S: Compute code_challenge':=func(code_verifier)
>>>> S: IF (code_challenge'==code_challenge) THEN SUCCESS ELSE FAIL.
>>>> 
>>>> The document currently does not say how much entropy the random number
>>>> has to have.
>>>> 
>>>> The text only talks about the output size and SHA-256 indeed produces a
>>>> 256 bit output.
>>>> 
>>>> Here is the relevant text:
>>>> 
>>>> "
>>>> 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.
>>>> "
>>>> 
>>>> I suggest to recommend at least 128 bits, which is inline with the
>>>> recommendations for symmetric ciphers in
>>>> http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07
>>>> 
>>>> I would also suggest to reference RFC 4086 concerning the creation of
>>>> random numbers.
>>>> 
>>>> Furthermore, since you allow other hash functions to be used as well it
>>>> would be good to give guidance about what the properties of those hash
>>>> functions should be. You definitely want a cryptographic hash function
>>>> that provides pre-image resistance, second pre-image resistance, and
>>>> collision resistance.
>>>> 
>>>> Given the size of the input and output it is impractical to compute a
>>>> table that maps code_verifies to code_challenges.
>>>> 
>>>> This mechanism provides better properties than the "plain" mechanism
>>>> since it deals with an attacker that can see responses as well as
>>>> requests (but cannot modify them). It does not provide any protection
>>>> against a true man-in-the-middle attacker.
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>