Subject: [Ace] Review of draft-palombini-ace-coap-pubsub-profile-01

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Oct 2017 18:08:45 -0700

Here are some comments on this draft.

1.  I find it difficult to call this a profile of the Oauth document in one
way.  This looks to me more of a "This is how you use the Oauth" document.
This echoes a comment that I made on the ACE base Oauth document.

2.  Introduction:  I think you should give a (very) brief introduction into
the pub sub system here rather than assuming that people are going to read
the pub/sub draft first.

3.  Overview:  I have a slight problem with the title of this section.  To
me I would expect an "Overview" and an "Introduction" to be the same
section.  Think about combining the sections together or rename this section
to be more specific.

4.  Overview:  this is a nit - I think that you want a different term than
scenario here.

5.  Overview:  You need to expand and define RS and AS on first usage.

6.  Overview:  One of the things that I am not currently happy with is that
you are looking at AS1 and AS2 as being independent appliers of access
control logic without any communication between them.  I think that AS1
needs the ability to give policy to AS2 on a topic after it has been created
and before any subscribers get keys.  In the case they are co-resident this
is trivial, in other cases it may not be.

7. Overview:  It is not clear to me that your allocation of roles to AS1 and
AS2 I correct.  If you have a second publisher, does it need to talk to both
AS1 and AS2 or just to AS2?  Is this really an AS1 controls creation of
topics and AS2 controls publishing and subscribing to topics?  If the
publisher loses its membership in the group for any reason, should it be
able to publish willy-nilly anyway?  I.e. should AS2 be able to "revoke" the
publishers right to publish?

8.  Overview:  I don't think the picture is correct at the bottom of the
section.  You have a Publisher-Subscriber client/client association

9.   Overview:  Is there any expectation that the broker should be notified
on a "revocation" of a publisher's right to publish?  (As opposed to the
right just expiring.)  There is no need to enforce subscribers right to
subscribe since a key roll over means that they are getting gibberish.

10.  Section 3 - I would remove 'D' from the picture as it gets a confusion
between updating the tokens and publishing content.  It is covered just fine
by the core document.  If you are using it as a 'publish' operation, then it
does not belong in the first bullet point.  It could also be the difference
between pushing the token and getting a session.  Again I don't think these
need to be separate, that is clear from the core document and you are not
doing anything different.

11.  Section 3.1 - I don't' think that the returned info on the first
request is going to be the same for publishers and subscribers.  Not sure
what this should really look like.

12. Section 3.1 - I am unsure what you believe is going to be accomplished
by doing a RD lookup.  You can get the name of the resource, but it would
not necessarily return the AS1, AS2 strings.

13.  Section 3.1 - On the unauthorized response, I think you want to be
returning different responses to subscriber vs the broker.  A subscriber
does not need to know about AS1.  Also I think you should be using the same
tag as the base profile for at least one of them - probably the first one
you would contact.

14.  Section 3.1 - I am not sure that it makes any sense to set an audience.
If the scope is the topic then all information exists.  The audience really
the subscriber.

15. Section 3.1 - You state that the algorithm must be a CE algorithm, but I
think you mean a signing algorithm.

16.  Section 3.1 - why not use the cnf return value for the key?  Also there
is no reason to make it a bstr rather than a map.

17.  Section 3.1 - need to define a signers_keys element which returns all
of the signing keys.  Defined as an array of keys.  Return other signers for
multiple publishers.

18.  Section 3.2 - see above about strings to be returned here.

19.  Section 5 - Need to talk about how to deal with multiple publishers -
are you assigning different keys or are you using different IV sections?
Need to ensure that you don't have an error from using the same key/iv pair.

20.  Section 5 - Are you containing a coap payload or a complete coap
message in the payload.  

21.  Section 5.  Do you want to talk about coordination of the observer
number and the iv of a message?

---

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

Hi Jim,

Thanks for a thoroughly review! 

I agree with many of your comments, and I modified the draft accordingly. I have included your comments (and my answers) in the source of the draft, next to what I thought was the right text for them, if you want to track it: https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/draft-palombini-ace-coap-pubsub-profile.md 

I report below the comments (and answers) which I think require more discussion.

Thanks,
Francesca

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: den 10 oktober 2017 03:09
> To: [email-masked]
> Cc: [email-masked]
> Subject: Review of draft-palombini-ace-coap-pubsub-profile-01
> 
> 1.  I find it difficult to call this a profile of the Oauth document in one way.
> This looks to me more of a "This is how you use the Oauth" document.

We should probably follow up on this comment on the ACE framework document.

