Subject: [OAUTH-WG] SPOP - code verifier requirements

From: Nat Sakimura <[email-masked]>
Date: Tue, 14 Oct 2014 18:26:11 +0900

In his mail, Mike asked whether code verifier is 
a value that is sendable without trnasformation 
as a http parameter value, or if it needs to be 
% encoded when it is being sent. 

We have several options here: 

1) Require that the code verifier to be a base64url encoded string of a binary random value.

2) Let code verifier to be a binary string and require it to be 
either % encoded or base64url encoded when it is sent.
In this case, which encoding should we use?  

3) require the code verifier to be conform to the following ABNF:
code_verifier = 16*128unreserved
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" 

Which one do you guys prefer? 

Nat

-- 
Nat Sakimura ([email-masked])
Nomura Research Institute, Ltd. 

PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Oct 2014 08:27:31 -0700

We went with base64url in our implementation

On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura <[email-masked]> wrote:

> If you are not an intended recipient of this e-mail, you are hereby
> notified that any review, dissemination, distribution or duplication of
> this message is strictly prohibited. If you have received this message in
> error, please notify the sender immediately and delete your copy from your
> system.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 16 Oct 2014 00:32:04 +0900

Thanks. 

So, to be clear, are you base64url encoding when sending it over the wire or is your code verifier is created by base64url encoding the binary value so that you do not need to encode it when sending it over? 

=nat via iPhone

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Oct 2014 11:48:47 -0700

We're actually debating it internally.   It seems easiest to just encode
the binary code up front.   Any issue with that?

- cmort

On Oct 15, 2014, at 8:32 AM, Nat Sakimura <[email-masked]> wrote:

Thanks.

So, to be clear, are you base64url encoding when sending it over the wire
or is your code verifier is created by base64url encoding the binary value
so that you do not need to encode it when sending it over?

=nat via iPhone

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 15 Oct 2014 21:12:09 +0100

Hi, in our project we ship a transformer implementation that assumes 
that a code verifier represents a base64url encoded SHA-256 hash of the 
code challenge

Cheers, Sergey
On 15/10/14 19:48, Chuck Mortimore wrote:
> On Oct 15, 2014, at 8:32 AM, Nat Sakimura <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Thanks.
>>
>> So, to be clear, are you base64url encoding when sending it over the
>> wire or is your code verifier is created by base64url encoding the
>> binary value so that you do not need to encode it when sending it over?
>>
>> =nat via iPhone
>>
>> Oct 16, 2014 00:27、Chuck Mortimore <[email-masked]
>> <mailto:[email-masked]>> のメッセージ:
>>
>>> On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>     Nat Sakimura ([email-masked] <mailto:[email-masked]>)
>>>     The information contained in this e-mail is confidential and
>>>     intended for the named recipient(s) only.
>>>     If you are not an intended recipient of this e-mail, you are
>>>     hereby notified that any review, dissemination, distribution or
>>>     duplication of this message is strictly prohibited. If you have
>>>     received this message in error, please notify the sender
>>>     immediately and delete your copy from your system.
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Sun, 19 Oct 2014 17:47:32 +0200

Hi,

using the base64url alphabet seems a reasonable choice.

kind regards,
Torsten.

Am 15.10.2014 22:12, schrieb Sergey Beryozkin:
> that a code verifier represents a base64url encoded SHA-256 hash of
> the code challenge
> 
> Cheers, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 14:13:31 -0600

In the default case, aren't the challenge and verifier just an arbitrary
string value? One that would be application/x-www-form-urlencoded on the
authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1)
and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like
any other parameter value? If the client uses unreserved characters then no
additional encoding is needed but I"m not sure I see any reason to restrict
it.

If a transform is used, I'd think that the transform defines how the octets
are represented as strings.

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 20 Oct 2014 15:25:52 -0500

So, for the default case, the intent was to use just the unreserved chars,
i.e.,

code_verifier =  code_challenge = 16*128unreserved
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

In sha256 case, I would expect the transform to conform to the constraint:
i.e., define such a transform
so that the end result expressed in code_verifier and code_challenge would
be expressed in unreserved.

Nat

