[Ace] Review on draft-bormann-core-ace-aif-07
Jim Schaad <ietf@augustcellars.com> Mon, 25 May 2020 20:46 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 B0B363A05A0; Mon, 25 May 2020 13:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 JjjBU4zIcT5M; Mon, 25 May 2020 13:46:53 -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 C30B43A0484; Mon, 25 May 2020 13:46:49 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 May 2020 13:46:40 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-bormann-core-ace-aif@ietf.org
CC: 'Ace Wg' <ace@ietf.org>
Date: Mon, 25 May 2020 13:46:38 -0700
Message-ID: <031c01d632d5$98158ba0$c840a2e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdYySg6qaQ1K2nGySeOKYIC/kF1pfw==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2VX2gLdAzjPs9aSkZmP7ZBK3tsY>
Subject: [Ace] Review on draft-bormann-core-ace-aif-07
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: Mon, 25 May 2020 20:46:55 -0000
* Section 2 - I would like more clarification on the subject as being derived implicitly from the armor and is a single entity rather than multiple entities. If we think that we want to do multiple subjects then that needs to be discussed. * Section 2.1 - The model does not current deal with the question of queries and how they would be permitted for a non-query object. * How do we ant to look at doing the generalization for the structure provided. There are two things to look at: 1. The object identifier: It makes sense for a good many things for this to be an absolute-path. However for other things this would be some type of identifier. With both the GroupKDC and with MQTT this identifier is a string. In the MQTT case the string has defined wild card behavior. Part of the question is how much does the object naming scheme need to be identified to the client, the AS and the RS. 2. The permissible actions: For a coap addressed device, it makes sense for this to be based on the set of coap verbs and the compressed bit string makes a great deal of sense. However for both GroupKDC and MQTT these verbs are not the same and thus cannot be compressed in the same manner. What I would like to see is a structure defined that can be used in a number of situations, but which the details are going to be very object dependent. authorization-info = [ * authorization] authorization = [ object: object-identifier, permissions: [* permission-name] | uint .bits methods ] permission-name = tstr One option would be to allow the methods to be object dependent this means that you could have "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT case. The advantage of this is that it provides better compressions, but it also means that one needs to know what the enumeration is for each different type of object. I don't know if this means that one needs to start having a registry to deal with people adding verbs to a particular interface. I also don't know what it would mean if they were interface specific and an object supported two different interfaces. Nits: Section 2 - para 2 s/on object/an object/ Jim