[Ace] Review of ietf-ace-key-groupcomm-08

[[e-mail]]

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