Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

From: Derek Atkins <[email-masked]>
Date: Mon, 03 Jun 2013 22:00:32 -0400

Justin Richer <[email-masked]> writes:

>     I think the concern here is that rotation of client credential is not
>     something discussed before. Before we put it in the spec we should
>     consider the reasons for doing it and what problems it solves.
>
> The client doesn't get to choose when its credentials get rotated. It used to
> be able to, but now it's purely the server's choice, including whether or not
> it wants to rotate things at all. I think this confusion can be cleared up
> with the explicit lifecycle discussion getting pulled out into one place.

>From a security standpoint, either side should be able to rotate keys.
It should not be only one side's choice; either side should have the
option to refresh due to local policy (or worse, local knowledge of an
issue).

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Mon, 03 Jun 2013 22:16:41 -0400

Phil,

Phil Hunt <[email-masked]> writes:

> Not quite. I will call you. 
>
> I am saying we are transitioning from the old public client model. The new
> model proposes quasi-confidential characteristics but in some respects is
> missing key information from the public model.  Namely that a group of clients
> are related and there have common behaviour and security characteristics. 
>
> We need to add to the self-asserted model an assertion equiv to the old common
> client_id. That is all. 
>
> I am NOT looking for a proof of application identity here. That is too far.
> But certainly what we define here can open that door. 
>
> Phil

