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

[Hannes Tschofenig <[e-mail]>]

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
> <[e-mail]> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
> 
>