> 6.  Overview:  One of the things that I am not currently happy with is that you
> are looking at AS1 and AS2 as being independent appliers of access control
> logic without any communication between them.  I think that AS1 needs the
> ability to give policy to AS2 on a topic after it has been created and before
> any subscribers get keys.  In the case they are co-resident this is trivial, in
> other cases it may not be.

AS1 and AS2 have in my mind clearly separated functions. There is some coordination involved of course (to gain knowledge of the policies), but I think that how this is dealt with is application specific. For example, there could be some node distributing those (they do not need to talk to each other directly). It may be good to add some generic considerations, do you think that would be enough?

> AS1 and AS2 or just to AS2?  Is this really an AS1 controls creation of topics
> and AS2 controls publishing and subscribing to topics?  If the publisher loses
> its membership in the group for any reason, should it be able to publish
> willy-nilly anyway?  I.e. should AS2 be able to "revoke" the publishers right to
> publish?
>

A second publisher would need to talk to both AS1 and AS2. As I intended, AS1 controls who can publish to (or create) a topic on a broker, AS2 more generally controls who can decrypt the content of the publication.
"Losing the membership" can mean "not being able to access (read or write) the content of the publication", in which case AS2 should revoke the node's rights or it can mean "not allowed to publish on the broker" (maybe it is still allowed to subscribe to the topic), in which case AS1 should revoke the node's right. Both revocations are not specified for now.

> 8.  Overview:  I don't think the picture is correct at the bottom of the section.
> You have a Publisher-Subscriber client/client association
> 

Both publisher and subscriber are CoAP client, as specified in the pub-sub doc

> on a "revocation" of a publisher's right to publish?  (As opposed to the right
> just expiring.)  There is no need to enforce subscribers right to subscribe
> since a key roll over means that they are getting gibberish.

Yes, the broker should be notified of revocation. This is not specified here, and I think this is a general topic that the framework should address: no profile deals with revocations so far, as far as I can tell.

> 11.  Section 3.1 - I don't' think that the returned info on the first request is
> going to be the same for publishers and subscribers.  Not sure what this
> should really look like.
> 

The broker _may_ send this info to both pub and sub, and then the subscriber could just discard the AS it does not need (AS1). Or the sub could know what AS to contact from a different exchange.

> 12. Section 3.1 - I am unsure what you believe is going to be accomplished by
> doing a RD lookup.  You can get the name of the resource, but it would not
> necessarily return the AS1, AS2 strings.
> 

Ok, I guess the same comment applies to https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-01#section-2  (4th paragraph) ? Otherwise I might have misunderstood that.

> returning different responses to subscriber vs the broker.  A subscriber does
> not need to know about AS1.  Also I think you should be using the same tag
> as the base profile for at least one of them - probably the first one you would
> contact.
>

I assume this was in this section (3.2) and not 3.1? Did you mean "publisher" instead of "broker"? As I mentioned in another comment, a subscriber may just drop the AS1 info. I do use the same tag as the DTLS profile. Do you think that it should anyway be stated somewhere?

> If the scope is the topic then all information exists.  The audience really the
> subscriber.
> 

That's right. I removed the scope, since the example states that the audience parameter contains the resource on the server (see https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-6.5 , bullet A)

> think you mean a signing algorithm.

Right, in COSE_Key. Also, I removed it from the last bullet because I could not find it in the ACE framework doc anymore (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-07#section-5.5.1)

> 16.  Section 3.1 - why not use the cnf return value for the key?  Also there is
> no reason to make it a bstr rather than a map.
> 

I did not use the cnf because of the following reasoning: the key is not used to authenticate the client (pub or sub) to the rs (broker), it is not a pop-key related to a token (no token). For subs, there are both cnf and key parameter (see {{fig-resp2-as2}}). Also, see the example on https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-6.5  (token-less exchange).
 OK, Changed to map.

> 17.  Section 3.1 - need to define a signers_keys element which returns all of
> the signing keys.  Defined as an array of keys.  Return other signers for
> multiple publishers.
> 

Are you sure this comment should be in this section? To a subscriber, yes, the set of all signers keys are returned (see {{subs-profile}} section: "The AS2 response contains a "cnf" parameter whose value is set to a COSE Key Set, (Section 7 of {{RFC8152}}) i.e. an array of COSE Keys, which contains the public keys of all authorized Publishers..."). If you did mean it for publishers, I don't see why.

> 19.  Section 5 - Need to talk about how to deal with multiple publishers - are
> you assigning different keys or are you using different IV sections?

Right, the key is the same ("key" in previous sections), but the IV is different. Added Base IV in the COSE_Key in previous section, and partial IV in the COSE_Key. Added TODO for sending Partial IV range for each publisher.

> 20.  Section 5 - Are you containing a coap payload or a complete coap

CoAP payload.

> number and the iv of a message?

What do you mean by "observer number"?