Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining
Marco Tiloca <marco.tiloca@ri.se> Fri, 20 October 2017 14:13 UTC
Return-Path: <marco.tiloca@ri.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 7AD5113339A; Fri, 20 Oct 2017 07:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 3NJyf2gC_639; Fri, 20 Oct 2017 07:13:23 -0700 (PDT)
Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79E713337F; Fri, 20 Oct 2017 07:13:19 -0700 (PDT)
Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id 666F22047B8; Fri, 20 Oct 2017 14:13:14 +0000 (UTC)
Received: from [193.10.66.141] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 20 Oct 2017 16:13:15 +0200
Message-ID: <59EA0476.5090403@ri.se>
Date: Fri, 20 Oct 2017 16:13:10 +0200
From: Marco Tiloca <marco.tiloca@ri.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Francesca Palombini <francesca.palombini@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, "draft-tiloca-ace-oscoap-joining@ietf.org" <draft-tiloca-ace-oscoap-joining@ietf.org>, "draft-palombini-ace-coap-pubsub-profile@ietf.org" <draft-palombini-ace-coap-pubsub-profile@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
References: <00d401d34966$1c9d0260$55d70720$@augustcellars.com> <HE1PR07MB15299B23E446FE9EAE7661D798430@HE1PR07MB1529.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB15299B23E446FE9EAE7661D798430@HE1PR07MB1529.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="0Ie36sKsVFxe1MphW7q5VNm5vmhSU2lc2"
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=02M-m0pO-4AA:10 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=XkYX7XBwUzrsRoDfeSgA:9 a=EkawJCAG25wRoCjN:21 a=uaerPYD_IUvpGIZr:21 a=pILNOxqGKmIA:10 a=_-38nKkDacA3SF9XkmQA:9 a=ONNS8QRKHyMA:10 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22
X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity
X-Virus-Status: Clean
X-MailSecurity-Status: 0
X-Scanned-By: WeCloud MailSecurity
X-MailSecurity-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/KA4SXTG7ckmQl3LUX-K2Xdhv0AQ>
Subject: Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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, 20 Oct 2017 14:13:38 -0000
Hi Jim, I support Francesca's thoughts on this. Please, find inline a few more comments. Ciao, /Marco On 2017-10-20 15:20, Francesca Palombini wrote: > Hi Jim, > > I don't think that your statement is correct: as far as I understood the oscoap-joining document, the RS is the group manager, while in the pubsub document (even generalizing it and making a group communication profile as Carsten was suggesting) the entity that does group management is the AS2. > > I consider these differences a reason to have separate documents, yes, they could be described in the same draft, but I don't see how that simplifies the specifications. > > One more comment inline. > > Thanks, > Francesca > >> -----Original Message----- >> From: Jim Schaad [mailto:ietf@augustcellars.com] >> Sent: den 20 oktober 2017 07:42 >> To: draft-tiloca-ace-oscoap-joining@ietf.org; draft-palombini-ace-coap- >> pubsub-profile@ietf.org >> Cc: ace@ietf.org >> Subject: Comments on draft-tiloca-ace-oscoap-joining >> >> After the interim meeting, I read this document through in order to produce >> a review. Instead you are going to get a meta-review. >> >> I am having a hard to seeing why this document exists in its current form and >> it is not some type of simple profile of the pub-sub security draft. >> While I am not sure that this document is a sub-set of that document, it >> appears to be about 90-99% a sub set of that document. Consider the >> following: >> >> You have both the publisher and subscriber roles as in the pub-sub draft. >> >> You have an entity which is doing key distribution in the system. For the pub- >> sub draft this is AS2 for you it is the RS, but they are performing the exact >> same set of tasks. >> > Yes, they are performing the same set of tasks on a high level, but they are using the ACE framework differently in practice. For example the publisher and subscriber acquire the keys without using the token. > >> The pub-sub draft as and endpoint which holds the encrypted messages, in >> its place you are using the multi-cast UDP channel. In both cases they are >> basically unprotected-untrusted entities to distribute the content message. >> The only difference is that in the pub-sub model the RS will also provide >> restricted access to publishing which is not enforceable here. >> >> Both of these documents are missing what I would consider to be core >> pieces. >> The pub-sub document does initial key distribution, while this document >> does not. Neither document does any discussion of how subsequent key >> distribution is done to deal with forward and backward security of messages. As to the "initial key distribution", I guess you refer to the group keying material that the Group Manager provides to the joining endpoint. From a previous discussion we had on this in Prague, I thought you were suggesting to specify the actual group OSCOAP key material provisioning on the group OSCOAP draft, rather than in this document. Of course, one of them has to describe such key provisioning. As to the "subsequent key distribution", we were trying to keep the definition of the specific group key revocation/renewal scheme enforced by the Group Manager out of the scope of both the group OSCOAP draft and this joining document. On the other hand, both documents acknowledge the importance of such service and discuss it in the "Security considerations" section. Such considerations cover both backward and forward security in the group OSCOAP draft, while only backward security on this document as related solely to the join process. >> >> This document probably needs to define a new relationship, which might be >> more generally used, to say - this URL is where you get the security >> information for this URL which is published in the directory - esp in the case >> of multi-cast address URLs in the resource directory. You might also find that >> the correct answer is not to use a separate resource for each channel, but to >> allow for the use of URI path elements to define the security for a resource. Thanks, we will think more on this. >> >> Jim >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB.
- [Ace] Comments on draft-tiloca-ace-oscoap-joining Jim Schaad
- Re: [Ace] Comments on draft-tiloca-ace-oscoap-joi… Carsten Bormann
- Re: [Ace] Comments on draft-tiloca-ace-oscoap-joi… Francesca Palombini
- Re: [Ace] Comments on draft-tiloca-ace-oscoap-joi… Marco Tiloca
- Re: [Ace] Comments on draft-tiloca-ace-oscoap-joi… Jim Schaad