Re: [Ace] Context-based Authorization

Ludwig Seitz <ludwig@sics.se> Tue, 15 July 2014 06:10 UTC

Return-Path: <ludwig@sics.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A831B2816 for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 23:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 x-VDis46Xw4a for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 23:10:37 -0700 (PDT)
Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id C1DB11B2812 for <ace@ietf.org>; Mon, 14 Jul 2014 23:10:36 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 1F12F6EA for <ace@ietf.org>; Tue, 15 Jul 2014 08:10:36 +0200 (CEST)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6F6AZoE016885 for <ace@ietf.org>; Tue, 15 Jul 2014 08:10:35 +0200
Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D1BA740116 for <ace@ietf.org>; Tue, 15 Jul 2014 08:10:31 +0200 (CEST)
Message-ID: <53C4C5D6.30503@sics.se>
Date: Tue, 15 Jul 2014 08:10:30 +0200
From: Ludwig Seitz <ludwig@sics.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ace@ietf.org
References: <34966E97BE8AD64EAE9D3D6E4DEE36F258177EE3@SZXEMA501-MBS.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258177EE3@SZXEMA501-MBS.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010604090308000203080609"
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN)
X-p0f-Info: os=Solaris 10, link=Ethernet or modem
X-CanIt-Geo: ip=85.235.11.178; country=SE; region=Skåne; city=Lund; latitude=55.7000; longitude=13.1833; http://maps.google.com/maps?q=55.7000,13.1833&z=6
X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default)
X-Canit-Stats-ID: 09MquazLk - d0d094420a33 - 20140715
X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MquazLk&m=d0d094420a33&t=20140715&c=f
X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MquazLk&m=d0d094420a33&t=20140715&c=n
X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MquazLk&m=d0d094420a33&t=20140715&c=s
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Vgser9D1nma1R2FaM2KmLbJuQCM
Subject: Re: [Ace] Context-based Authorization
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 15 Jul 2014 06:10:39 -0000

On 07/15/2014 05:19 AM, Likepeng wrote:
> Hi all,
>
> Personally I am wondering whether or not we should support context-based
> authorization indicated in
> http://tools.ietf.org/html/draft-seitz-ace-usecases-01.
>
> For U2.4, do we want to achieve something like this: if time is 9:00 ~
> 18:00, Client A is allowed to turn on a light, but Client B is not allowed?

Yes that's one example.

>
> To me, this is purely Resource Server side policy setting and
> enforcement. Does it require any information exchange with Authorization
> Server? Is it necessary?

We are moving away from requirements here and getting into solutions, 
but for the sake of clarification: I don't think this kind of policy 
should be on the RS, it should be maintained and managed by the AS, for 
the same reasons we want all the other authorization policies to be on 
the AS. The solution I have in mind are conditional authorization 
decisions in the style: "You are permitted to turn on the light, 
provided it is between 9:00 and 18:00".


> About presence, does it mean online / offline status? If yes, this
> should be covered by another requirement U5.2, which was discussed in
> another discussion thread “offline operation”.
>

No I meant physical presence, like "you get to control the HVAC if you 
are in the room, but from elsewhere"

>
> For U3.1, how to define an emergency context?

In medical access control scenarios there is the concept of 
"break-the-glass policies". This means that medical personnel can just 
declare an emergency context (similar to breaking the glass to access a 
fire alarm, see attached image) in order to get additional 
authorization. This declaration is then subject to auditing at a later 
point, to ensure that there really was an emergency situation.



/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