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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Dec 2014 12:17:25 +0100

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

---

From: John Bradley <[email-masked]>
Date: Wed, 3 Dec 2014 08:37:14 -0300

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 <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 03 Dec 2014 11:44:13 +0000

Thanks Hannes.

One question: we are recommending 32 octetes=256 bits to fill the sha256
range. Is there a reason for asking for a lesser entropy?
On 2014年12月3日(水) at 20:37 John Bradley <[email-masked]> wrote:

> 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.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Dec 2014 12:46:50 +0100

Hi John,

I believe it makes sense to give recommendations for extensions (if you
envision them). Of course, I hope that we do not see a flood of
extensions that all use different hash functions.

Changing the mechanism to something that provides even stronger security
properties would definitely require a new specification and review.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 3 Dec 2014 09:01:06 -0300

We have been thinking that new hash functions and new mechanisms (eg ECDH-ES) would be treated the same and require a spec and review. 

(At some point I will do a asymmetric extension so that the key can also be used to encrypt POP keys back to the client,  but I don't want to make this spec look to complicated)

Any mechanism using a challenge & verifier approach could fit in to the defined parameters,  a different hash like SHA3 is simple in that it just be a replacement of the hash function.

I think guidance id fine as long as it doesn't limit future options.

John B.

> On Dec 3, 2014, at 8:46 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi John,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Dec 2014 13:09:59 +0100

I just looked at the IANA consideration section and I noticed that there
is no policy defined for adding, or deprecating values from various
registries, such as the code_challenge_method.

So, you can essentially decide about how easy or difficult you can make
it for yourself.

I would think that 'Specification Required' would be appropriate.
You can copy the relevant text from
https://tools.ietf.org/html/rfc6749#section-11 and adjust it accordingly.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 3 Dec 2014 09:14:28 -0300

The only question is if the OAuth ext review list is the correct place for review.  

I don't have a problem with re using an existing review process for a new registry, if that works for people.

John B.

> On Dec 3, 2014, at 9:09 AM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Dec 2014 13:22:50 +0100

> The only question is if the OAuth ext review list is the correct place for review.  

I think it is.

---

From: Bill Mills <[email-masked]>
Date: Wed, 3 Dec 2014 18:10:07 +0000 (UTC)

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 <[email-masked]> wrote:

 Hi all,

S: store code_challenge
S: Send(Authz Grant,C)

"

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Dec 2014 10:50:00 +0100

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."
> 
> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Dec 2014 07:56:30 -0300

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 <[email-masked]> wrote:
> 
> Hi Bill,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Dec 2014 15:07:06 +0100

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).

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Dec 2014 12:14:52 -0300

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 <[email-masked]> wrote:
>