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

John Bradley <ve7jtb@ve7jtb.com> Wed, 03 December 2014 11:37 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 57A621A1A48 for <oauth@ietfa.amsl.com>; Wed, 3 Dec 2014 03:37:20 -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 z58Lw5wqF_Wh for <oauth@ietfa.amsl.com>; Wed, 3 Dec 2014 03:37:18 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D18F1A1A68 for <oauth@ietf.org>; Wed, 3 Dec 2014 03:37:18 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id h11so31104073wiw.1 for <oauth@ietf.org>; Wed, 03 Dec 2014 03:37:17 -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=qAfLqYn0UfhmUFA5zWclhWMkxwe5oWMWRo5+HdYBPd8=; b=g2Z6XAHiCmMWPAAdB+NACBMeqzbh0zmXZ4VWY0QvFqtqfxH0R/rmH1nXNxcuht8wSy bcmPztGBceGYxVXoqZalo1NvjSh9dAA3bFA2dC0qTcuFl/VKyl+ZwhD4gZI+/tif74Ie 9vWoteRSdxTin6cU/yusD9zvH75fijLp8TtdSHfh5j/wBuueg+DoWGzDKmYKuGhGxfyq +5SHvRP0zQ5zTNceqKPLrlPUZTECnLGeJT9hqTXMjuRVHzCHGPWoyAUVyZ2tFxFxENUC cIKPqxWLBgsuz3LNr8i36oKbaSRrVmY6iZJDvVfyCXIyw7Bg58woVpp3T9RE6EF+C8qK CVbA==
X-Gm-Message-State: ALoCoQkgnuACve6jwNQZXlEBLGS/KCy2kApmcDLAgacbGLgtBFf290MmOqtR1NbkZDGXdbaQ6OC/
X-Received: by 10.180.20.163 with SMTP id o3mr102540593wie.12.1417606637244; Wed, 03 Dec 2014 03:37:17 -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 ud1sm35912826wjc.7.2014.12.03.03.37.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 03:37:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9B240F07-FDAE-4366-BCFA-216F8C745E36"; 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: <547EF145.5030501@gmx.net>
Date: Wed, 03 Dec 2014 08:37:14 -0300
Message-Id: <B0DA0AD6-DE2C-4ECB-B2E2-04F369AAD610@ve7jtb.com>
References: <547EF145.5030501@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QfXgcLfOrKoUm15X3fdGfCgRKe0
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: Wed, 03 Dec 2014 11:37:20 -0000

Thanks Hannes.

Other methods such as different hashes need to be added via extension specs.   

Are you saying that we should set minimum recommendations for them.

It is also possible that those methods might use something other than hashing.  Key agreement might be a possibility.

Those properties would all be requirements for selecting a different hash function.   We could add that as a requirement for extensions if you think that is appropriate.

John B.

> On Dec 3, 2014, at 8: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
> https://www.ietf.org/mailman/listinfo/oauth