Re: [Ace] Review of draft-ietf-ace-oauth-params-00

Jim Schaad <ietf@augustcellars.com> Thu, 25 October 2018 20:51 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0031276D0 for <ace@ietfa.amsl.com>; Thu, 25 Oct 2018 13:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kecQJbSCChNm for <ace@ietfa.amsl.com>; Thu, 25 Oct 2018 13:51:35 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF51124C04 for <ace@ietf.org>; Thu, 25 Oct 2018 13:51:34 -0700 (PDT)
Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 13:46:42 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, <ace@ietf.org>
References: <VI1PR0801MB2112DD9ECD09B98C5060D868FAF50@VI1PR0801MB2112.eurprd08.prod.outlook.com> <c55b3179-ad19-0dbf-c183-3723ff2dade6@ri.se>
In-Reply-To: <c55b3179-ad19-0dbf-c183-3723ff2dade6@ri.se>
Date: Thu, 25 Oct 2018 13:51:21 -0700
Message-ID: <018301d46ca4$7e091db0$7a1b5910$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ8qlZiinhkNDNE8EN7qIRibxZqnwJPovo6o81xeLA=
Content-Language: en-us
X-Originating-IP: [50.252.25.182]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/xQiABOT_IVE24_NbpTi3XrGMe1Y>
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 20:51:37 -0000


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org>; On Behalf Of Ludwig Seitz
> Sent: Wednesday, October 24, 2018 1:00 AM
> To: ace@ietf.org
> Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00
> 
> On 23/10/2018 21:09, Hannes Tschofenig wrote:
> 
> > 2) 'req_aud' parameter
> >
> > At the last IETF OAuth meeting in Montreal we agreed to adopt a new
> > document, called resource indicators, and it can be found here:
> >
> > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01
> >
> > I believe the parameter name and semantics defined in
> > draft-ietf-oauth-resource-indicators-01 should match what is defined
> > in draft-ietf-ace-oauth-params-00.
> >
> > The name of the parameter in draft-ietf-oauth-resource-indicators-01
> > is 'resource' and it is defined as
> >
> >     resource
> >
> >        Indicates the location of the target service or resource where
> >
> >        access is being requested.  Its value MUST be an absolute URI,
> > as
> >
> >        specified by Section 4.3 of [RFC3986], which MAY include a
> > query
> >
> >        component but MUST NOT include a fragment component.  Multiple
> >
> >        "resource" parameters MAY be used to indicate that the
> > requested
> >
> >        token is intended to be used at multiple resources.
> >
> >
> 
> 
> Looking closer at this draft:
> 
> The resource parameter seems to be much more limited than the audience
> claim, since a URI is required. As Steffi recently remarked in her review
of
> draft-ietf-oauth-authz, URIs are not a good way to identify resources in
> constrained environments, since the address of a device can change.

I rather have to agree that these do not seem to be doing the same thing.
The 'resource' parameter looks like it could actually be used in parallel
with the 'aud' parameter if you want to refer to a specific RS which is
hosting the audience in question.  But that would be some form of narrowing
of scope.

> 
> Furthermore there seems also to be an overlap with the 'scope'
> parameter, since the 'resource' parameter can be used to indicate specific
> resources and not only the target RS.
> 
> What if we want to identify the audience by its public key instead of an
URI?

Ludwig, this is not actually a problem since there is a URI for doing that.

> 
> What if a client wants to request a token for a group of RS identified by
a
> specific audience value (e.g. "thermostats-building-1")?

One of the things that I kept hearing is that an audience may be hosted by
multiple resource servers as long as I have been going to ACE meetings.
This does not seem to be a problem with the OAuth in HTTP right now as a CDN
would hide that level of detail.  

Jim

> 
> 
> /Ludwig
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace