Subject: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

From: Brian Campbell <[email-masked]>
Date: Fri, 9 May 2014 14:51:01 -0600

I notice that code_verifier is defined as "high entropy cryptographic
random string of length less than 128 bytes"  [1], which brought a few
questions and comments to mind. So here goes:

Talking about the length of a string in terms of bytes is always
potentially confusing. Maybe characters would be an easier unit for people
like me to wrap their little brains around?

Why are we putting a length restriction on the code_verifier anyway? It
seems like it'd be more appropriate to restrict the length of the
code_challenge because that's the thing the AS will have to maintain
somehow (store in a DB or memory or encrypt into the code). Am I missing
something here?

Let me also say that I hadn't looked at this document since its early days
in draft -00 or -01 last summer but I like the changes and how it's been
kept pretty simple for the common use-case while still allowing for crypto
agility/extension. Nice work!

[1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3

---

From: Derek Atkins <[email-masked]>
Date: Mon, 12 May 2014 17:15:17 -0400

Brian Campbell <[email-masked]> writes:

> I notice that code_verifier is defined as "high entropy cryptographic random
> string of length less than 128 bytes"  [1], which brought a few questions and
> comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always potentially
> confusing. Maybe characters would be an easier unit for people like me to wrap
> their little brains around?

It depends if it really is characters or bytes.  For example there are
many multi-byte UTF-8 characters, so if it really is bytes then saying
characters is wrong because it could overflow.  So let's make sure we
know what we're talking about.  Historically, if we're talking bytes the
IETF often uses the phrase "octets".  Would that be less confusing?

> Why are we putting a length restriction on the code_verifier anyway? It seems
> like it'd be more appropriate to restrict the length of the code_challenge
> because that's the thing the AS will have to maintain somehow (store in a DB
> or memory or encrypt into the code). Am I missing something here?
>
> Let me also say that I hadn't looked at this document since its early days in
> draft -00 or -01 last summer but I like the changes and how it's been kept
> pretty simple for the common use-case while still allowing for crypto agility/
> extension. Nice work!
>

-derek

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: John Bradley <[email-masked]>
Date: Mon, 12 May 2014 23:48:13 +0200

I think octets is more consistent with other JW* and OAuth specs.

The code_challange is the same length as the code_verifyer or is a hash of the code_verifyer so likely smaller than 128octets (43 ish for base64 256 bit)

Limiting the code_verifyer size sets the upper bound for code_challange, unless someone comes up with a really creative code challenge algorithm.

I will talk to nat about changing it to octets when I see him tomorrow.  

John B.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 12 May 2014 15:50:20 -0600

Yeah, it does depend on what it really is and why the length needs to be
restricted. That's what the other questions were really about.

Octets would be better than bytes, if that's what's intended.

On Mon, May 12, 2014 at 3:15 PM, Derek Atkins <[email-masked]> wrote:

> random
> potentially
> seems

-- 
    <https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
  @ [email-masked]   +1 720.317.2061  Connect
with us…   <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> [image: Google+
logo]<https://plus.google.com/u/0/114266977739397708540> [image:
slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard
logo] <http://flip.it/vjBF7> [image: rss feed
icon]<https://www.pingidentity.com/blogs/>
   [image: Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19–23 July, 2014 | Monterey,
CA]<https://www.cloudidentitysummit.com/>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 12 May 2014 15:54:02 -0600

Right but that's why I'm asking why not just put the limit on
code_challange rather than inferring it from code_verifyer + challenge
algorithm, which probably bounds it but doesn't necessarily do so? It's not
a big deal but would read more clearly, I think.

On Mon, May 12, 2014 at 3:48 PM, John Bradley <[email-masked]> wrote:

> The code_challange is the same length as the code_verifyer or is a hash of
> the code_verifyer so likely smaller than 128octets (43 ish for base64 256
> bit)
>
> Limiting the code_verifyer size sets the upper bound for code_challange,
> unless someone comes up with a really creative code challenge algorithm.
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 12 May 2014 15:56:28 -0600

And it'd give the AS some direct guidance on protecting itself from crazy
long code_challenge values rather than relying on the client not to do
something creative.

On Mon, May 12, 2014 at 3:54 PM, Brian Campbell
<[email-masked]>wrote:

