IETF Logo Mail Archive

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

Ludwig Seitz <ludwig.seitz@ri.se> Wed, 24 October 2018 09:02 UTC

Return-Path: <ludwig.seitz@ri.se>
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 770BE130F75; Wed, 24 Oct 2018 02:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OUpJKKYUb7tj; Wed, 24 Oct 2018 02:02:31 -0700 (PDT)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE955130F3E; Wed, 24 Oct 2018 02:02:30 -0700 (PDT)
Received: from 1gFF3c-000Qww-U6 by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gFF3c-000Qyb-VS; Wed, 24 Oct 2018 02:02:28 -0700
Received: by emcmailer; Wed, 24 Oct 2018 02:02:28 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gFF3c-000Qww-U6; Wed, 24 Oct 2018 02:02:28 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 11:02:28 +0200
To: Jim Schaad <ietf@augustcellars.com>, 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>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <0e01455c-4337-c51a-c199-fd5b56cf717d@ri.se>
Date: Wed, 24 Oct 2018 11:02:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <038001d46b00$767a8520$636f8f60$@augustcellars.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/DC01jPLwcpYIhn887-WZm_MLlFo>
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 09:02:41 -0000

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.

/Ludwig



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

v2.23.0 | Report a Bug | By Email