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

[Bill Mills <[e-mail]>]

Quoting from 7.1 
"It is RECOMMENDED that the output of a suitable random number generator be 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]
https://www.ietf.org/mailman/listinfo/oauth