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

[Naveen Agarwal <[e-mail]>]

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
<[e-mail]>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 <[e-mail]> wrote:
>
>> 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 <[e-mail]> 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 <[e-mail]>:
>>
>>> 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 <[e-mail]>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 <[e-mail]>:
>>>>
>>>> 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 <
>>>>> [e-mail]> 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 <[e-mail]>wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> On May 12, 2014, at 11:15 PM, Derek Atkins <[e-mail]> wrote:
>>>>>>>
>>>>>>> > Brian Campbell <[e-mail]> 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!
>>>>>>> >>
>>>>>>> >> [1]
>>>>>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
>>>>>>> >
>>>>>>> > -derek
>>>>>>> >
>>>>>>> >> _______________________________________________
>>>>>>> >> OAuth mailing list
>>>>>>> >> [e-mail]
>>>>>>> >> 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
>>>>>>> >       [e-mail]                        PGP key available
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>>>>> Brian Campbell
>>>>>> Portfolio Architect
>>>>>>   @ [e-mail]  [image: phone] +1 720.317.2061  Connect
>>>>>> with us…  [image: twitter logo] <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/>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>>>> Brian Campbell
>>>>> Portfolio Architect
>>>>>   @ [e-mail]  [image: phone] +1 720.317.2061  Connect
>>>>> with us…  [image: twitter logo] <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/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>>
>>>
>>>
>>>
>>> --
>>>    [image: Ping Identity logo] <https://www.pingidentity.com/>
>>> Brian Campbell
>>> Portfolio Architect
>>>   @ [e-mail]  [image: phone] +1 720.317.2061  Connect
>>> with us…  [image: twitter logo] <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/>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>