IETF Logo Mail Archive

Re: [Ace] WGLC for draft-ietf-ace-authz

Jim Schaad <ietf@augustcellars.com> Wed, 24 October 2018 18:20 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 89F8B12777C; Wed, 24 Oct 2018 11:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 hu4X0nFNNAZv; Wed, 24 Oct 2018 11:20:33 -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 25AE4124C04; Wed, 24 Oct 2018 11:20:32 -0700 (PDT)
Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 24 Oct 2018 11:15:21 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, draft-ietf-ace-oauth-authz@ietf.org
CC: ace@ietf.org
References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <028d01d46a3a$bc6414f0$352c3ed0$@augustcellars.com> <e430cb24-1ac8-5eaf-2513-399c345fc999@ri.se> <038001d46b00$767a8520$636f8f60$@augustcellars.com> <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se>
In-Reply-To: <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se>
Date: Wed, 24 Oct 2018 11:20:01 -0700
Message-ID: <00b001d46bc6$2f9fde90$8edf9bb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAJjpp42AY2H+FoCbDZgzwL8GF23o49PCGA=
Content-Language: en-us
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/eryxsWVbAqc9DYGra8B8l6PoVVs>
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
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: Wed, 24 Oct 2018 18:20:36 -0000


> -----Original Message-----
> From: Ludwig Seitz <ludwig.seitz@ri.se>
> Sent: Wednesday, October 24, 2018 2:02 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-oauth-
> authz@ietf.org
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
> 
> On 23/10/2018 20:44, Jim Schaad wrote:
> >
> 
> >
> >
> >>> * Section 6 - I am not sure that I agree with the SHOULD NOT in the
> >>> last paragraph.  Think multicast.
> >> Any suggestions on how to mitigate the issue then? If I issue a token
> >> bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got
> >> this token it can impersonate the client and gain access to R2 and
> >> R3.
> >
> > I am not sure that I think this is an issue that needs to be
> > mitigated.  It needs to be acknowledged, but the assumption would be
> > that if you have three resource servers that are hosting the same
> > audience they are going to be run by the same RO and already be
> > coupled.  After all it should not matter which of them you do a GET
> > from, you should get the same answer.  Similarly a PUT to one should
> > propagate to the others so that it is available to all clients.
> >
> 
> 
> Say the client is a cleaning service and the audience is the locks of the
> different apartments it is allowed to open.
> 
> If the token uses symmetric keys, as soon as the cleaning service sends the
> token to one apartment, this apartment can open the other apartments. This
> is the situation I want to avoid.

I would not expect that the locks would all be a single audience.  You might have all of the locks in a single apartment be one audience but you would want to separate the apartments into different security groups.  The cleaning service should be required to obtain a token specific to an apartment and not generally for all apartments.

If you have a situation where a single audience encompasses multiple security objects that are to be controlled differently then you run across the problem that Stefanie was raising where you cannot know which RS to make the token for because you are now needing to map audience, scope and actions all to a different RS which seems to be defeating the purpose of having an audience. 

Jim

> 
> /Ludwig
> 
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51

v2.23.0 | Report a Bug | By Email