Constrained Join Protocol (CoJP) for 6TiSCH
Extracted elements (31)
CoJP limits the entire join procedure to a single CoAP request-response exchange because 6TiSCH nodes keep their radios off most of the time to conserve energy, giving the join link limited bandwidth. Reusing CoAP and OSCORE, which are already in the 6TiSCH stack, also minimizes code footprint on constrained microcontrollers.
The Link_Layer_Key object is encoded as a CBOR sequence rather than a CBOR map, avoiding the overhead of per-element integer labels. The CBOR type of the first element (uint for key_id) acts as a structural delimiter between successive key objects within the key-set array, enabling compact multi-key encoding.
The pledge communicates with the JRC at the application layer only (via JP proxy), rather than at the network layer, so that it can join without knowing the JRC's IPv6 address. The pledge learns the JRC's global address only from the Join Response, after which it can act as a JP itself.
The mandatory-to-implement AEAD algorithm is AES-CCM-16-64-128, which is also used for IEEE 802.15.4 frame security and has hardware acceleration on virtually all compliant radio chips. The mandatory KDF is HKDF (RFC 5869) instantiated with SHA-256.
All frames originated at the JP and destined to the pledge during the join process MUST be authenticated at the link layer using the key normally in use in the network. This prevents a time-replay attack where forged EB frames cause the pledge to reuse an IEEE 802.15.4 link-layer nonce.
Each pledge MUST be provisioned with a unique PSK that is a cryptographically strong key with at least 128 bits of entropy, indistinguishable from a random uniform string. In the case of recommissioning a device to a new owner, the PSK MUST be changed.
Implementations MUST ensure that multiple CoAP requests, including to different JRCs, properly increment OSCORE sequence numbers so that the same sequence number is never reused under the same PSK. Reuse breaks AEAD security guarantees due to nonce reuse.
Implementations MUST use different link-layer keys when using different authentication tag (MIC) lengths, as using the same key with different MIC lengths may be unsafe. For example, the same key MUST NOT be used for both MIC-32 and MIC-64 security levels.
Mutable OSCORE context parameters (Sender Sequence Number, Replay Window) MUST be stored in persistent memory. Each update of the Replay Window MUST be written to persistent memory to guarantee nonce uniqueness and replay resistance across reboots and rejoins.
OSCORE errors during the join process MUST be silently dropped with no error response signaled. The pledge MUST silently discard any response not protected with OSCORE, including CoAP error codes, to prevent an attacker from sending bogus errors that force sequential network exhaustion.
The JRC and any proxy on the JP-JRC path MUST support extended CoAP token lengths per RFC 8974. When the JP operates statelessly, the CoAP message type it forwards on behalf of the pledge MUST be non-confirmable (NON) regardless of the message type received from the pledge.
The JRC MUST ensure that at any given time there are never two nodes using the same short identifier under the same link-layer key, because the short address is an input to the IEEE 802.15.4 TSCH link-layer nonce construction.
The OSCORE security context MUST be derived per RFC 8613 Section 3: Master Secret MUST be the PSK, Master Salt MUST be the empty byte string, ID Context MUST be the pledge identifier, pledge Sender ID MUST be the empty byte string, and JRC Recipient ID MUST be 0x4a5243 ('JRC' in ASCII).
The pledge identifier MUST be unique in the set of all pledge identifiers managed by a JRC. The network identifier MUST be provisioned to the 6LBR pledge; regular pledges for which it is omitted will attempt networks one at a time, significantly prolonging the join process.
When a regular 6LN receives a Configuration object with a new link-layer key set, it MUST install the new keys but MUST continue using old keys for outgoing traffic until it receives a frame authenticated with the new key set. It MUST then switch outgoing traffic and MUST remove old keys after COJP_REKEYING_GUARD_TIME.
When JRC failure results in loss of mutable security-context parameters, the network administrator MUST force all networks managed by the failed JRC to rejoin through out-of-band means. The RFC 8613 Appendix B.2 nonce-renegotiation procedure is RECOMMENDED; nonces exchanged via that procedure MUST be at least 8 bytes.
The pledge identifier, typically the EUI-64, is transmitted in cleartext in the OSCORE 'kid context' field and is visible to the JP. A random byte string MAY be used instead of the EUI-64 as the pledge identifier for privacy, provided it satisfies the uniqueness requirement. The blacklist parameter also carries pledge identifiers in cleartext.
The Configuration object is a CBOR map with labels: link-layer key set (2, array of Link_Layer_Key), short identifier (3, Short_Identifier array), JRC address (4, 16-byte byte string), blacklist (6, array of byte strings), and join rate (7, uint in bytes/second). All parameters are optional.
The Diagnostic Response message is returned when processing of a CoJP request payload fails. It maps to a CoAP 4.00 (Bad Request) response carrying an Unsupported_Configuration CBOR object identifying the parameter and error code that triggered the failure.
The Join_Request object is a CBOR map with labels: role (1, optional uint indicating '6TiSCH Node'=0 or '6LBR'=1), network identifier (5, required byte string), and unsupported configuration (8, optional Unsupported_Configuration array). The network identifier MUST always be included.
The Link_Layer_Key structure is encoded as a CBOR sequence (not a map) containing: key_id (required uint), key_usage (optional int referencing the CoJP Key Usage registry), key_value (required byte string), and key_addinfo (optional byte string for Key ID Mode signaling in IEEE 802.15.4).
The Parameter Update message, sent by the JRC to a joined node, is a CoAP POST CON request to Uri-Host '6tisch.arpa', Uri-Path 'j', secured with OSCORE. The joined node acts as CoAP server and exposes the '/j' resource, reversing the client/server roles from the join exchange.
The Short_Identifier object is a CBOR array containing: identifier (required byte string, exactly 2 bytes for IEEE 802.15.4 TSCH) and lease_time (optional uint in hours). The pledge MUST stop using the identifier after lease expiry and SHOULD initiate a new join exchange.
The 'Constrained Join Protocol (CoJP) Key Usage' IANA registry defines 15 initial integer values (0–14) mapping to IEEE 802.15.4 AES-CCM-128 configurations, specifying which frame types (EB, DATA, ACKNOWLEDGMENT) and MIC lengths (32/64/128-bit) each key should be used for.
The 'Constrained Join Protocol (CoJP) Parameters' IANA registry (Expert Review) assigns CBOR integer labels to CoJP object parameters: role=1, link-layer key set=2, short identifier=3, JRC address=4, network identifier=5, blacklist=6, join rate=7, unsupported configuration=8.
The 'Constrained Join Protocol (CoJP) Unsupported Configuration Codes' IANA registry (Expert Review) defines integer codes indicating why a configuration parameter cannot be acted upon, such as 'Unsupported' or 'Malformed', carried in the Unsupported_Configuration object.
A stateful CoAP proxy at the JP is vulnerable to memory exhaustion DoS from unauthenticated pledges. The JP SHOULD operate statelessly by encoding per-pledge state in the CoAP extended token (RFC 8974), so that responding to the JRC's echoed token recovers all necessary forwarding state.
An attacker can replay legitimate EB frames to the pledge, acting as a man-in-the-middle to cause the pledge to adopt a stale Absolute Slot Number, potentially causing nonce reuse in the first link-layer-secured frame after joining. Requiring link-layer authentication of all JP-to-pledge frames during the join process mitigates this.
Unauthenticated join traffic forwarded by the JP may cause intermediate 6TiSCH nodes to over-allocate bandwidth and energy. JPs SHOULD mark forwarded join traffic with DSCP AF43 so Scheduling Functions can suppress additional cell allocation for such traffic.
The pledge join process traverses four steps: (1) passive scan for Enhanced Beacon and TSCH synchronization; (2) optional Neighbor Discovery with JP; (3a) send OSCORE-protected Join Request via JP to JRC; (3b) receive Join Response and transition to joined node. CoAP retransmit failure triggers an attempt on a different network identifier.
CoJP payloads are CBOR-encoded. In the OSCORE option, the pledge sets the 'kid' flag with a 0-length 'kid' (because its Sender ID is the empty byte string) and transports its pledge identifier in the 'kid context' field, allowing the JRC to retrieve the per-pledge security context.