>> The code_challange is the same length as the code_verifyer or is a hash
>> of the code_verifyer so likely smaller than 128octets (43 ish for base64
>> 256 bit)
>>
>> >> [1]
>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>> >
>> > -derek
>> >
> logo] <https://www.facebook.com/pingidentitypage> <https://plus.google.com/u/0/114266977739397708540> [image:
> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
> flipboard logo] <http://flip.it/vjBF7> <https://www.pingidentity.com/blogs/>
> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 13 May 2014 15:52:24 +0900

+1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while
at the same time complaining in Jose that it should be "octet". JW* changed
to "octet" but I failed to sync with it in the last few edits.

I do not quite remember which platform, but the reason for the limit was
that some platform had some limitations as to the length of the sting to be
passed to it through URI and we did not want the challenges to be truncated
by that limit.

Best,

Nat

2014-05-13 6:56 GMT+09:00 Brian Campbell <[email-masked]>:

> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <
> [email-masked]> wrote:
>

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 14 May 2014 12:37:54 +0100

Hi

Section 3.2 [1] mentions that "If the algorithm is
registered, the server MUST reject any request that does not conform
to the algorithm"

I wonder is this text adds anything extra in addition to what Section 
3.7 [2] says where the server is required to reject the request if the 
verifier and the challenge do not match ?

I don't understand how registering the supported algorithms helps given 
that the client only provides a code_verifier

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.2
[2] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.7

---

From: Brian Campbell <[email-masked]>
Date: Wed, 14 May 2014 05:46:24 -0600

That too would suggest that the length limit be on code_challenge because
that's the parameter that will be on URIs getting passed around. The
code_verifier is sent directly in the POST body from client to AS.

On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <[email-masked]> wrote:

>>>> Limiting the code_verifyer size sets the upper bound for
>>>> code_challange, unless someone comes up with a really creative code
>>>> challenge algorithm.
>>>>
>>> LinkedIn logo] <https://www.linkedin.com/company/21870> [image:
>>> Facebook logo] <https://www.facebook.com/pingidentitypage> [image:
>>> Google+ logo] <https://plus.google.com/u/0/114266977739397708540> [image:

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 16 May 2014 22:10:11 +0900

Now that I cannot remember what limit we were hitting, it might be a good
idea to remove the constraint and see if anyone protests.

What do you think?

Nat

2014-05-14 20:46 GMT+09:00 Brian Campbell <[email-masked]>:

>> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here,
>> while at the same time complaining in Jose that it should be "octet". JW*
>> changed to "octet" but I failed to sync with it in the last few edits.
>>
>>>> On Mon, May 12, 2014 at 3:48 PM, John Bradley <[email-masked]>wrote:
>>>>
>>>>> The code_challange is the same length as the code_verifyer or is a
>>>>> hash of the code_verifyer so likely smaller than 128octets (43 ish for
>>>>> base64 256 bit)
>>>>>

---

From: John Bradley <[email-masked]>
Date: Fri, 16 May 2014 15:41:45 +0200

From the AS side you probably want to know what the max size you need to store per code.

On the call to the token endpoint it is a POST so size should not be an issue.  

On May 16, 2014, at 3:10 PM, Nat Sakimura <[email-masked]> wrote:

> Now that I cannot remember what limit we were hitting, it might be a good idea to remove the constraint and see if anyone protests. 
> 
> What do you think? 
> 
> Nat
> 
> 
> That too would suggest that the length limit be on code_challenge because that's the parameter that will be on URIs getting passed around. The code_verifier is sent directly in the POST body from client to AS. 
> 
> 
> +1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while at the same time complaining in Jose that it should be "octet". JW* changed to "octet" but I failed to sync with it in the last few edits. 
> 
> I do not quite remember which platform, but the reason for the limit was that some platform had some limitations as to the length of the sting to be passed to it through URI and we did not want the challenges to be truncated by that limit. 
> 
> Best, 
> 
> Nat
> 
> 
> And it'd give the AS some direct guidance on protecting itself from crazy long code_challenge values rather than relying on the client not to do something creative. 
> 
> 
> On Mon, May 12, 2014 at 3:54 PM, Brian Campbell <[email-masked]> wrote:
> Right but that's why I'm asking why not just put the limit on code_challange rather than inferring it from code_verifyer + challenge algorithm, which probably bounds it but doesn't necessarily do so? It's not a big deal but would read more clearly, I think.
> 
> 
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…
>        
> 
> 
> 
> 
> -- 
> 	
> Brian Campbell
> Portfolio Architect
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…
>        
> 
> 
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…
>        
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)

