[OAUTH-WG] SPOP: Code Challenge Discussion
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 03 December 2014 11:17 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 1E49A1A0AF7 for <oauth@ietfa.amsl.com>; Wed, 3 Dec 2014 03:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 P3RdkEsUkZwv for <oauth@ietfa.amsl.com>; Wed, 3 Dec 2014 03:17:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843821A0461 for <oauth@ietf.org>; Wed, 3 Dec 2014 03:17:29 -0800 (PST)
Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAgzj-1XkpPJ30Y7-00BpVp for <oauth@ietf.org>; Wed, 03 Dec 2014 12:17:26 +0100
Message-ID: <547EF145.5030501@gmx.net>
Date: Wed, 03 Dec 2014 12:17:25 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="HCWbhVFNNUJUourBcf0jPdCo2t0FuB7rN"
X-Provags-ID: V03:K0:h77EUFiNgvxci2/6mVs/P/ugaXzm5moUoyBwYS5sCcUnLY80Ej2 Sfkv8WG/XJjD3HVuBhK48QVrx7Zu1izlL0i7uyT0/73joT+1rRwa3PHHynb70avhT9v1tOj sesQLWiRpVU1qw9Iy528m/9rPJ2IjeNl9QMhmJiByer4QWg1EvR3duc4sAGU3iy7mHX6nbG 2T/kn0/zq0vl/bAvb7arw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/w5Sw68T-ZmovK3-IRnQrwOumMxw
Subject: [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:17:31 -0000
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
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion John Bradley
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion John Bradley
- [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Nat Sakimura
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion John Bradley
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion John Bradley
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Bill Mills
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion Hannes Tschofenig
- Re: [OAUTH-WG] SPOP: Code Challenge Discussion John Bradley