Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Mark Mcgloin <mark.mcgloin@ie.ibm.com> Wed, 29 September 2010 15:27 UTC

Return-Path: <mark.mcgloin@ie.ibm.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC213A6D00; Wed, 29 Sep 2010 08:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPzGkGeu-rz0; Wed, 29 Sep 2010 08:27:53 -0700 (PDT)
Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by core3.amsl.com (Postfix) with ESMTP id 7D00E3A6B0B; Wed, 29 Sep 2010 08:27:53 -0700 (PDT)
Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o8TFSaK9009038; Wed, 29 Sep 2010 15:28:36 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8TFSaIU3203282; Wed, 29 Sep 2010 16:28:36 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o8TFSZG1021876; Wed, 29 Sep 2010 16:28:36 +0100
Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o8TFSZCR021871; Wed, 29 Sep 2010 16:28:35 +0100
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BE4113B3-D849-4BA1-B8FC-975C636D1303@gmail.com> <OF4576070A.5F974BC0-ON802577AD.002AB50B-802577AD.002B9415@ie.ibm.com> <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-KeepSent: 142A94C3:963BF481-802577AD:0052B3D8; type=4; name=$KeepSent
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009
Message-ID: <OF142A94C3.963BF481-ON802577AD.0052B3D8-802577AD.005502A3@ie.ibm.com>
From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Wed, 29 Sep 2010 16:27:59 +0100
X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 29/09/2010 16:28:02
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: "oauth-bounces@ietf.org" <oauth-bounces@ietf.org>, "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 29 Sep 2010 15:27:54 -0000

Eran Hammer-Lahav <eran@hueniverse.com> wrote on 29/09/2010 15:50:33:

> >
> > -1 to splitting acquiring and using a token. It may not confuse
> people actively
> > engaged in the WG but what about everyone else?
>
> We are already splitting it, by putting signatures elsewhere. Just
> because you might think bearer tokens are the 'obvious choice' and
> signatures are the 'optional more advance choice', you are still
> splitting the protocol over multiple parts. It is just that your
> preferred way of splitting it is optimized to what you care most
> about. I have made the same argument about the readability of the
> specification without signatures in core and was shut down because
> it will delay the work too much and other reasons.
>

Yes I know and I realise there are conflicting opinions and you want a
compromise. I do not want to block that, hence my mild -1, but want to
raise these 2 points now before the split in case others feel they are
important points.

> > Also, as Torsten and I look at security considerations, I wonder
> if there are
> > some examples that link the threat model for acquiring a token and
using a
> > token.
>
> This is possible, but there is absolutely no benefit from the way
> the draft is structured today. If you strive to offer a complete and
> comprehensive solution and security review, you clearly have to
> include signatures in the same document. How would you discuss these
> examples and dependencies without the full picture? IOW, how is
> including bearer token but not other alternatives make answering
> these questions in the core specification any easier? Why is it any
> less useful to discuss these questions in each of the token
> authentication schemes? After all, it is the nature of the scheme
> that dictates everything else.
>
> This argument is valid but has nothing to do with moving section 5 out.
>

I think acquiring and using a token can be considered core as you always
need both. I don't have valid security consideration linkage between
acquiring and using the token to back up my assertion that it may confuse
developers if we separate them (yet)


> This leaves readability as the only potential argument against
> splitting. Why not try it out? What's the worse that will happen? We
> have to put it back in and look for a different compromise?
>
> And last, if you are going to opposed this proposal, then the burden
> is on you to offer an alternative that is going to address the
> concerns and parameters presented in my original post. By
> definition, a compromise means you don't get everything you want, so
> what are you willing to give up to help resolve these otherwise
> blocking issues? I am not trying to tease anyone, but asking an
> sincere question. Every other proposal has been rejected with
> sufficient resistance to suggest it will not last through the
> multiple review stages.
>

I am fine with breaking the spec if it means progress towards review stages

> EHL