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 protected]] > Sent: den 10 oktober 2017 03:09 > To: [email protected] > Cc: [email protected] > Subject: Review of draft-palombini-ace-coap-pubsub-profile-01 > > 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. > 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? > > 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? > 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 > 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. 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. > 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. > 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? > 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. > 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) > 15. Section 3.1 - You state that the algorithm must be a CE algorithm, but I > 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? > Need to ensure that you don't have an error from using the same key/iv pair. 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 > message in the payload. CoAP payload. > > 21. Section 5. Do you want to talk about coordination of the observer > number and the iv of a message? > What do you mean by "observer number"? _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
