[core] review of palombini-ace-key-groupcomm
Peter van der Stok <stokcons@bbhmail.nl> Mon, 30 July 2018 10:45 UTC
Return-Path: <stokcons@bbhmail.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3C413102A; Mon, 30 Jul 2018 03:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 tdGHrxpVc2Wb; Mon, 30 Jul 2018 03:45:27 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9726C130EEF; Mon, 30 Jul 2018 03:45:27 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id E6470100E86C1; Mon, 30 Jul 2018 10:45:25 +0000 (UTC)
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:2:41:72:152:355:379:582:800:871:920:960:962:967:968:973:983:988:989:1000:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1432:1436:1437:1516:1517:1518:1573:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2196:2198:2199:2200:2525:2553:2561:2564:2682:2685:2692:2737:2829:2859:2892:2897:2901:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3366:3586:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4419:4425:4511:4513:4557:4641:4659:4860:6117:6119:6261:6298:6353:6354:6506:6659:6747:6748:7281:7398:7464:7774:7875:7903:7904:7974:8526:8603:9015:9025:9177:9388:9912:10004:10376:10848:10945:11026:11232:11604:11657:11658:11914:12043:12114:12291:12295:12296:12438:12555:12663:12679:12683:12895:12986:13139:13144:13161:13181:13199:13200:13229:13230:13236:13439:13846:14096:14149:21060:21080:21324:21433:21451:21625:21691:21703:21740:3
X-HE-Tag: cap00_4c782bae7c704
X-Filterd-Recvd-Size: 60486
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 30 Jul 2018 10:45:25 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_f84ee3b034e6761fcf18e41dc87185bf"
Date: Mon, 30 Jul 2018 12:45:24 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Ace <ace-bounces@ietf.org>, Core <core@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl
Mail-Reply-To: consultancy@vanderstok.org, stokcons@bbhmail.nl
Message-ID: <23af2ffc9ec791bec0653d4a5baab467@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [5.206.216.229]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/94d5jiA-DupbK1qc-sUkhtVug2w>
Subject: [core] review of palombini-ace-key-groupcomm
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 10:45:32 -0000
Hi key-groupcomm authors, To start the review I have looked at the dependencies between the different involved drafts and came up with the figure below. The arrows indicate that a draft references another draft. The dots reference arrow means Informative reference. According to me, this means that the work on CORE can proceed independently of the work in ACE. The oscoap-join and key-groupcomm can proceed together to their conclusion without other dependencies. That guarantees that we can develop the group communication drafts in ACE without unwanted dependencies on pubsub. The pubsub-profile depends on core-pusub and key-groupcomm, which does not bother me too much. Keeping this in mind, I have reviewed the key-groupcomm draft. BTW, it might be helpful to include a similar overview in the oscoap-join draft. ________________________________________________________________ Abstract OLD:This document defines a message format for distributing keying material in group communication scenarios (such as based on multicast or publisher-subscriber model) using the ACE framework. NEW:This document defines a message format for distributing keying material to groups to protect the communication between group members using the ACE framework. Introduction OLD: Profiles that use group communication can build on this document to specify exactly which of the message parameters defined in this documents are used, and what are their values. NEW: Profiles that use group communication can build on this document to specify a selection of the message parameters defined in this document and their values. At the end of section 1: .... [RFC8152], like Authorization Server (AS) and Resource Server (RS). Figure 1 is not referenced in the text. I suggest a slightly different figure where dispatcher and KDC are endpoints of the RS, and for multicast the communication is directly between Client and group members without passing through the RS. Key Distribution Center (KDC): Maintains the keying material to protect group communications, and provides keys to clients authorized to join the group. It corresponds to an endpoint of the RS in the ACE Framework. Dispatcher: this is the entity the Client wants to securely communicate with and is responsible for distribution of group messages. Example dispatchers are the Broker in a pub-sub setting or the generator of unicast messages to all group members for group communication. Alternatively, Group communication is done by transmitting to a multicast IP address, and entrusting message delivery to the transport channels between Client and Group members. What is the difference between "adding node to group" and "distribution of keying material". I find the phrase difficult to understand. Figure 2 : I suggest to add Group Member (GM) as communication entity. At the end of section 2, I suggest some text on group identifier and role identifier, such that these terms can be used independent of the application profiles specified in other documents. Section 3. Remove: "where the RDC takes the role of RS". Suggest to add the message exchange before section 3.1 POST --- Authorization Request (application/CBOR) ----> <-- Authorization Response (???? ) ----- It would be nice if here the use of DTLS (or not) and the content format is specified: application/cbor or application/Cose+cbor section 3.1 scope: with as values the group identifier and optionally the role .... "The encoding of the group identifier and the role(s) is application specific." cnf: Optionally, the public key or the certificate of the client Question: is this a certificate identifier, or the public key extracted from the certificate, or a hash????? section 3.2: 0 access token containing all the parameters defined below; This is very confusing. I understood that access token parameter is at same level as cnf, rs_cnf, and exp. And here you write that they are contained in access token. If that is true, I suggest to make the other three parameter sub-bullets of access-token bullet. For topic and role see section 3.1 section 3.3: same request response figure as suggested in section 3 before section 3.1 "a different endpoint" is very vague. Please explain. section 4: /The same types of messages can also be/the same set of messages is/ just before section 4.1 same figure and information as requested in section 3 before section 3.1 section 4.1 "....request to the endpoint in the KDC associated..." Not clear what is meant: - one endpoint for all groups? - one endpoint per group? - one endpoint per subset of groups? scope: remove topic; what resource is referred to? get_pub_keys: Instead of empty CBOR array, an empty payload is also possible? client_cred: same question on certificate as for section 3.1 below figure 3 /additionally/Optionally/ The parameters group_policies and mgt_key_material are not specified in pubsub-profile draft. Do you ever use them? Section 5.2 "NOte that .... leaving node" It is not clear if the client has left the group in this case, and what that means. The actions look quite contradictory to me. section 6 /not able to participate to/not able to receive or decrypt/ section 6.1 scope: same remarks about topic and group identifier. "In some cases ... same KDC". Suggest to remove. In a fast changing environment, this may lead to many error messages if not wrong behavior; Imagine group GA is the only group. C is member of GA. GA is removed and GB is entered as the only group. C wants to leave/join GA, and accesses GB. Section 7 Again suggest to add figure with request before section 7.1 scope: same comment on group identifier and topic. _____________________________________________________ Hope this helps, greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org
- [core] review of palombini-ace-key-groupcomm Peter van der Stok