CoAP, OSCORE, and Lightweight M2M

CoAP, OSCORE and LwM2M provide different parts of a constrained device system. Document which combination handles transport, message protection and device management.

Overview#

The Constrained Application Protocol (CoAP) is a compact request/response protocol for constrained nodes and networks. It has HTTP like methods and response classes but different transport, retransmission, discovery, observation, caching, and security behaviour. Lightweight M2M (LwM2M) builds a standardised device management and service enablement model on CoAP. OSCORE protects CoAP exchanges at the message layer. COAP LWM2M

These technologies are composable, not interchangeable:

application resource model       vendor model or LwM2M Objects/Resources
CoAP semantics                   methods, options, codes, Observe, block transfer
message protection               OSCORE where selected
transport protection             DTLS / TLS where selected
transport                        UDP / TCP / WebSocket profile
network                          IP and the applicable constrained network

An implementation must state the exact stack and profile. “CoAP secure,” “LwM2M,” or a familiar UDP port isn't enough to determine transport, identity, message protection, bootstrap mode, or authorisation.

CoAP resource and exchange model#

CoAP identifies resources with URIs and uses GET, POST, PUT, and DELETE methods. Responses use code classes: 2.xx success, 4.xx client error, and 5.xx server error. The meaning of a successful application response is resource specific; it doesn't prove a motor moved, a relay changed, an alarm was received by an operator, or a firmware update completed.

UDP message types#

The Message ID supports duplicate detection and matching for the local message layer exchange. The Token correlates a request and response across message layer details, including a separate response. Neither is a permanent event ID, authorisation credential, or fleet wide idempotency key. Use a domain operation identifier and durable deduplication policy for side effecting work.

A server can acknowledge a confirmable request and send the response separately later. Timeouts therefore need distinct budgets for message acknowledgment, application response, and authoritative device outcome. Avoid blind retry after an indeterminate result: the server may have committed an operation before the response was lost.

CoAP over reliable transports#

RFC 8323 defines CoAP over TCP, TLS, and WebSockets. Reliable transports use length framing and signalling behaviour rather than copying the UDP message retransmission model unchanged. Don't assume UDP Message IDs, confirmable message timers, multicast, or intermediary behaviour apply to a TCP/TLS/WebSocket binding. COAP TCP

IANA service names and ports such as coap/5683 and coaps/5684 are conventions, not protocol or security detection. A deployment should identify the negotiated stack from approved configuration and authenticated context. COAP

Options, representations, and parsers#

CoAP options carry URI components, content negotiation, freshness, observation, proxying, and extensions. Option numbers encode critical/elective and safe to forward properties. A parser should:

• reject malformed option deltas/lengths, truncated values, and invalid message framing;
• implement the standard rules for unknown critical options instead of ignoring them;
• cap total message, option count/length, token length, URI length, payload, nesting, and decoded object size;
• allow only approved content formats and validate the representation independently;
• keep URI path and query normalisation consistent across routing, authorisation, caching, and logs;
• treat remote diagnostics, entity tags, location values, and all representation metadata as untrusted.

Content Format identifies a representation format, not schema validity. CBOR, SenML, JSON, and vendor binary objects each need their own duplicate key, number range, depth, allocation, canonicalization, and extension policy.

Observe and block wise transfer#

RFC 7641 lets a client observe a resource and receive notifications. Observation is a soft state relationship. Preserve sequence/freshness rules, Max-Age, registration/re registration behaviour, cancellation, authorisation expiry, and gaps. A recently received notification is still an observation, not proof of present physical state; record source time, receipt time, quality, and the point at which state becomes stale. OBSERVE

RFC 7959 defines block wise transfer for representations too large for one message. Block1 and Block2 aren't generic file transfer transactions. Bound total reconstructed size, block number, block size, concurrent bodies, inactivity, out of order behaviour, and storage. Authenticate and authorise the completed logical operation consistently; don't let individually acceptable blocks bypass whole object validation. BLOCKWISE

Intermediaries, caching, and server side retrieval#

CoAP supports proxies and cacheable responses. Proxy-Uri, Proxy-Scheme, URI options, redirects at another protocol layer, and externally referenced content can turn a gateway into a server side request forgery path.

• Resolve only approved schemes and destinations; reject loopback, link local, metadata service, management, and unexpected private network targets.
• Revalidate after name resolution and every permitted redirection or proxy transition.
• Include method, effective URI, representation negotiation, OSCORE/security context, tenant, and authorisation policy in cache decisions.
• Never share a private representation merely because its URI and freshness metadata match.
• Bound cache entry size/count, negative caching, freshness, revalidation, and key cardinality.
• Keep proxy credentials and topology out of client visible errors and ordinary logs.

Security choices#

DTLS 1.3 is specified by RFC 9147, but constrained products can support older or restricted profiles. Record protocol versions, cipher/profile, credential type, peer identity, resumption behaviour, time dependence, and update path. Don't label an endpoint secure solely because it uses coaps. DTLS13

OSCORE context#

RFC 8613 uses AEAD protection and an OSCORE security context to protect CoAP messages while allowing selected outer fields needed by intermediaries to remain visible. Engineering records should include:

• context establishment/provisioning method and authenticated peer identity;
• master secret/salt custody, sender and recipient IDs, ID Context use, and algorithm suite;
• sender sequence persistence and recovery rules that prevent nonce reuse;
• replay window size and behaviour after reboot, restore, failover, or cloned state;
• which options remain outer visible and what metadata they disclose;
• group versus pairwise design, since group security and authorisation require a separate applicable profile;
• rekey, decommissioning, loss recovery, and multi server ownership.

