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

[Brian Campbell <[e-mail]>]

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