Subject: [Ace] Comments on draft-tiloca-ace-oscoap-joining

From: Jim Schaad <[email-masked]>
Date: Thu, 19 Oct 2017 22:41:40 -0700

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.

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.

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.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Oct 2017 07:48:26 +0200

> distribution is done to deal with forward and backward security of messages.

By being more explicit that the “pubsub” profile really is a group communication profile, it would be easier to remember that we have to solve all the usual problems in securing group communication, including group membership maintenance.

Grüße, Carsten

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 20 Oct 2017 13:20:35 +0000

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:[email-masked]]
> Sent: den 20 oktober 2017 07:42
> To: [email-masked]; draft-palombini-ace-coap-
> [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-tiloca-ace-oscoap-joining
> 
> 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.
> 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
> The pub-sub document does initial key distribution, while this document
> does not.  Neither document does any discussion of how subsequent key
> 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.
> 
> Jim
>

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 20 Oct 2017 16:13:10 +0200

Hi Jim,

I support Francesca's thoughts on this. Please, find inline a few more
comments.

Ciao,
/Marco

>> 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.

>> 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
> [email-masked]
> 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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 20 Oct 2017 09:51:22 -0700

Francesca,

My first concern is that the messages being send around to do the group
communication setup should be, if not identical, highly coordinated in how
they are formatted.   I don't really want two different sets of messages.

I understand, and indeed noted, that the current model of how they are using
the authentication structure is different.  However, I believe that I could
easily map things so that the structures are going to be the same.  Consider
the following change of the join picture.

Kill the current AS entity from the system as not providing new
functionality.
Rename the current RS entity to be AS2 mapping to the same current
functionality as is provided in the pub-sub draft.
Create a new collective RS entity which consists of all of the entities
(other than me) which are listening to the multicast address.

If you do that then the picture of the multicast and pub-sub systems have a
great deal in common.  The one thing that gets lost is the ability to ask
the current RS where the AS lives, but this is the type of information that
Ludwig is saying should be able to be placed in the resource directory (see
the oauth-authz document).  This is where the question of what the resource
types and relationships between different elements in the RD would come into
focus.  It would also be possible that AS2 in the new module would just have
a directory of multicast items which it supports.

The pub-sub discovery of resources is currently designed to be done via the
resource directory, so there is no reason that the multicast ones should not
as well.

I think that this means that the structure between the two documents is far
closer to the same that either of you realize.

Jim

> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Friday, October 20, 2017 6:21 AM
> To: Jim Schaad <[email-masked]>; draft-tiloca-ace-oscoap-
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-tiloca-ace-oscoap-joining
> 
> 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.
> > To: [email-masked];
> > draft-palombini-ace-coap- [email-masked]
> > Cc: [email-masked]
> > 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 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.
> >
> > 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.
> >
> >
> > 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.
> >
> > Jim
> >