Code change:
text for proxy security cases
Reverse proxy may act as origin server and hence client doesn't use e2e security to server group. However, in other cases a reverse proxy may assume the client uses e2e OSCORE security and not add any security by itself. To consider all the different, possible/valid cases for this. And see if it's different for forward proxies.
One particular example is a client that connects over CoAP+TLS+TCP (or CoAP+DTLS) to the reverse-proxy, where the proxy uses OSCORE security for the multicast request. The client is not aware of the (group) security material which the proxy and servers have.
At high level, there are 4 different potential cases of "proxying with security". Forward proxy with e2e security [=Group oscore e2e via proxy] Forward proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Reverse proxy with e2e security [=Group oscore e2e via proxy] Reverse proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Currently the draft doesn't say anything about these combinations, which are valid, which not, and where to find the security solution to them (e.g. a pointer to draft-groupcomm-proxy for covering most of these cases) This text/analysis could be a new Section 5.3 "Proxy Security" or so. Note: cases 2 and 4 depend on a 100% trusted proxy so no e2e security model. The client in this case is not even aware necessarily of the existence of Group-OSCORE. The proxy stores the "group member identity" to be used to make the Group OSCORE protected request. This may be a single identity, or a separate identity for each authorized user of the Proxy service. Case 1 and 3 most likely means OSCORE-in-OSCORE is needed?
It seems like a good idea. Intermediaries are usually considered non-trusted, hence the interest for an actual e2e security model between origin client and origin servers. How would the proxy store and use a "group member identity" ? Even if the proxy somehow obtains multiple different Sender IDs from the Group Manager (i.e., one for each authorized user of the proxy service), the proxy would have to sign a Group OSCORE protected request with a private key of its own (possibly one per corresponding Sender ID), which is not in control of the actual origin client. With such a level of trust on the proxy, and with a client not interested in e2e security anyway, it would be just easier to think of the proxy simply as another single member of the same OSCORE group including the servers, thus sacrificing verifiable data authorship/origin. Maybe this might be useful/applicable for case 4, with a client anyway likely unaware of what happens beyond the reverse-proxy and to be actually reaching a group of servers. Not sure about case 2, where the client would be aware of an actual group of servers it tries to reach. Yes, when exactly OSCORE is also conveniently used between Client and Proxy, to fulfill REQ2 from URL : REQ2. The CoAP proxy MUST identify a client sending a CoAP group request, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following ... Note that this requirement applies even in case end-to-end security is not enforced between client and servers.
Agree, in the two-legs security case it seems sufficient that the proxy has one "identity" within the group. And I agree that this proxy would most likely be a reverse proxy Case 4 i.e. it operates like a (trusted!) origin server. By definition of a reverse proxy , it has to be trusted just like a client trusts an origin server with being able to know and manipulate the served content.
This issue was addressed in Section 5.3 of version -04. NAME , can we close it?
Yes!
Looks good! See inline some proposed rephrasing.

Related discussion:
text: This section defines how proxies operate in a group communication scenario.  In particular, sec-proxy-forward defines operations of forward-proxies, while sec-proxy-reverse defines operations of <del> reverse-proxies. </del> <ins> reverse-proxies.  Security operations for a proxy are discussed later in chap-proxy-security. </ins> 3.5.1.