Summary

  • RFC 10020 defines a CoAP group, an application group and a security group as distinct sets. Their relationships may be many-to-many, one-to-many, many-to-one or one-to-one; a deployment, not the protocol, decides how they align.
  • Group OSCORE can authenticate the particular security-group member that sent a protected request. The RFC explicitly separates that membership from authorization to use an application resource. A useful control record must therefore join three rosters, a key epoch and a separate authorization decision.

The request was validly protected and the sender was identifiable. Every intended server could verify it as coming from a member of the OSCORE group. Yet one receiver no longer belonged to the operational cohort that the command was supposed to control. It still listened on the multicast address, still possessed current group material and still exposed the matching resource.

Nothing in the cryptographic verdict could express that business mismatch. The message was authentic. The membership was real. The mandate had drifted.

That distinction sits at the center of RFC 10020, the July 2026 Standards Track specification for group communication with the Constrained Application Protocol. The document obsoletes RFC 7390, updates RFC 7252 and RFC 7641, and makes UDP/IP multicast the default transport for CoAP group requests. More importantly for governance, it refuses to describe “the group” as a single fact.

Three memberships, three questions

A CoAP group is a set of endpoints configured to receive group messages sent to an associated IP multicast address and UDP port. Its question is about network reachability: which endpoints listen here? A group URI can contain the multicast address or a group hostname and, when needed, a port other than CoAP’s default UDP port 5683.

An application group is a set of server endpoints sharing application-level functionality through CoAP resources. Its question is functional: which servers implement the resource behavior addressed by this request? The application group can be named in a URI path or inferred from the request and deployment context.

A security group contains endpoints that hold shared security material for protecting and verifying messages. Its question is cryptographic participation: which endpoints can validly send or process traffic under this security context? An endpoint may belong to several such groups.

These sets do not inherit one another. RFC 10020 permits every cardinality among them: many-to-many, one-to-many, many-to-one and one-to-one. Multiple application groups may use one security group to reduce storage and update costs. One application group may use several security groups because clients support different algorithm suites. Configuring entities establish the mappings for the particular deployment.

The source side is separate too. RFC 10020 scopes UDP/IP multicast to Any-Source Multicast. A sender may or may not be a member of the destination multicast group, and the protocol does not limit the number of senders. A dashboard that displays the listening roster as the sending authority roster has already merged two different facts.

Authentication stops before authorization

Secured CoAP group communication uses Group OSCORE, specified in RFC 10021 and built on OSCORE in RFC 8613. At the application layer, messages receive confidentiality and integrity protection through the COSE framework defined in documents including RFC 9052. Group mode uses sender signatures; pairwise mode derives keys for one-to-one exchanges.

The resulting assurance is precise. A recipient can verify that a protected message originated with a specific, identified endpoint that belongs to the OSCORE group. Shared symmetric material alone supplies only group-level authentication, but Group OSCORE adds source authentication. It does not, however, authenticate the packet’s source IP address or UDP port.

Nor does it grant general permission over the application group. RFC 10020 expressly says that security groups are not meant to represent different access policies inside one application group. Membership grants the ability to exchange protected messages and authenticate group members. Authorization to use a resource belongs to a separate security domain and should be enforced through resource properties or dedicated access-control credentials.

That is the decisive boundary. “Signature verified” answers who sent the request within a security epoch. “Resource authorized” answers whether that sender may invoke this method on this path, for this application cohort, now. Replacing the second decision with the first turns a secure transport group into an accidental entitlement system.

The ACE framework in RFC 9200 can support authorization when endpoints join a security group through a Group Manager. But permission to obtain group material is still not automatically identical to permission for every resource protected by it. Join authority, message authenticity and resource authority need separate evidence.

Membership drift begins before deployment

RFC 10020 uses the neutral term “configuring entity” because no single operator necessarily creates all three groups. An application, a user, a developer, a cloud service, a commissioning tool or another actor can establish a group. Configuration may occur during software creation, in a factory, at a reseller, during initial installation or during later reconfiguration.

The document notes that different configuring entities may perform those steps with minimal or no coordination. That observation turns a clean protocol diagram into a lifecycle problem. A factory can load a security identity, an installer can assign a multicast address, an application service can define a resource cohort, and a later maintenance team can change only one of the three.

Group maintenance is correspondingly broad. It includes joining and leaving members, replacing security material, changing the IP multicast address or UDP port, changing the group URI, renaming application groups, and splitting or merging groups. A change ticket that says only “device removed from group” is incomplete: from which group, at which control point, and with what effect on the other two?

Security material has its own time boundary. OSCORE groups require rekeying for revocation and renewal. When churn is frequent and rekeying is slow, an operator may cautiously batch changes rather than rekey after every join or departure. The trade-off is explicit. Until the next rekey, a recently departed endpoint may retain access to communication under existing material; depending on policy, a new member may gain access to earlier protected traffic.

“Member” therefore needs an epoch. A security roster without the key version and rekey completion state can report a departed device and a currently trusted device as if their powers were identical.

Silence is not a negative receipt

Group communication also changes what an observer can infer from responses. A client sends one request over multicast; individual servers ordinarily return responses over unicast. To avoid congestion and response implosion, group requests are Non-confirmable and servers delay replies over a randomized Leisure interval. Congestion controls such as NSTART and PROBING_RATE still matter.

Servers may suppress responses. RFC 10020 says they should suppress an error or a response with nothing useful to contribute unless the application policy requires it. A client can use the No-Response option to influence suppression only where that choice has already been judged appropriate for the resource.

Consequently, no response does not prove no execution. It may mean the request was lost, the receiver did not match the application group, the resource rejected the method, policy suppressed the error, the reply was delayed, or the response was lost. Repeating the request may cause servers that handled the first copy to process a new message again. An audit built only from received responses cannot reconstruct the receiver set with confidence.

This is where Heng Lu’s running-code principle matters. The declared memberships describe intended boundaries. Observed receiver behavior shows what the deployed system did. Neither replaces the other. A control system needs the mapping and the execution evidence together.

The three-roster authorization receipt

A three-roster authorization receipt can preserve that chain without pretending the protocol created one universal group. The first section identifies the CoAP group: multicast address or hostname, UDP port, address scope, listening endpoints, discovery source and configuration epoch. It records the sending endpoint separately because Any-Source Multicast does not require it to listen to the destination group.

The second section identifies the application group and exact resource decision. It records URI path, method, relevant payload class, the server cohort expected to implement that function, policy version, authorization credential or resource property assessed, decision result, and expiry. “Can verify the packet” is never accepted as the authorization field.

The third section identifies the security group: Group Manager, group identifier, algorithm suite, authenticated sender identity, OSCORE key epoch, join evidence, leave state, last rekey and whether rekeying completed at every required member. Source authentication and network-address validation are separate. Where reachability validation matters, the Echo option from RFC 9175 can help establish that the authenticated requester is reachable at the claimed address.

The outcome section records intended receivers, observed processing results, response-suppression policy, Leisure window, replies received, known losses, repetitions and side effects. Silence is stored as an unresolved observation rather than converted into “not executed”. The lifecycle section links each roster change to the configuring entity that made it and to the reconciliation that checked the other two rosters.

This receipt is Daniel Kade’s editorial governance proposal, not a requirement in RFC 10020. Its purpose is to prevent a valid address, a matching resource and valid security material from being compressed into one misleading green status.

Secure group traffic still has an amplification boundary

Unsecured group communication under NoSec is strongly discouraged. RFC 10020 limits any exception to narrow, well-understood steps that cannot attain or do not require security, such as some early discovery cases, and forbids public-Internet access to a NoSec group server. The reason is structural: a spoofed source address on one multicast request can direct multiple server responses at a victim.

Group OSCORE narrows that attack surface by authenticating the sender and protecting the path and query, while response limits and the Echo option add further defenses. It does not abolish every threat. An on-path actor can still create address-related problems; an authenticated group member can be malicious; and the number and size of permitted responses still determine amplification impact.

Heng Lu’s policy-mirror argument supplies the broader test: the interface should reveal the actual distribution of control rather than display a reassuring abstraction. Here, control is divided among multicast configuration, resource deployment, Group Manager policy, application authorization, response behavior and operating evidence. A single “group healthy” badge hides the only facts that can assign responsibility.

The point is not to distrust group communication. It is to trust each assurance for exactly what it proves. BTW Media’s reality-first premise asks for that discipline: reachability, function, identity, authority and execution should remain separately observable even when a product wants to call them all membership.

Sources