---

From: Brian Campbell <[email-masked]>
Date: Fri, 16 May 2014 10:32:14 -0600

Yeah, I agree with John here. There are a few good reasons to restrict the
length of the code_challenge. One is trying to keep the authorization
request URI to reasonable size as it will eventually run into various
limits on clients and/or servers. The other is constraining the amount of
data that an AS needs to store per code.

On Fri, May 16, 2014 at 7:41 AM, John Bradley <[email-masked]> wrote:

>> On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura <[email-masked]>wrote:
>>
>>> And it'd give the AS some direct guidance on protecting itself from
>>>> crazy long code_challenge values rather than relying on the client not to
>>>> do something creative.
>>>>
>>>>

---

From: Naveen Agarwal <[email-masked]>
Date: Fri, 16 May 2014 10:11:05 -0700

I think having a limit is much better (to increase compatibility) than not
having one.  If servers code developers will have to make a decision on the
length they should accept and they'll all select a different one and cause
issues.

Of course the browser URL size have limits and having much larger than 128
octets is not improving the security much.

Thanks

Naveen

On Fri, May 16, 2014 at 9:32 AM, Brian Campbell
<[email-masked]>wrote:

>>> That too would suggest that the length limit be on code_challenge
>>> because that's the parameter that will be on URIs getting passed around.
>>> The code_verifier is sent directly in the POST body from client to AS.
>>>
>>>
>>>> I do not quite remember which platform, but the reason for the limit
>>>> was that some platform had some limitations as to the length of the sting
>>>> to be passed to it through URI and we did not want the challenges to be
>>>> truncated by that limit.
>>>>
>>>> Best,
>>>>
>>>> Nat
>>>>
>>>>

---

From: Bill Mills <[email-masked]>
Date: Fri, 16 May 2014 14:27:21 -0700 (PDT)

The HTTP specs don't limit these things, but implementations do, and the problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of RECOMMENDED or SHOULD?

On Friday, May 16, 2014 9:35 AM, Brian Campbell <[email-masked]> wrote:
 
Yeah, I agree with John here. There are a few good reasons to restrict the length of the code_challenge. One is trying to keep the authorization request URI to reasonable size as it will eventually run into various limits on clients and/or servers. The other is constraining the amount of data that an AS needs to store per code.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 20 May 2014 06:09:43 -0600

I'd say it should be a MUST so that implementations are consistent about it.

On Fri, May 16, 2014 at 3:27 PM, Bill Mills <[email-masked]> wrote:

> The HTTP specs don't limit these things, but implementations do, and the
> problems when you run into them are a rea pain.
>
>   Yeah, I agree with John here. There are a few good reasons to restrict
> the length of the code_challenge. One is trying to keep the authorization
>  @ [email-masked]  +1 720.317.2061 Connect with
> us…  <https://twitter.com/pingidentity> [image:
>  @ [email-masked]  +1 720.317.2061 Connect with
> us…  <https://twitter.com/pingidentity> [image:
>  @ [email-masked]  +1 720.317.2061 Connect with
> us…  <https://twitter.com/pingidentity> [image:

---

From: Anil Saldhana <[email-masked]>
Date: Tue, 20 May 2014 08:56:59 -0500

Brian - I agree with you.  It should be MUST as long as the hard limit 
is generous for usage.

On 05/20/2014 07:09 AM, Brian Campbell wrote:
> On Fri, May 16, 2014 at 3:27 PM, Bill Mills <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The HTTP specs don't limit these things, but implementations do,
>     and the problems when you run into them are a rea pain.
>
>     On Friday, May 16, 2014 9:35 AM, Brian Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     Yeah, I agree with John here. There are a few good reasons to
>     restrict the length of the code_challenge. One is trying to keep
>     the authorization request URI to reasonable size as it will
>     eventually run into various limits on clients and/or servers. The
>     other is constraining the amount of data that an AS needs to store
>     per code.
>
>
>
>
>     On Fri, May 16, 2014 at 7:41 AM, John Bradley <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         On May 16, 2014, at 3:10 PM, Nat Sakimura <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>>         Now that I cannot remember what limit we were hitting, it
>>         might be a good idea to remove the constraint and see if
>>         anyone protests.
>>
>>         What do you think?
>>
>>         Nat
>>
>>
>>         2014-05-14 20:46 GMT+09:00 Brian Campbell
>>         <[email-masked] <mailto:[email-masked]>>:
>>
>>             That too would suggest that the length limit be on
>>             code_challenge because that's the parameter that will be
>>             on URIs getting passed around. The code_verifier is sent
>>             directly in the POST body from client to AS.
>>
>>
>>             On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 +1 for octet. We used to have "bytes" in JW* so I
>>                 used "bytes" here, while at the same time complaining
>>                 in Jose that it should be "octet". JW* changed to
>>                 "octet" but I failed to sync with it in the last few
>>                 edits.
>>
>>                 I do not quite remember which platform, but the
>>                 reason for the limit was that some platform had some
>>                 limitations as to the length of the sting to be
>>                 passed to it through URI and we did not want the
>>                 challenges to be truncated by that limit.
>>
>>                 Best,
>>
>>                 Nat
>>
>>
>>                 2014-05-13 6:56 GMT+09:00 Brian Campbell
>>                 <[email-masked]
>>                 <mailto:[email-masked]>>:
>>
>>                     And it'd give the AS some direct guidance on
>>                     protecting itself from crazy long code_challenge
>>                     values rather than relying on the client not to
>>                     do something creative.
>>
>>
>>                     <[email-masked]
>>                     <mailto:[email-masked]>> wrote:
>>
>>                         Right but that's why I'm asking why not just
>>                         put the limit on code_challange rather than
>>                         inferring it from code_verifyer + challenge
>>                         algorithm, which probably bounds it but
>>                         doesn't necessarily do so? It's not a big
>>                         deal but would read more clearly, I think.
>>
>>
>>                         On Mon, May 12, 2014 at 3:48 PM, John Bradley
>>                         <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>                             The code_challange is the same length as
>>                             the code_verifyer or is a hash of the
>>                             code_verifyer so likely smaller than
>>                             128octets (43 ish for base64 256 bit)
>>
>>                             Limiting the code_verifyer size sets the
>>                             upper bound for code_challange, unless
>>                             someone comes up with a really creative
>>                             code challenge algorithm.
>>
>>                             On May 12, 2014, at 11:15 PM, Derek
>>                             Atkins <[email-masked]
>>                             <mailto:[email-masked]>> wrote:
>>
>>                             > Brian Campbell
>>                             <[email-masked]
>>                             <mailto:[email-masked]>> writes:
>>                             >
>>                             >> confusing. Maybe characters would be
>>                             an easier unit for people like me to wrap
>>                             >> Why are we putting a length
>>                             restriction on the code_verifier anyway?
>>                             It seems
>>                             >> like it'd be more appropriate to
>>                             restrict the length of the code_challenge
>>                             >> [email-masked] <mailto:[email-masked]>
>>                             >>
>>                             > [email-masked]
>>                             <mailto:[email-masked]>                
>>                                    PGP key available
>>                         Ping Identity logo
>>                         <mailto:[email-masked]>
>>                         phone 	+1 720.317.2061
>>                         Connect with us...
>>                         twitter logo
>>                         <https://twitter.com/pingidentity> youtube
>>                         logo
>>                         <https://www.youtube.com/user/PingIdentityTV>
>>                         LinkedIn logo
>>                         <https://www.linkedin.com/company/21870>
>>                         Facebook logo
>>                         <https://www.facebook.com/pingidentitypage>
>>                         Google+ logo
>>                         <https://plus.google.com/u/0/114266977739397708540>
>>                         slideshare logo
>>                         <http://www.slideshare.net/PingIdentity>
>>                         flipboard logo <http://flip.it/vjBF7> rss
>>                         feed icon <https://www.pingidentity.com/blogs/>
>>
>>                         Register for Cloud Identity Summit 2014 |
>>                         Modern Identity Revolution | 19--23 July,
>>                         2014 | Monterey, CA
>>                         <https://www.cloudidentitysummit.com/>
>>
>>
>>
>>
>>
>>                     -- 
>>                     Ping Identity logo <https://www.pingidentity.com/> 	
>>                     Brian Campbell
>>                     Portfolio Architect
>>                     <mailto:[email-masked]>
>>                     phone 	+1 720.317.2061
>>                     Connect with us...
>>                     twitter logo <https://twitter.com/pingidentity>
>>                     youtube logo
>>                     <https://www.youtube.com/user/PingIdentityTV>
>>                     LinkedIn logo
>>                     <https://www.linkedin.com/company/21870> Facebook
>>                     logo <https://www.facebook.com/pingidentitypage>
>>                     Google+ logo
>>                     <https://plus.google.com/u/0/114266977739397708540>
>>                     slideshare logo
>>                     <http://www.slideshare.net/PingIdentity>
>>                     flipboard logo <http://flip.it/vjBF7> rss feed
>>                     icon <https://www.pingidentity.com/blogs/>
>>
>>                     Register for Cloud Identity Summit 2014 | Modern
>>                     Identity Revolution | 19--23 July, 2014 |
>>                     Monterey, CA <https://www.cloudidentitysummit.com/>
>>
>>
>>
>>                     [email-masked] <mailto:[email-masked]>
>>             Ping Identity logo <https://www.pingidentity.com/> 	
>>             Brian Campbell
>>             Portfolio Architect
>>             <mailto:[email-masked]>
>>             phone 	+1 720.317.2061
>>             Connect with us...
>>             twitter logo <https://twitter.com/pingidentity> youtube
>>             logo <https://www.youtube.com/user/PingIdentityTV>
>>             LinkedIn logo <https://www.linkedin.com/company/21870>
>>             Facebook logo <https://www.facebook.com/pingidentitypage>
>>             Google+ logo
>>             <https://plus.google.com/u/0/114266977739397708540>
>>             slideshare logo <http://www.slideshare.net/PingIdentity>
>>             flipboard logo <http://flip.it/vjBF7> rss feed icon
>>             <https://www.pingidentity.com/blogs/>
>>
>>             Register for Cloud Identity Summit 2014 | Modern Identity
>>             Revolution | 19--23 July, 2014 | Monterey, CA
>>             <https://www.cloudidentitysummit.com/>
>>
>>
>>
>>
>>
>>         -- 
>>         Nat Sakimura (=nat)
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 May 2014 10:11:11 +0900

