Hi Sandeep, While it is possible to merge the drafts, OSCOAP is already a long draft and we preferred to separate the general secure group communication into a separate text, which may be applied in other contexts beside the "low latency" setting.
Göran > On 12 okt. 2016, at 14:17, Kumar SS, Sandeep <[email protected]> > wrote: > > I agree with Hannes. The changes need to OSCOAP was quite straightforward and > clear from the beginning, we were waiting for OSCOAP to be stable. The minor > changes could have been directly taken into OSCOAP with an optional SenderID > field. If that is not possible, then it can be done directly in the ACE > draft. I do not see any value in an additional draft to solve this minor > sub-issue. > > Sandeep > >> -----Original Message----- >> From: Ace [mailto:[email protected]] On Behalf Of Hannes Tschofenig >> Sent: Wednesday, October 12, 2016 1:51 PM >> To: Göran Selander <[email protected]>; Marco Tiloca >> <[email protected]>; [email protected] >> Subject: Re: [Ace] [core] Fwd: New Version Notification for >> draft-tiloca-core- >> multicast-oscoap-00.txt >> >> Hi Goeran, >> >> there was never any doubt that we can use COSE to design a security >> solution using the already existing building blocks. >> >> Btw, in the meanwhile we have actually concluded the discussion in ACE on >> the group communication security topic, see https://www.ietf.org/mail- >> archive/web/ace/current/msg01967.html >> >> Ciao >> Hannes >> >> PS: You cannot decouple the question of adoption of >> draft-somaraju-ace-multicast-01 from the question of source authentication >> since this was the core issue of the debate. >> >>> On 10/12/2016 01:31 PM, Göran Selander wrote: >>> >>> Hi Hannes, >>> >>> I’m a bit surprised at your reaction. If you have followed the >>> discussion on OSCOAP you know that one recurring request has been on >>> support for multicast. This draft is addressing that request. >>> >>> draft-somaraju-ace-multicast-01 is referring to OSCOAP for secure >>> group communication and we propose this draft to be the way to extend >>> OSCOAP for that purpose. >>> >>> In the "controversial, long, and tough” discussion you refer to, one >>> central issue relates to the use of symmetric keys only in group >>> communication. Our draft mandates the use of asymmetric keys since >>> that provides source authentication. Should it be agreed that source >>> authentication for some purpose is not necessary, it is a simple >>> modification of this draft - simply making the counter signature in >>> the COSE object non-mandatory. >>> >>> It was our hope that we in this way can decouple the question of >>> adoption of draft-somaraju-ace-multicast-01 from the question of >>> source authentication. >>> >>> Göran >>> >>> >>> >>> >>> On 2016-10-12 10:40, "Ace on behalf of Hannes Tschofenig" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>> Hi Marco, Hi Francesca, Hi Goeran, >>>> >>>> I am a bit surprised about your document submission since you guys >>>> have been pretty silent in the group communication security >>>> discussion, which was quite controversial, long, and tough. That's >>>> where your support would have been needed. Adding the few small bits >>>> to the already written draft isn't the problem. >>>> >>>> Ciao >>>> Hannes >>>> >>>>> On 10/12/2016 10:12 AM, Marco Tiloca wrote: >>>>> Dear CoRE/ACE, >>>>> >>>>> We have submitted a draft on secure group communication for CoAP >>>>> addressing security for the setting of a multicast CoAP request with >>>>> unicast responses as described in RFC7390. >>>>> >>>>> This draft builds on the recently updated version of OSCOAP, >>>>> extended with mandatory Sender ID and multiple Recipient Contexts. >>>>> It also enables source authentication with asymmetric signatures >>>>> implemented as counter signatures included with the COSE objects >> defined by OSCOAP. >>>>> >>>>> We hope that by submitting now we could get some first discussion to >>>>> allow updates before the cutoff. >>>>> >>>>> This draft provides the missing link between >>>>> https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP. >>>>> >>>>> Best regards, >>>>> Marco >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: ** <[email protected] >>>>> <mailto:[email protected]>> >>>>> Date: Wed, Oct 12, 2016 at 9:27 AM >>>>> Subject: New Version Notification for >>>>> draft-tiloca-core-multicast-oscoap-00.txt >>>>> To: Marco Tiloca <[email protected] <mailto:[email protected]>>, Goeran >>>>> Selander <[email protected] >>>>> <mailto:[email protected]>>, >>>>> Francesca Palombini <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> >>>>> >>>>> A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt >>>>> has been successfully submitted by Francesca Palombini and posted to >>>>> the IETF repository. >>>>> >>>>> Name: draft-tiloca-core-multicast-oscoap >>>>> Revision: 00 >>>>> Title: Secure group communication for CoAP >>>>> Document date: 2016-10-12 >>>>> Group: Individual Submission >>>>> Pages: 15 >>>>> URL: >>>>> >>>>> https://www.ietf.org/internet-drafts/draft-tiloca-core-multicast-osc >>>>> oap-0 >>>>> 0.txt >>>>> >>>>> <https://www.ietf.org/internet-drafts/draft-tiloca-core-multicast-os >>>>> coap- >>>>> 00.txt> >>>>> Status: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-tiloca-core-multicast-oscoap/ >>>>> <https://datatracker.ietf.org/doc/draft-tiloca-core-multicast-oscoap/> >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00 >>>>> <https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00> >>>>> >>>>> >>>>> Abstract: >>>>> This document describes a method for application layer protection of >>>>> messages exchanged with the Constrained Application Protocol (CoAP) >>>>> in a group communication context. The proposed approach relies on >>>>> Object Security of CoAP (OSCOAP) and the CBOR Object Signing and >>>>> Encryption (COSE) format. All security requirements fulfilled by >>>>> OSCOAP are maintained for multicast CoAP request messages and >> related >>>>> unicast CoAP response messages. Source authentication of all >>>>> messages exchanged within the group is ensured, by means of digital >>>>> signatures produced through asymmetric private keys of sender >> devices >>>>> and embedded in the protected CoAP messages. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org <http://tools.ietf.org>. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> Ace mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ace > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
