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

Nat Sakimura sakimura at gmail.com
Thu Nov 7 23:15:39 UTC 2013


+1 That's much better.


2013/11/7 Anthony Nadalin <tonynad at microsoft.com>

> I'm OK with your suggested text
>
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
> Sent: Thursday, November 7, 2013 11:32 AM
> To: Anthony Nadalin
> Cc: Justin P. Richer; Torsten Lodderstedt; Openid-specs Ab
> Subject: Re: [Openid-specs-ab] Review Comments on Dyn Reg
>
> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131107/19ca237e/attachment-0001.html>


More information about the Openid-specs-ab mailing list