[Openid-specs-ab] Review Comments on Dyn Reg

[John Bradley]

The high level goal is that an attacker who knows some number of client_id and client secret pairs cannot guess what the client secret for other clieent_id are.

Someone could do something like have randomly generated client_id and use the same random value as the secret.  That would be unique and random but not secure.
Another could XOR the client_id with some static value to produce the secret.   That works until and attacker can get two client_id and there secrets and reverse out the key.

The simple wording is don't do stupid things to create the client secret.

Perhaps something like client_secrets need to be generated in a manner to have them be unguessable by an attacker who has access to other client_id and secrets generated by the AS.

John B.

On Nov 7, 2013, at 9:17 AM, Anthony Nadalin <tonynad at microsoft.com> wrote:

> There should be no requirement that the secret be tied to the client_id, this is an implementation choice on how authentication is done
> 
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Richer, Justin P.
> Sent: Thursday, November 7, 2013 9:01 AM
> To: Torsten Lodderstedt
> Cc: Openid-specs Ab
> Subject: Re: [Openid-specs-ab] Review Comments on Dyn Reg
> 
> 
> On Nov 7, 2013, at 8:03 AM, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:
> 
>> Hi,
>> 
>>>>> client_secret - "This MUST be unique for each client_id." - why 
>>>>> must the client secret be _unique_? This seems to be a rather hard requirement.
>>>> +1 on that
>>> If you're handing out client secrets that aren't uniquely tied to 
>>> client_ids, then you're going to end up with problems as some of your 
>>> dynamically registered clients are going to be able to more easily 
>>> impersonate each other. Normally this is a sufficiently random blob, 
>>> but it can be a signed blob or something else of that nature, too. 
>>> You can of course use credentials other than a client secret.
>> 
>> Client secrets must indeed be tight to client_ids. But as I read the text it requires the OP to issue secrets, which are unique over _all_ client secrets. This is more challenging than "sufficiently random" as it prohibits any duplicates/collisions.
> 
> OK, I can buy that, though I think it's a bit of an arbitrary distinction. So if you've got a suggestion for more exact specification of this principle, please provide better text. (I'll make sure to copy it to the OAuth draft too.)
> 
> -- Justin
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131107/af9f603d/attachment.p7s>