OSCORE survives some proxy architectures because protection is bound to the CoAP message rather than each transport hop. A proxy can still observe or modify unprotected fields and availability, and an OSCORE authenticated peer can still lack permission for the requested physical resource. OSCORE

RFC 9175 defines Echo and Request Tag options and updates Token processing. Echo can support freshness checks, while Request Tag distinguishes request bodies in relevant block wise/retransmission cases. These mechanisms must be implemented under their specified rules; they aren't substitutes for OSCORE/DTLS, a durable operation ID, or post condition confirmation. COAP 9175

Lightweight M2M 1.2.2#

OMA Lightweight M2M 1.2.2 defines a device management architecture and object/resource model over CoAP. The principal roles are:

Core interfaces cover bootstrap, registration, device management/service enablement, and information reporting. Resources are addressed by Object, Object Instance, Resource, and where applicable Resource Instance identifiers. Object IDs and resource types provide structure; a deployment still needs the exact object version, data type, access mode, units, range, optionality, and vendor extension contract. LWM2M CORE

Registration and reporting#

Registration establishes the client's declared object capability and location at a server. Update, lifetime expiry, queue behaviour, network change, and re registration affect reachability. Registration success means that server/client protocol state exists, not that every sensor is fresh or every downstream physical function is healthy.

Information reporting commonly uses CoAP Observe semantics. Define minimum/maximum reporting periods, thresholds, stale state rules, queue mode behaviour, clock quality, and reconnection reconciliation. Rate limits must account for fleet wide reconnect or threshold storms.

Bootstrap and credential lifecycle#

Bootstrap can install or replace security sensitive server relationships. Use an explicit ownership model, unique per device credentials, authenticated bootstrap identity, destination allowlists, bounded retry, audit evidence, and a closed/bootstrap disabled normal state where the product supports it. Never experiment with live bootstrap discovery or server replacement to learn a device's behaviour.

Protect LwM2M Security and Server Object data from ordinary read paths and logs. Plan manufacturing enrolment, ownership transfer, credential rotation, server migration, backup/restore, compromised device quarantine, and decommissioning. A copied device image must not clone operational identity or OSCORE sender state.

Firmware and high impact operations#

Firmware Update and vendor management objects can alter code, reset devices, change networks, or affect outputs. Require signed update metadata/package validation, anti rollback policy, compatible hardware/version checks, staged rollout, power loss recovery, rate limits, and an independent health signal. A download response or execute request isn't update completion; preserve states for downloaded, verified, installing, rebooting, confirmed, rolled back, and failed.

Treat reboot, factory reset, credential change, network reconfiguration, relay/output, lock, camera privacy, alarm, and local rule changes as high impact. Separate authorisation, approval, maintenance window, idempotency, and recovery controls from ordinary telemetry reads.

Safe integration pattern#

A defensive gateway should begin with a declared resource allowlist and read only behaviour:

authenticated peer
      |
      v
transport / OSCORE validation
      |
      v
method + URI + content-format + size policy
      |
      v
schema and object-version validation
      |
      +----> bounded read / observe ----> normalized state with quality
      |
      +----> high-impact method -------> separate authorization and workflow

Don't perform live multicast discovery, bootstrap, observe registration, firmware transfer, resource writes, execute operations, or group actuation as a documentation validation technique. Static review can verify message field interpretation, URI/option limits, credential ownership, object version mapping, authorisation design, and synthetic fixture expectations without contacting a device.

Design and evidence checklist#

• CoAP version, UDP/TCP/TLS/WebSocket binding, URI scheme, and security profile explicit
• Message ID, Token, domain operation ID, retry, timeout, and completion semantics kept separate
• Method, URI, options, content format, schema, size, depth, allocation, and rate limits defined
• Observe freshness, sequence/gap, cancellation, authorisation renewal, and resubscription behaviour documented
• Block wise total size, concurrency, inactivity, and whole object validation bounded
• Proxy, external reference, DNS, redirect, cache key, and tenant isolation policy reviewed
• DTLS/TLS identity and OSCORE context, sequence persistence, replay, rekey, and restore behaviour recorded
• LwM2M object/resource versions and vendor extensions inventoried
• Bootstrap server, LwM2M server, client identity, ownership transfer, and decommissioning controlled
• Firmware, reset, credential, network, relay, lock, alarm, and other high impact operations separated from telemetry
• Protocol acknowledgment/success can't masquerade as physical or operational completion
• Audit evidence records trusted identity, resource, decision, operation ID, result stage, and authoritative post condition

Sources#

• COAP, RFC 7252: The Constrained Application Protocol, IETF, June 2014.
• COAP TCP, RFC 8323: CoAP over TCP, TLS, and WebSockets, IETF, February 2018.
• OSCORE, RFC 8613: Object Security for Constrained RESTful Environments, IETF, July 2019.
• COAP 9175, RFC 9175: CoAP: Echo, Request Tag, and Token Processing, IETF, March 2022.
• OBSERVE, RFC 7641: Observing Resources in the Constrained Application Protocol, IETF, September 2015.
• BLOCKWISE, RFC 7959: Block Wise Transfers in the Constrained Application Protocol, IETF, August 2016.
• DTLS13, RFC 9147: The Datagram Transport Layer Security Protocol Version 1.3, IETF, April 2022.
• LWM2M, OMA Lightweight M2M releases, Open Mobile Alliance, accessed 25 August 2026.
• LWM2M CORE, Lightweight M2M Core 1.2.2, Open Mobile Alliance, approved 13 June 2024.

Section overview · Wiki home