Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

Phil Hunt <phil.hunt@oracle.com> Tue, 04 June 2013 04:33 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2591321E80EA for <oauth@ietfa.amsl.com>; Mon, 3 Jun 2013 21:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.471
X-Spam-Level:
X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eblqd+z3N0KJ for <oauth@ietfa.amsl.com>; Mon, 3 Jun 2013 21:33:09 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17621E8124 for <oauth@ietf.org>; Mon, 3 Jun 2013 20:35:04 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r543Z2dM005235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jun 2013 03:35:03 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r543Z1jo002463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 03:35:02 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r543Z1AY001361; Tue, 4 Jun 2013 03:35:01 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Jun 2013 20:35:01 -0700
References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <A1F47E63-DFE6-41A2-9F91-2DB44091D94C@oracle.com> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <B0C50AAD-97F0-4E55-A30D-C011B012A3DB@oracle.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <D4A8CBBB-2929-4B8D-BE05-086F895F0930@oracle.com> <519B9623.8030403@mitre.org> <C7C4CA9B-1C34-452A-B3C3-0BBE9EF1ECB7@oracle.com> <sjmr4gi4o3a.fsf@mocana.ihtfp.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <sjmr4gi4o3a.fsf@mocana.ihtfp.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6A7DF11-8F20-43FB-96DB-D8EF2FD3ED9E@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Mon, 3 Jun 2013 20:34:44 -0700
To: Derek Atkins <derek@ihtfp.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 04:33:26 -0000

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

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

> Phil,
> 
> Phil Hunt <phil.hunt@oracle.com> 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
> 
> -- 
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant