Draft: draft-ietf-core-groupcomm-bis

Commentary: text for proxy security cases 
 Reverse proxy may act as origin server and hence client does n'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 " . proxy with e2e security [= Group oscore e2e via proxy ] proxy with two - leg security [= unicast OSCORE or DTLS on 1st leg , with group OSCORE on 2nd leg ] proxy with e2e security [= Group oscore e2e via proxy ] proxy with two - leg security [= unicast OSCORE or DTLS on 1st leg , with group OSCORE on 2nd leg ] Currently the draft does n'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  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  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 : 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 . 
  , 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  . , can we close it ? 
 Yes ! 
 Looks good ! See inline some proposed rephrasing .
Paragraph (version A):
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
reverse-proxies.
Paragraph (version B):
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
reverse-proxies.  Security operations for a proxy are discussed later
in chap-proxy-security.
Paragraph (version B):
Different solutions may be selected for secure group communication
via a proxy depending on proxy type, use case and deployment
requirements.  In this section the options based on Group OSCORE are
listed.
Paragraph (version B):
For a client performing a group communication request via a forward-
proxy, end-to-end security should be implemented.  The client then
creates a group request protected with Group OSCORE and unicasts this
to the proxy.  The proxy adapts the request from a forward-proxy
request to a regular request and multicasts this adapted request to
the indicated CoAP group.  During the adaptation, the security
provided by Group OSCORE persists, in either case of using the group
mode or using the pairwise mode.  The first leg of communication from
client to proxy can optionally be further protected, e.g., by using
(D)TLS and/or OSCORE.
Paragraph (version B):
For a client performing a group communication request via a reverse-
proxy, either end-to-end-security or hop-by-hop security can be
implemented.  The case of end-to-end security is the same as for the
forward-proxy case.
Paragraph (version B):
The case of hop-by-hop security is only possible if the proxy can be
completely trusted and it is configured as a member of the OSCORE
security group(s) that it needs to access, on behalf of clients.  The
first leg of communication between client and proxy is then protected
with a security method for CoAP unicast, such as (D)TLS, OSCORE or a
combination of such methods.  The second leg between proxy and
servers is protected using Group OSCORE.  This can be useful in
applications where for example the origin client does not implement
Group OSCORE, or the group management operations are confined to a
particular network domain and the client is outside this domain.
Paragraph (version B):
For all the above cases, more details on using Group OSCORE are
defined in I-D.tiloca-core-groupcomm-proxy.