Re: [Ace] discussion on draft-vasu-ace-core-access-privilege-provisioning-00

Ludwig Seitz <ludwig@sics.se> Fri, 22 April 2016 08:58 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 4D60C12E35E for <ace@ietfa.amsl.com>; Fri, 22 Apr 2016 01:58:20 -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 CXdDqWMm3np8 for <ace@ietfa.amsl.com>; Fri, 22 Apr 2016 01:58:18 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 DA87312DFCC for <ace@ietf.org>; Fri, 22 Apr 2016 01:58:17 -0700 (PDT)
Received: by mail-lb0-x229.google.com with SMTP id os9so40393095lbb.2 for <ace@ietf.org>; Fri, 22 Apr 2016 01:58:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to; bh=x7lkBWHHBl9YsipOf4ef3LS1ZArAW0TmCIY6sgiLBc4=; b=Nk3PVJqMDHHzXpHdP9VYMgwoY5cGqD9IzOoGGDQw0WyD2VB3PIZLl3A18eRMEfyuCK oK5q0bv7GPtZdoLhfz7aq+wIjb6dhXA/2A/IZrkr1MHK9euvoNSFWFfEZsWNKu1UATvE F711FToM039kxiSkecUofjnMGPqePr2Bxbk0YJrYNZrFzh+KeYNRsFcH8tulbtzZSdzO TYU6ONZ9qgiIF0CrpA7dg5cFSoBi7hIN0+x9jCz4oYfrj+wZnIpkLF/ym0Z0PQhJUHkm UcrHsgquV98e1CMlZ3SITEIpG0Kfee3eg5XVoVSJYAmactzlEhazzmCJwoG2GBQ+oT6p BicA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to; bh=x7lkBWHHBl9YsipOf4ef3LS1ZArAW0TmCIY6sgiLBc4=; b=dfXV4HETDVSsStnBr5BeA0sXFE7lzblCyuGBxlscgJxM9lFZvWXV1zkQnkJlxKes1t 1K2ROGJlLcIk45X+AO2q7kWmgzm+V8p4Dxm6cdG6MXk4iC/OKtSc4RFVu9w0wC+Fg+cw 5uYgQ53irUc8nzbcYKmr71IDparE70P46nE9OzWXwUmoBFHmH9nVC1dx6PycYQLlKvmb qr4dZwjDEn+Nl1UXybWNSo3S8PdsgbPWcv9Q/xkQfFErU0VdYdBU6JC1s8/xFajONkW5 wdTjmEAFvauXDNtxb6VB/MFhSKLRcEeNVy59P4MuZBT8qxPzbZsJaR2MHN38JDmwoW+w GELw==
X-Gm-Message-State: AOPr4FWW5bgOcwJjTlaw8pYRk/jEb6KVyg1AJqZWWiHmXMhrIZQkhLQQi/OrttwDeZQGsqQ+
X-Received: by 10.112.154.5 with SMTP id vk5mr2305015lbb.126.1461315496075; Fri, 22 Apr 2016 01:58:16 -0700 (PDT)
Received: from [192.168.0.166] ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id ug7sm1359859lbb.9.2016.04.22.01.58.14 for <ace@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 01:58:15 -0700 (PDT)
From: Ludwig Seitz <ludwig@sics.se>
To: ace@ietf.org
References: <mailman.1679.1461237949.4402.ace@ietf.org> <D6EBB546995C064A9492E8E27F62D90D0AA2C958@blreml509-mbb.china.huawei.com>
Message-ID: <5719E7A6.3@sics.se>
Date: Fri, 22 Apr 2016 10:58:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <D6EBB546995C064A9492E8E27F62D90D0AA2C958@blreml509-mbb.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030600020601090402040700"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ace/buWQmqvWsHvF_Y6lfSk04tIkCNc>
Subject: Re: [Ace] discussion on draft-vasu-ace-core-access-privilege-provisioning-00
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: Fri, 22 Apr 2016 08:58:20 -0000

Hello,

I'm still trying to clarify the details of the approach you propose,
so please excuse the barrage of questions.

In figure 2 it looks like the RS has to do an online lookup at the AS to
get an access control decision while in figure 3 it seems as if the AS
itself executes the request on behalf of the client.

Both cases work fine if the RS can connect to the AS at the time of the
request, but if you look at RFC 7744 we have usecases where this is not
possible or not cost effective (e.g. in terms of battery usage). Have 
you considered such usecases?

 From our discussion I got the impression that in your approach, both
access control and resource control policies are provisioned to the AS
only and not to the RS, but in figure 3 is seems like the RS makes some
access control decision towards the AS, I wonder based on which policies
that happens?

> Why would the scheduling problem be caused by the access control
> mechanism? That causality doesn't seem obvious to me, please explain
> in more detail.
> --> Here, If I am not wrong, you mentioned that same access tokens
> can be valid for multiple resources.

Right

> If access control does not consider resource availability and
> resources max capacity to handle the request. Then clients need to
> send the resource request to multiple resource servers. Then it may
> need a scheduling by a proxy.

As I said, the AS can very well consider resource control or scheduling 
when making an access control decision, but the details of how the AS 
makes access control decisions are not in scope for ACE.

I also get the feeling that you got hang up on my simplistic example of 
a client sending a request to multiple resource servers. I guess a more 
realistic example would be that there are proxies taking care of 
scheduling, independently of the access control mechanism in place. 
Alternatively you could imagine a setting where the client broadcasts or 
multicasts its request.

>
> It seems to me that your goal is to include resource control aspects
> into that decision, and that is fine by me, but not relevant for the
> ACE work, which deals with encoding the access control decision into
> a token, getting the token to the Resource Server and then having the
> RS enforce that access control decision. --> Can you suggest me,
> which group I can reach for?

I don't think there is an IETF working group on that topic.




> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ace digest..."

Please note this ^^^^^^



/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