2014-10-20 15:13 GMT-05:00 Brian Campbell <[email-masked]>:

> If a transform is used, I'd think that the transform defines how the
> octets are represented as strings.
>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Oct 2014 17:33:47 -0300

Yes for the default case it is a simple string comparison,  so not such a big issue.

It might still be possible to cause it to break by using a binary value and letting the underlying libraries do the encoding on the two calls to the authorization server.  They might possibly use different escaping,  or the server might unescape one back to binary and use the escaped version on the other input causing the comparison to fail.

I agree that base64url encoding is probably the safest for interoperability but will add a bit of processing on the client in the default case that might not be necessary if the verifier value is already URL safe by some other mechanism.

Given a desire to make a SHA256 transform MTI for servers, standardizing on base64url encoding of the values seems to make sense.

John B.

On Oct 20, 2014, at 5:13 PM, Brian Campbell <[email-masked]> wrote:

> In the default case, aren't the challenge and verifier just an arbitrary string value? One that would be application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other parameter value? If the client uses unreserved characters then no additional encoding is needed but I"m not sure I see any reason to restrict it.
> 
> If a transform is used, I'd think that the transform defines how the octets are represented as strings. 
> 
>

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Oct 2014 17:54:10 -0300

Part of the issue is that we want people to use a good source of entropy for this.   PRNG on the device seems like the most likely thing.  Those generally give you a an array of bytes.

Yes you could use anything to make them URL safe but that happens to be precisely what base64url is intended for.  

So while it is true that they could come up with some other way to do it, likely that is the result of doing something stupid around generating the values like using a fixed string with a counter.

In the default mode the AS is just doing a string compare so what the client uses to encode the string the string is probably not relevant to the server.    

Saying that the client MUST send a URL safe value vs letting it be encoded by the http lib is I think important for interoperability.

For the SHA256 version we are adding base64url encoding for both the hash and the string seem the best choice as well.

John B.

On Oct 20, 2014, at 5:25 PM, Nat Sakimura <[email-masked]> wrote:

> So, for the default case, the intent was to use just the unreserved chars, i.e., 
> 
> In sha256 case, I would expect the transform to conform to the constraint: i.e., define such a transform 
> so that the end result expressed in code_verifier and code_challenge would be expressed in unreserved. 
> 
> Nat
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Oct 2014 15:23:06 -0600

That all makes sense. And yeah, our AS side implementation just does a
string compare. I'd just really like to keep that compliant as the spec
gets updated. But being tighter about what the client can send doesn't
change anything there.

If the concern is about people using a good source of entropy, then
something to that effect should probably be said directly.

On Mon, Oct 20, 2014 at 2:54 PM, John Bradley <[email-masked]> wrote:

> Part of the issue is that we want people to use a good source of entropy
> for this.   PRNG on the device seems like the most likely thing.  Those
> generally give you a an array of bytes.
>
> Yes you could use anything to make them URL safe but that happens to be
> precisely what base64url is intended for.
>
> So while it is true that they could come up with some other way to do it,
> likely that is the result of doing something stupid around generating the
> values like using a fixed string with a counter.
>
> In the default mode the AS is just doing a string compare so what the
> client uses to encode the string the string is probably not relevant to the
> server.
>
> Saying that the client MUST send a URL safe value vs letting it be encoded
> by the http lib is I think important for interoperability.
>
> For the SHA256 version we are adding base64url encoding for both the hash
> and the string seem the best choice as well.
>
> John B.
>
>> and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3)
>> like any other parameter value? If the client uses unreserved characters
>> then no additional encoding is needed but I"m not sure I see any reason to
>> restrict it.
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Oct 2014 18:50:45 -0300

Saying that the string must be base64url encoded when sent to the AS shouldn't impact any servers doing a string compare.

Yes we are a touch vague about what constitutes high entropy.

On Oct 20, 2014, at 6:23 PM, Brian Campbell <[email-masked]> wrote:

> That all makes sense. And yeah, our AS side implementation just does a string compare. I'd just really like to keep that compliant as the spec gets updated. But being tighter about what the client can send doesn't change anything there.
> 
> If the concern is about people using a good source of entropy, then something to that effect should probably be said directly. 
>