I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind together (in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Jun 2013 20:34:44 -0700

From an operational security and change management perspective it is absolutely critical to know what clients should be of the same software type and version. 

We have customers that will want to be able to approve what 3rd party software is used on their service. 

If the spec doesn't support it, i *will* force another standard. It seems trivial to maintain the notion of software is rather than another draft for two attributes. 

I have agreed to make this optional. 

Those that are arguing for are oidc and only google has production deployment. 

Finally when we did 6819 we were hammered by the iesg on the notion of authenticating legit software. I believe they will send the draft back if it leaves that issue entirely out of scope. 

Phil

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Jun 2013 20:37:32 -0700

Arg iphone types...
See below

Phil

On 2013-06-03, at 20:34, Phil Hunt <[email-masked]> wrote:

> If the spec doesn't support it, i *will*
it will
> force another standard. It seems trivial to maintain the notion of software is
software id
> rather than another draft for two attributes. 
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Jun 2013 20:39:34 -0700

Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 04 Jun 2013 07:32:29 +0200

Hi Phil,

isn't the initial registration token such a credential,  which allows to co-relate different instances of the same software? 

regards, 
Torsten.

Phil Hunt <[email-masked]> schrieb:

>Finally i believe the bb+ doesn't have the issue because they are
>solving with an initial authn credential that contains the same info. 
>
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Jun 2013 23:28:49 -0700

Yes. However the contents and format are out of scope.  

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <[email-masked]> wrote:

>>>> missing key information from the public m!
>>>>  odel. 
>>>> Namely that a group of clients
>>> constant, assertion that would bind to!
>>>  gether
>>> (in a non-authenticated

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Jun 2013 12:03:06 -0400

We used to have a mechanism for clients to rotate their client secret, 
but that was removed some drafts ago, after list discussion on its utility.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Jun 2013 12:45:46 -0400

I agree with the goal of standardizing on identifying software 
instances, but I think it's out of scope to do so inside of dynamic 
registration when most dynamic registration use cases don't need it and 
won't use it. I think that you've got to define discovery, assertion 
contents, and a few other things in order to make it work and 
interoperable across different services. Do we really want to define 
assertion formats and server/client discovery and processing rules 
inside of dynamic registration? I really don't think that's beneficial, 
either to dynamic registration itself or to the problem that the 
software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I 
will help work on it. Heck, I'll even help edit the thing (or things) if 
people want. But I strongly believe that it's a separate concern from 
dynamic client registration, and I think it needs to have its own proper 
discussion apart from that.

  -- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:
> On 2013-06-03, at 22:32, Torsten Lodderstedt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi Phil,
>>
>> isn't the initial registration token such a credential, which allows 
>> to co-relate different instances of the same software?
>>
>> regards,
>> Torsten.
>>
>>
>>
>> Phil Hunt <[email-masked] <mailto:[email-masked]>> schrieb:
>>
>>     On 2013-06-03, at 19:16, Derek Atkins <[email-masked]  <mailto:[email-masked]>> wrote:
>>
>>         Phil, Phil Hunt <[email-masked]
>>         <mailto:[email-masked]>> writes:
>>
>>             Not quite. I will call you. I am saying we are
>>             transitioning from the old public client model. The new
>>             model proposes quasi-confidential characteristics but in
>>             some respects is missing key information from the public
>>             m! odel. Namely that a group of clients are related and
>>             there have common behaviour and security characteristics.
>>             We need to add to the self-asserted model an assertion
>>             equiv to the old common client_id. That is all. I am NOT
>>             looking for a proof of application identity here. That is
>>             too far. But certainly what we define here can open that
>>             door. Phil
>>
>>         I think I understand what you're saying here. In the "old
>>         way", a public client had a constant client_id amongst all
>>         instances of that public client, whereas in the "new way", a
>>         public client will have different client_ids amongst all
>>         instances of that client. You feel this is a loss, whereas it
>>         seems most people seem to feel this change is okay. Since you
>>         are effectively the lone dissenter on this one topic, let me
>>         ask you a question: What is a technical reason that you need
>>         to have a constant, assertion that would bind to! gether (in
>>         a non-authenticated way) multiple instances of a client? I
>>         believe that Justin has provides some attacks against this;
>>         so I'm trying to understand, (with my chair hat on), why you
>>         need this functionality? With my security-mafia hat on, I
>>         feel like the old way was bad, and I much prefer the newer
>>         way where each instance of a client gets its own ID and a
>>         locally-stored secret. -derek -- Derek Atkins 617-623-3745
>>         [email-masked] <mailto:[email-masked]> www.ihtfp.com
>>         <http://www.ihtfp.com> Computer and Internet Security Consultant 
>>
>>     ------------------------------------------------------------------------
>>
>>     OAuth mailing list
>>     [email-masked]  <mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Tue, 04 Jun 2013 13:56:32 -0400

+1 for leaving dyn reg as is and working on a profile that enables this 
more domain specific scenario. I agree with Phil and Justine that it's 
important... I just don't think it should be put in the core dyn reg spec.

Thanks,
George

On 6/4/13 12:45 PM, Justin Richer wrote:
> registration when most dynamic registration use cases don't need it 
> and won't use it. I think that you've got to define discovery, 
> assertion contents, and a few other things in order to make it work 
> and interoperable across different services. Do we really want to 
> define assertion formats and server/client discovery and processing 
> rules inside of dynamic registration? I really don't think that's 
> beneficial, either to dynamic registration itself or to the problem 
> that the software instance tracking is trying to solve.
>
> will help work on it. Heck, I'll even help edit the thing (or things) 
> if people want. But I strongly believe that it's a separate concern 
> from dynamic client registration, and I think it needs to have its own 
> proper discussion apart from that.
>
>  -- Justin
>
>>>             there have common behaviour and security
>>>             characteristics. We need to add to the self-asserted
>>>             model an assertion equiv to the old common client_id.
>>>             That is all. I am NOT looking for a proof of application
>>>             identity here. That is too far. But certainly what we
>>>             define here can open that door. Phil
>>>
>>>         instances of that client. You feel this is a loss, whereas
>>>         it seems most people seem to feel this change is okay. Since
>>>         you are effectively the lone dissenter on this one topic,
>>>         let me ask you a question: What is a technical reason that
>>>         you need to have a constant, assertion that would bind to!
>>>         gether (in a non-authenticated way) multiple instances of a
>>>         client? I believe that Justin has provides some attacks
>>>         against this; so I'm trying to understand, (with my chair
>>>         hat on), why you need this functionality? With my
>>>         security-mafia hat on, I feel like the old way was bad, and
>>>         I much prefer the newer way where each instance of a client
>>>         gets its own ID and a locally-stored secret. -derek -- Derek
>>>         Atkins 617-623-3745 [email-masked] <mailto:[email-masked]>
>>>         www.ihtfp.com <http://www.ihtfp.com> Computer and Internet
>>>         Security Consultant 
>>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 04 Jun 2013 14:10:13 -0400

Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry 
Justin!

On 6/4/13 1:56 PM, George Fletcher wrote:
> +1 for leaving dyn reg as is and working on a profile that enables 
> this more domain specific scenario. I agree with Phil and Justine that 
> it's important... I just don't think it should be put in the core dyn 
> reg spec.
>
> Thanks,
> George
>
>> from dynamic client registration, and I think it needs to have its 
>> own proper discussion apart from that.
>>
>>  -- Justin
>>
>>> On 2013-06-03, at 22:32, Torsten Lodderstedt 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>> Hi Phil,
>>>>
>>>> isn't the initial registration token such a credential, which 
>>>> allows to co-relate different instances of the same software?
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>>
>>>>
>>>>             model proposes quasi-confidential characteristics but
>>>>             in some respects is missing key information from the
>>>>             public m! odel. Namely that a group of clients are
>>>>             related and there have common behaviour and security
>>>>             That is all. I am NOT looking for a proof of
>>>>             application identity here. That is too far. But
>>>>             certainly what we define here can open that door. Phil
>>>>
>>>>         instances of that public client, whereas in the "new way",
>>>>         a public client will have different client_ids amongst all
>>>>         it seems most people seem to feel this change is okay.
>>>>         Since you are effectively the lone dissenter on this one
>>>>         topic, let me ask you a question: What is a technical
>>>>         reason that you need to have a constant, assertion that
>>>>         would bind to! gether (in a non-authenticated way) multiple
>>>>         instances of a client? I believe that Justin has provides
>>>>         some attacks against this; so I'm trying to understand,
>>>>         (with my chair hat on), why you need this functionality?
>>>>         With my security-mafia hat on, I feel like the old way was
>>>>         bad, and I much prefer the newer way where each instance of
>>>>         a client gets its own ID and a locally-stored secret.
>>>>         -derek -- Derek Atkins 617-623-3745 [email-masked]
>>>>         <mailto:[email-masked]> www.ihtfp.com

---

From: "Anganes, Amanda L" <[email-masked]>
Date: Tue, 4 Jun 2013 18:17:18 +0000

+1

The fact that there has been so much discussion around this topic seems like a clear indicator to me that the group needs to carefully and precisely figure out the use cases and mechanisms needed to identify "application classes" or "client instances" (or whatever they should be called), in a secure and trustworthy manner. The security aspect is key here – otherwise we will end up with a situation like all the kerfluffle over the Implicit Grant and how it's not secure but everyone is using it (because it's easy) and it's bad for the OAuth 2.0 brand because it's not as secure.

