[Openid-specs-ab] Transient Client Secret Extension for OAuth

Nat Sakimura sakimura at gmail.com
Mon Jul 29 12:51:55 UTC 2013


Oh... Do you guys think that it is ready to be sent to the OAuth list?

Nat


2013/7/29 Nat Sakimura <sakimura at gmail.com>

> The sentiment of the group seems to be that we are concerned with preimage
> resistance here and not the collision resistance.
> Brian, Dirk, and me is supporting simple hash in this view, IMHO. John is
> supporting salted hash siting the collision resistance importance.
>
> As an editor, for the time being, keeping 2^128 search space is more
> important than restricting the possibility of collision.
> So I have reverted the salted hash to hash. I am happy to re-introduce
> salted hash if more convincing argument is put forward.
> (That's the beauty of version control system :-)
>
> Nat
>
>
>
> 2013/7/29 Nat Sakimura <sakimura at gmail.com>
>
>> OK. I will keep it as transient client secret hash, tcsh.
>>
>>
>> 2013/7/29 Torsten Lodderstedt <torsten at lodderstedt.net>
>>
>>> **
>>>
>>> don't use "request token", please! I expect this to totally confuse
>>> people. Probably request secret or similar.
>>>
>>> Am 29.07.2013 14:27, schrieb Nat Sakimura:
>>>
>>> Good catch.
>>>
>>> I am also thinking of change the name for client secret hash to request
>>> token, and parameter name from 'tcsh' to 'rt'.
>>> Also, I am thinking of reverting salted hash to just a hash per the
>>> discussion with Dirk.
>>>
>>> What do you think?
>>>
>>>
>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>
>>>>  In general, those changes look good to me. Though 2nd paragraph of
>>>> section 1 still says "this extension utilizes OpenID Server Configuration
>>>> Document" which should probably be removed now.
>>>>
>>>> I am also unsure about needing to salt the hash.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jul 29, 2013 at 12:26 PM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>>
>>>>> Updated the draft.
>>>>>
>>>>> Changes:
>>>>>
>>>>> * Removed the discovery, and made the method to find out the server
>>>>> capability out-of-scope.
>>>>> * Salted the hash. <<< Still not sure but for the time being.
>>>>> * Fixed the working group and area
>>>>>
>>>>>
>>>>>
>>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>>
>>>>>>   I'm just trying to be realistic.
>>>>>>
>>>>>> The client can send the values regardless of if the sever supports
>>>>>> this or not.
>>>>>>
>>>>>> If a client really cares enough and will not use the AS if this isn't
>>>>>> supported, it can find out out of band. Or it's easy enough to test it out.
>>>>>>
>>>>>> Most clients are written to a particular AS so they'll know already.
>>>>>> Libraries are more general and they need to support it first.
>>>>>>
>>>>>> Connect (and eventually general OAuth) can put this in dico. But the
>>>>>> basic functionality doesn't need to address that.
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 29, 2013 at 9:45 AM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>>>>
>>>>>>> Hmmm. Then, the client has lost its capability to find out whether
>>>>>>> the server is secure or not dynamically.
>>>>>>> Do you mean that the client should find it out out-of-band?
>>>>>>> That's possible, and is more OAuthy.
>>>>>>>
>>>>>>> So, instead of current 3.2, it can just state :
>>>>>>>
>>>>>>> The client MUST find out if the server supports this mode before
>>>>>>> issuing the authorizaiton request. The exact method of how it can be done
>>>>>>> is out of scope.
>>>>>>>
>>>>>>> Is that what you mean?
>>>>>>>
>>>>>>> Nat
>>>>>>>
>>>>>>>
>>>>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>>>>
>>>>>>>> Pretty much just removing 3.1 and 3.2 and 2.2 from your draft.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 29, 2013 at 9:36 AM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Yup. It is too late. The client needs to know whether the server
>>>>>>>>> is secure or not to start with.
>>>>>>>>>
>>>>>>>>> > I still think that a base definition of this shouldn't try and
>>>>>>>>> address discovering or publishing support for the functionality.
>>>>>>>>>
>>>>>>>>>  Could you kindly propose a concrete method? A concrete text
>>>>>>>>> would be even better.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>>>>>>
>>>>>>>>>>  As John pointed out, putting metainfo about support into the
>>>>>>>>>> token response is too late in the flow.
>>>>>>>>>>
>>>>>>>>>> I still think that a base definition of this shouldn't try and
>>>>>>>>>> address discovering or publishing support for the functionality.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 29, 2013 at 9:28 AM, Nat Sakimura <sakimura at gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> OK. Fair enough.
>>>>>>>>>>>
>>>>>>>>>>> I will change it to the invalid_grant.
>>>>>>>>>>>
>>>>>>>>>>> What do you think about the idea for "meta"?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>>>>>>>>
>>>>>>>>>>>> It's really not client authentication. It's something that
>>>>>>>>>>>> links the initial authorization request with the corresponding access token
>>>>>>>>>>>> request, which enables detecting a particular problem/attack. Similar to a
>>>>>>>>>>>> mismatch on the redirect URI value between the authorization request and
>>>>>>>>>>>> the corresponding access token request, it's the grant (or transaction)
>>>>>>>>>>>> that is invalid.
>>>>>>>>>>>>
>>>>>>>>>>>> http://tools.ietf.org/html/rfc6749#section-5.2
>>>>>>>>>>>>
>>>>>>>>>>>>            invalid_grant
>>>>>>>>>>>>                The provided authorization grant (e.g., authorization
>>>>>>>>>>>>                code, resource owner credentials) or refresh token is
>>>>>>>>>>>>                invalid, expired, revoked, does not match the redirection
>>>>>>>>>>>>                URI used in the authorization request, or was issued to
>>>>>>>>>>>>                another client.
>>>>>>>>>>>>
>>>>>>>>>>>> Discovery is maybe useful but is definitely not necessary. What
>>>>>>>>>>>> is necessary is to define the parameter(s) and their treatment on the
>>>>>>>>>>>> authorization request and access token request so that clients and servers
>>>>>>>>>>>> can interop.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 29, 2013 at 9:07 AM, Nat Sakimura <
>>>>>>>>>>>> sakimura at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Brian,
>>>>>>>>>>>>>
>>>>>>>>>>>>> inline:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  2013/7/29 Brian Campbell <bcampbell at pingidentity.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  IMHO, invalid_grant is the proper error response code, not
>>>>>>>>>>>>>> invalid_client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  I have thought a bit about that when I was writing it down.
>>>>>>>>>>>>> invalid_grant is concerned about the token which has been
>>>>>>>>>>>>> previously issued.
>>>>>>>>>>>>> invalid_client is concerned about the client authentication.
>>>>>>>>>>>>> In the initial path, I had it as invalid_grant, then, I
>>>>>>>>>>>>> thought - well, it is the client
>>>>>>>>>>>>> authentication that is failing when the client has provided
>>>>>>>>>>>>> invalid tcs.
>>>>>>>>>>>>> The code is correct. It is the client authentication which is
>>>>>>>>>>>>> going wrong, is it not?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Along the same lines, I'd like to see it named something more
>>>>>>>>>>>>>> like "message correlation id" rather than anything involving client secret.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  The name "message correlation identifier" does not convey
>>>>>>>>>>>>> the nature of the parameter, which is the high entropy credential for the
>>>>>>>>>>>>> client. Just for the sake of the correlation, it does not have to have a
>>>>>>>>>>>>> high entropy. Thus, I have chosen the name.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a general OAuth problem and I believe the solution
>>>>>>>>>>>>>> should be general too. Thus, at least the base definition of the
>>>>>>>>>>>>>> parameter(s) should not require discovery or rely on any of the Connect
>>>>>>>>>>>>>> documents.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  OAuth generally does not need discovery. However, this spec
>>>>>>>>>>>>> really needs it, at least in one form or another.
>>>>>>>>>>>>> I have thought of making a new file but then that would amount
>>>>>>>>>>>>> to having the client hit those discovery endpoints twice.
>>>>>>>>>>>>> I did not want the duplicate situation that resulted in the
>>>>>>>>>>>>> dynamic client registration. That's why I am referring OpenID Connect.
>>>>>>>>>>>>> OpenID Connect originated the Discovery and Registration. On
>>>>>>>>>>>>> the hind site, even registration should have been referring OpenID Connect
>>>>>>>>>>>>> documents instead of duplicating. At least, that's how academic papers work
>>>>>>>>>>>>> :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another idea is to have the metadata come back in the token
>>>>>>>>>>>>> response.
>>>>>>>>>>>>> I actually prefer this. It increases the server traffic a bit,
>>>>>>>>>>>>> though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The way it works is this.
>>>>>>>>>>>>> Instead of doing the discovery and caching it at the client,
>>>>>>>>>>>>> the client finds the server capability from the token endpoint reference.
>>>>>>>>>>>>> For this, the server includes something like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "meta": {
>>>>>>>>>>>>>    "tcs_supported":true;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> You guys know that I like this idea because then I would have
>>>>>>>>>>>>> a stub to put link relationship there as well.
>>>>>>>>>>>>> Do you like the idea? If so, I can update the draft in this
>>>>>>>>>>>>> manner.
>>>>>>>>>>>>> Well, perhaps I should anyways.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for pointing out.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nat
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  On Sun, Jul 28, 2013 at 9:39 PM, Nat Sakimura <
>>>>>>>>>>>>>> sakimura at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  As some of you knows, passing the code securely to a
>>>>>>>>>>>>>>> native app on iOS platform is next to impossible. Malicious application may
>>>>>>>>>>>>>>> register the same custom scheme as the victim application and hope to
>>>>>>>>>>>>>>> obtain the code, whose success rate is rather high.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We have discussed about it during the OpenID Conenct Meeting
>>>>>>>>>>>>>>> at IETF 87 today, and I have captured the discussion in the form of I-D. It
>>>>>>>>>>>>>>> is pretty short and hopefully easy to read.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You can find it at:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://bitbucket.org/Nat/drafts/src/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Comments are welcome.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Nat Sakimura (=nat)
>>>>>>>>>>>>>>> Chairman, OpenID Foundation
>>>>>>>>>>>>>>> http://nat.sakimura.org/
>>>>>>>>>>>>>>> @_nat_en
>>>>>>>>>>>>>>>   _______________________________________________
>>>>>>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Nat Sakimura (=nat)
>>>>>>>>>>>>> Chairman, OpenID Foundation
>>>>>>>>>>>>> http://nat.sakimura.org/
>>>>>>>>>>>>> @_nat_en
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Nat Sakimura (=nat)
>>>>>>>>>>> Chairman, OpenID Foundation
>>>>>>>>>>> http://nat.sakimura.org/
>>>>>>>>>>> @_nat_en
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nat Sakimura (=nat)
>>>>>>>>> Chairman, OpenID Foundation
>>>>>>>>> http://nat.sakimura.org/
>>>>>>>>> @_nat_en
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nat Sakimura (=nat)
>>>>>>> Chairman, OpenID Foundation
>>>>>>> http://nat.sakimura.org/
>>>>>>> @_nat_en
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/3ee11594/attachment-0001.html>


More information about the Openid-specs-ab mailing list