Hello Francesca, Marco and ACE, I've had a bit of a hard time working through ace-key-groupcomm (and the associated OSCORE adaption); here's what I think makes it difficult:
(It may be worth pointing out that my perspective in reading was joining a group as a monitor device, which may explain my points of attention or lack thereof) * Some example exchange ... somewhere would make it easier to digest. I'm not saying that every step needs one here (and am aware that I have a tendency to overdo it myself), but skimming through examples often allows getting a rough idea much more quickly than having it develop while going through the text. * The way groupcomm-specific data is exchanged in the token phase violates the layering of ACE as I see it. The whole section 3 (Authorization to Join a Group) should be expressible a few paragraphs. Figure 2 already indicates that ("Defined in the ACE framework"), yet it spans 7 pages. The part where outlines how scope is expressed w/rt groups is good, that needs to be there. Then there are sign_info and kdcchallenge, which are for the next bullet. Apart from that, it largely reads like a repetition of general ACE. That may be justified by the intention to make it usable for readers who didn't go through the rest of ACE before, but then please mark it as such. (To illustrate: In 3.2 around rs_cnf I started wondering whether that might apply when asymmetric keys are used in the group because I never had to deal with rs_cnf, just to realize that it's some ACE transport profiles that use it. I've only used ACE-OSCORE so far, and sure there's several generic ACE mechanisms I haven't used, but why is this piece of information occupying my time here?). * Join components in the Token phase I understand sign_info and kdcchallenge to be process optimizations that allow joining the group with fewer round-trips. The point they are introduced at does not make this obvious, though -- the reader is right in the middle of going through the ACE part and possibly trying to figure out what they already have implemented and what's changed here. Frankly, if there were a better way to bundle compressed requests ("and by the way, of the things I'm now authorized to see, give me the sign_info") or unsolicited responses ("and by the way, if you tried to register with a public key, you'd fail because you don't have a kdcchallenge, so here's one to get started"), I'd suggest it here, but I don't have anything written I could refer you to. But from a teaching and understanding point of view, I think that it'd be better structured about like this: * In the very short ACE section, add an item that "Parts of the following group joining process can be rolled into the token exchange. They manifest in a sign_info entry in the token request, and a kdcchallenge in the token response (which is then an application/ace+cbor representation rather than empty). These can be added by the parties to save round-trips and are described in detail in appendix X. While it is RECOMMENDED that they are used when adaequate, parties MAY ignore them (but MUST NOT fail the process just because they find them in a message)." * Then explain the process from a client not having a kdcchallenge (or having a stale one, or not even having sign_info) with the clear separation of ACE tasks and interactions with the protected resource (the join resource). Here may be a place for a note about the option to optimize away the step by using appendix X. * Then, in the appendix, use the established knowledge of what sign_info and the challenge do to concisely map the data items piggy-backed on the token exchange into information populating the client's cache of the groups. * On the AIF: The first parameter of the AIF is said to be "the identifier of the specific group or topic". I suppose the identifier cleanup will make this clearer. As it's described as a default, how is that overridden, and how does the client know whether it can just construct a scope or has to try first and wait for the KDC to give it a good value in a 4.01? * 4.1.2.2 GET handler of /ace-group/GROUPNAME: Why MUST requests from authorized (as per third paragraph) but non-member (as per fourth) clients turned down with 4.00? The only reason I can think of to deny that would be running an audit trail of which authorized clients actually joined (to see when to rekey after a compromise), but as that sounds like it's within range of the permissive side effects a GET could have just as well (as per RFC7231 Section 4.2.1), so rather than refusing, the GET could just be served and the audit entry created. (Otherwise, my gut feeling says this should be a 4.01 response as well, but maybe we don't need to have that discussion in the first place). * If, of course, the client's scope is only to get public keys of the group but not the cryptographic material (as might be for scenarios where there is a verifier), then that client would not be allowed to GET that data, and should be 4.01'd no matter whether it has actually joined the group nor not. That case seems not to be covered well in the 4.1.2.2 GET handler description: Neither check ("group is in scope", "is a current member") really accounts for that. (The 'signature verifier' role of -oscore says "does not join [...] as an *actual* member", but I wouldn't count on everyone reading that as "not a member at all" for the purpose of the above paragraph). * 4.1.3.1 and 4.1.3.2 (/ace-group/GROUPNAME/pub-key FETCH): The "The handler verifies that" and "Note that this resource handler" appear to contradict each other (or the latter overrides the former); it would be easier to understand if they were rolled in one. The former reads like boilerplate text; I'd rather see that avoided ("For all resources, X and Y apply") or referenced if the reader can't be trusted to read the whole document ("General authentication requirements per Section X apply."). Defined terminology may help there as well ("is Authenticated As a group member", "is Authenticated As the group member identified by NODENAME" in other places). * 4.1.3.1 and 4.1.3.2 (/ace-group/GROUPNAME/pub-key GET and FETCH): The GET text reads like a duplicate of the FETCH text. Can't this be a simple "GET requests are served just like FETCH requests but without any filtering"? * GROUPNAME/num: Is there a particular reason this is a dedicated resource and not just accessed through GROUPNAME? * request latest keying material "To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.1.6.2." What's the purpose of the node observing its own resource rather than the the whole group? After all, its own keys won't change out of the blue, just the group's material. * I'm a bit uncertain about the change of keys mid-blockwise, but can't put a finger on it yet. Do you have any use case examples that'd help me figure out what such an operation would look like in the first place? * IANA File Extension: Why? * I've only skimmed section 8. Kind regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace