Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Ludwig Seitz <ludwig@sics.se> Thu, 21 July 2016 14:39 UTC

Return-Path: <ludwig@sics.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 2E45812D67D for <ace@ietfa.amsl.com>; Thu, 21 Jul 2016 07:39:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com
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 hIC4hXn8gxPq for <ace@ietfa.amsl.com>; Thu, 21 Jul 2016 07:39:18 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B931412D684 for <ace@ietf.org>; Thu, 21 Jul 2016 07:39:08 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id o80so28023820wme.1 for <ace@ietf.org>; Thu, 21 Jul 2016 07:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=jQJ+VJNIowBFQyX2kqMfzlxfZ620tdoZvtCzGlPymag=; b=T+vvpPifPyCrSlGp8ua8q2Gv6TISm6pHZUioeZ7u6qI11Fmci29CoUAlo6SC3wWHrc 8ygcwiGEHuXWxF9eitk6l49CGAqhcmYqWJiIar31os2Jc1lDBEAaY5XkG28ElaEP7Wwl fUjuROUn4sOFDPAMCoaXjJMedPkp7XLo64oiksJSvaVXzavPF7+MSxqQyKTGZihhmA0q 6qexSty7El3mc/YPQ4uVDpE+i8YO/AdIx7UzaCnwz7BotQJWtlTthZ0D4FgoLStLF+sO gyhJWPnz1hI8kuxIwbc/kvkDAr7fsrrmLT1QpTzXg6JpQC3msJiM6tQwF7acaych3R8F akbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=jQJ+VJNIowBFQyX2kqMfzlxfZ620tdoZvtCzGlPymag=; b=CG1e+q7on7ABXUbsCx59K2W9/f6p9OmuqUAwuxbbnlpzFQG0FdGfXkYMHWdsIZ0kWp IM7+JleuNk2HY+th+ARTS8WHfC857matWkH3qksJ4+ZLDmanZi1OUSJA/jhWVcIVSQqw 9hFbp1//6FHioNZeSi2jNkCloFNWrqG9WA+jHvQ/6DsRWyEcjURKnKdqVbeEudtJtk9x UgoIZ/WKXs9pifLdJ9Lchptqt7rbk7br6mRLkK8mdrqB0gCY7JceVOSG+te9dcNpCdN/ 1if1BAgmkHl/eAyz2T4892UJrnbGPmgfXdW8x7+6UTMjUNjqyBDa4SR9FliyEGLs3ds6 iHRw==
X-Gm-Message-State: ALyK8tLq+e37Lb2YuHq17tI5Z85FVxSdZB0xEBiUmKaDSYo2mmjr7uVTj/YRkV1DurhdC+Lk
X-Received: by 10.28.20.77 with SMTP id 74mr19556927wmu.1.1469111946610; Thu, 21 Jul 2016 07:39:06 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:4d2a:de06:a61e:cc49? ([2001:67c:370:160:4d2a:de06:a61e:cc49]) by smtp.gmail.com with ESMTPSA id f187sm4574678wmf.15.2016.07.21.07.39.05 for <ace@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 07:39:05 -0700 (PDT)
To: ace@ietf.org
References: <578F4D59.8050005@gmx.net> <5E393DF26B791A428E5F003BB6C5342AB3716D64@OC11EXPO33.exchange.mit.edu> <23666.1469091857@obiwan.sandelman.ca> <95b0103c-ba2d-6cd8-6241-228df46e530b@sics.se> <8ca27108-a8b9-7b07-e752-656247716708@comcast.net>
From: Ludwig Seitz <ludwig@sics.se>
Message-ID: <71465ddb-04dd-072a-da07-1646a7add8dc@sics.se>
Date: Thu, 21 Jul 2016 16:39:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <8ca27108-a8b9-7b07-e752-656247716708@comcast.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020301050101040509010407"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/hxjiG0xx8QqkU3duuX5-hteOQj8>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Jul 2016 14:39:23 -0000

On 2016-07-21 14:49, Michael StJohns wrote:
> On 7/21/2016 5:29 AM, Ludwig Seitz wrote:
>> On 2016-07-21 11:04, Michael Richardson wrote:
>>>
>>> Why will ACE succeed when DICE failed?
>>> Does ACE now have some knowledge or mechanism that DICE couldn't have
>>> created
>>> because it was out of scope?
>>>
>>
>> ACE is (also) about authorization, which DICE wasn't. A compromised
>> lightbulb might well have the possibility to talk to a door lock
>> (using it's group key), but it would lack the authorization to do
>> anything with the lock.
>>
>> IMHO that's what ACE add that DICE didn't have (and wasn't chartered
>> to have).
>
> Hi Ludwig -
>
> Sorry - you are incorrect.
>
> The group key is also the authorization key in the model proposed. Any
> entity that holds that key can forge a message that can cause the action
> authorized by the issuance of that key. In your example, assuming that
> the door lock and the lightbulb share the same group key, then
> compromising the lightbulb allows you to control the door lock.
>

That is certainly not the model I had in mind. Why on earth would a sane 
Authorization Server issue OAuth access tokens that authorize operations 
on the door-locks and that are bound to the lightbulb-group key?

The way I see this play out is this: In the low latency cases, with low 
security requirements (such as turning on lights, or operating blinds) 
you can use the group key for authorization, but this authorization 
would be clearly scoped to the lights or blinds.
Resources with higher security requirements (such as door-locks) 
shouldn't be on the same multicast-group to start with, but even if they 
were, they SHOULD NOT be configured to accept actuator commands 
authorized by access tokens bound to a multicast group key.

Would that address your concerns?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se