Good! I achieve the purpose :-)

So what would be the appropriate length?
The current one would do?

2014-05-20 22:56 GMT+09:00 Anil Saldhana <[email-masked]>:

> On Fri, May 16, 2014 at 3:27 PM, Bill Mills <[email-masked]>wrote:
>
>>  The HTTP specs don't limit these things, but implementations do, and
>> the problems when you run into them are a rea pain.
>>
>> restrict the length of the code_challenge. One is trying to keep the
>> authorization request URI to reasonable size as it will eventually run into
>> various limits on clients and/or servers. The other is constraining the
>> amount of data that an AS needs to store per code.
>>
>>
>>
>>
>>  Now that I cannot remember what limit we were hitting, it might be a
>> good idea to remove the constraint and see if anyone protests.
>>
>>  What do you think?
>>
>>  Nat
>>
>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 21 May 2014 21:25:52 -0400

I think the current one is probably a OK compromise. 

Sent from my iPhone

> On May 21, 2014, at 9:11 PM, Nat Sakimura <[email-masked]> wrote:
> 
>> Brian - I agree with you.  It should be MUST as long as the hard limit is generous for usage.
>> 
>> 
>> 
>>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 May 2014 10:38:36 +0900

Some more questions.

Q1. Length limitation on

   1. code_challenge only
   2. code_verifier only
   3. both

Q2. Length in

   1. Octents
   2. Number of characters

My preference for Q2 is 1. as number of characters would not dictate the
actual length. A character is variable in length.

---

From: John Bradley <[email-masked]>
Date: Wed, 21 May 2014 23:02:45 -0400

Q1 should be both.  Limiting one but not the other is confusing to developers.  In the default case they are always the same size.

Q2 Octets 

John B.

On May 21, 2014, at 9:38 PM, Nat Sakimura <[email-masked]> wrote:

> Some more questions. 
> 
> Q1. Length limitation on 
> code_challenge only
> code_verifier only
> both
> Q2. Length in
> Octents
> Number of characters
> My preference for Q2 is 1. as number of characters would not dictate the actual length. A character is variable in length. 
> 
>