Phil previously wrote:

However, I think everyone else has made pretty convincing arguments as to why that's not a door worth opening in *this* spec, and cracking it open by just dropping in a self-asserted application ID could cause much more trouble than it's worth. DynReg has clear extension points to add new parameters if needed, but I agree with Justin that there are a lot of other things that need to be defined and specified beyond just adding an extra parameter.

Let's get DynReg finished and then those that are interested can start work on an extension to it, to fill in what's needed for client instance identification.

--Amanda

From: Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 4, 2013 12:45 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: Derek Atkins <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

 -- Justin

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Phil,

regards,
Torsten.

Phil Hunt <[email-masked]<mailto:[email-masked]>> schrieb:

Phil

On 2013-06-03, at 19:16, Derek Atkins <[email-masked]<mailto:[email-masked]>> wrote:

Phil,

Phil Hunt <[email-masked]<mailto:[email-masked]>> writes:

Phil

-derek

--
Derek Atkins                 617-623-3745
[email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com>
Computer and Internet Security Consultant

________________________________

OAuth mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Jun 2013 14:34:25 -0400

No problem, Georgia. :)

On 06/04/2013 02:10 PM, George Fletcher wrote:
>> this more domain specific scenario. I agree with Phil and Justine 
>> that it's important... I just don't think it should be put in the 
>> core dyn reg spec.
>>
>> Thanks,
>> George
>>
>>> If this gets proposed as a separate document, I will support it and 
>>> I will help work on it. Heck, I'll even help edit the thing (or 
>>> things) if people want. But I strongly believe that it's a separate 
>>> concern from dynamic client registration, and I think it needs to 
>>> have its own proper discussion apart from that.
>>>
>>>  -- Justin
>>>
>>>>>             transitioning from the old public client model. The
>>>>>             new model proposes quasi-confidential characteristics
>>>>>             but in some respects is missing key information from
>>>>>             the public m! odel. Namely that a group of clients are
>>>>>         would bind to! gether (in a non-authenticated way)
>>>>>         multiple instances of a client? I believe that Justin has
>>>>>         provides some attacks against this; so I'm trying to
>>>>>         understand, (with my chair hat on), why you need this
>>>>>         functionality? With my security-mafia hat on, I feel like
>>>>>         the old way was bad, and I much prefer the newer way where
>>>>>         each instance of a client gets its own ID and a

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Jun 2013 00:27:36 +0200

+1

Sent from my iPhone

On 2013-06-04, at 7:56 PM, George Fletcher <[email-masked]> wrote:

> +1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec.
> 
> Thanks,
> George
>