draft-ietf-6tisch-minimal-security-09.txt   draft-ietf-6tisch-minimal-security-10.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: May 24, 2019 Analog Devices Expires: October 7, 2019 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
November 20, 2018 April 05, 2019
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-09 draft-ietf-6tisch-minimal-security-10
Abstract Abstract
This document describes the minimal framework required for a new This document describes the minimal framework required for a new
device, called "pledge", to securely join a 6TiSCH (IPv6 over the device, called "pledge", to securely join a 6TiSCH (IPv6 over the
TSCH mode of IEEE 802.15.4e) network. The framework requires that TSCH mode of IEEE 802.15.4e) network. The framework requires that
the pledge and the JRC (join registrar/coordinator, a central the pledge and the JRC (join registrar/coordinator, a central
entity), share a symmetric key. How this key is provisioned is out entity), share a symmetric key. How this key is provisioned is out
of scope of this document. Through a single CoAP (Constrained of scope of this document. Through a single CoAP (Constrained
Application Protocol) request-response exchange secured by OSCORE Application Protocol) request-response exchange secured by OSCORE
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2019. This Internet-Draft will expire on October 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11
6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 6.1. Identification of Unauthenticated Traffic . . . . . . . . 12
7. Application-level Configuration . . . . . . . . . . . . . . . 13 7. Application-level Configuration . . . . . . . . . . . . . . . 13
7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13
7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14
7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 17 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 17
8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20
8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 21
8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24
8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 35 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 38 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 39
11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 39 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 40
11.3. CoJP Error Registry . . . . . . . . . . . . . . . . . . 39 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 41
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 44
Appendix B. Lightweight Implementation Option . . . . . . . . . 46 Appendix B. Lightweight Implementation Option . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document defines a "secure join" solution for a new device, This document defines a "secure join" solution for a new device,
called "pledge", to securely join a 6TiSCH network. The term "secure called "pledge", to securely join a 6TiSCH network. The term "secure
join" refers to network access authentication, authorization and join" refers to network access authentication, authorization and
parameter distribution, as defined in [I-D.ietf-6tisch-terminology]. parameter distribution, as defined in [I-D.ietf-6tisch-terminology].
The Constrained Join Protocol (CoJP) defined in this document handles The Constrained Join Protocol (CoJP) defined in this document handles
parameter distribution needed for a pledge to become a joined node. parameter distribution needed for a pledge to become a joined node.
Authorization mechanisms are considered out of scope. Mutual Authorization mechanisms are considered out of scope. Mutual
skipping to change at page 5, line 15 skipping to change at page 5, line 15
o join protocol o join protocol
o join process o join process
The following terms defined in [RFC6775] are also used throughout The following terms defined in [RFC6775] are also used throughout
this document: this document:
o 6LoWPAN Border Router (6LBR) o 6LoWPAN Border Router (6LBR)
o 6LoWPAN Node (6LN)
The term "6LBR" is used interchangeably with the term "DODAG root" The term "6LBR" is used interchangeably with the term "DODAG root"
defined in [RFC6550], assuming the two entities are co-located, as defined in [RFC6550], assuming the two entities are co-located, as
recommended by [I-D.ietf-6tisch-architecture]. recommended by [I-D.ietf-6tisch-architecture].
The term "pledge", as used throughout the document, explicitly The term "pledge", as used throughout the document, explicitly
denotes non-6LBR devices attempting to join the network using their denotes non-6LBR devices attempting to join the network using their
IEEE Std 802.15.4 network interface. The device that attempts to IEEE Std 802.15.4 network interface. The device that attempts to
join as the 6LBR of the network and does so over another network join as the 6LBR of the network and does so over another network
interface is explicitly denoted as the "6LBR pledge". When the text interface is explicitly denoted as the "6LBR pledge". When the text
equally applies to the pledge and the 6LBR pledge, the "(6LBR) equally applies to the pledge and the 6LBR pledge, the "(6LBR)
skipping to change at page 13, line 46 skipping to change at page 13, line 46
The CoAP proxy defined in [RFC7252] keeps per-client state The CoAP proxy defined in [RFC7252] keeps per-client state
information in order to forward the response towards the originator information in order to forward the response towards the originator
of the request. This state information includes at least the CoAP of the request. This state information includes at least the CoAP
token, the IPv6 address of the client, and the UDP source port token, the IPv6 address of the client, and the UDP source port
number. Since the JP can be a constrained device that acts as a CoAP number. Since the JP can be a constrained device that acts as a CoAP
proxy, memory limitations make it prone to a Denial-of-Service (DoS) proxy, memory limitations make it prone to a Denial-of-Service (DoS)
attack. attack.
This DoS vector on the JP can be mitigated by making the JP act as a This DoS vector on the JP can be mitigated by making the JP act as a
stateless CoAP proxy, where "state" refers to individual pledges. stateless CoAP proxy, where "state" encompasses the information
The JP can wrap the state it needs to keep for a given pledge related individual pledges. The JP can wrap the state it needs to
throughout the network stack in a "state object" and include it as a keep for a given pledge throughout the network stack in a "state
CoAP token in the forwarded request to the JRC. The JP may use the object" and include it as a CoAP token in the forwarded request to
CoAP token as defined in [RFC7252], if the size of the serialized the JRC. The JP may use the CoAP token as defined in [RFC7252], if
state object permits, or use the extended CoAP token defined in the size of the serialized state object permits, or use the extended
[I-D.hartke-core-stateless], to transport the state object. Since CoAP token defined in [I-D.ietf-core-stateless], to transport the
the CoAP token is echoed back in the response, the JP is able to state object. Since the CoAP token is echoed back in the response,
decode the state object and configure the state needed to forward the the JP is able to decode the state object and configure the state
response to the pledge. The information that the JP needs to encode needed to forward the response to the pledge. The information that
in the state object to operate in a fully stateless manner with the JP needs to encode in the state object to operate in a fully
respect to a given pledge is implementation specific. stateless manner with respect to a given pledge is implementation
specific.
It is RECOMMENDED that the JP operates in a stateless manner and It is RECOMMENDED that the JP operates in a stateless manner and
signals the per-pledge state within the CoAP token, for every request signals the per-pledge state within the CoAP token, for every request
it forwards into the network on behalf of unauthenticated pledges. it forwards into the network on behalf of unauthenticated pledges.
When operating in a stateless manner, the state object communicated When operating in a stateless manner, the security considerations
in the token MUST be integrity protected, potentially with a key that from [I-D.ietf-core-stateless] apply and the type of the CoAP message
is known only to the JP, MUST include a freshness indicator, and MAY
be encrypted. Security considerations from
[I-D.hartke-core-stateless] apply.
When operating in a stateless manner, the type of the CoAP message
that the JP forwards on behalf of the pledge MUST be non-confirmable that the JP forwards on behalf of the pledge MUST be non-confirmable
(NON), regardless of the message type received from the pledge. The (NON), regardless of the message type received from the pledge. The
use of a non-confirmable message by the JP alleviates the JP from use of a non-confirmable message by the JP alleviates the JP from
keeping CoAP message exchange state. The retransmission burden is keeping CoAP message exchange state. The retransmission burden is
then entirely shifted to the pledge. A JP that operates in a then entirely shifted to the pledge. A JP that operates in a
stateless manner still needs to keep congestion control state with stateless manner still needs to keep congestion control state with
the JRC, see Section 9. Recommended values of CoAP settings for use the JRC, see Section 9. Recommended values of CoAP settings for use
during the join process, both by the pledge and the JP, are given in during the join process, both by the pledge and the JP, are given in
Section 7.2. Section 7.2.
Note that in some networking stack implementations, a fully (per- Note that in some networking stack implementations, a fully (per-
pledge) stateless operation of the JP may be challenging from the pledge) stateless operation of the JP may be challenging from the
implementation's point of view. In those cases, the JP may operate implementation's point of view. In those cases, the JP may operate
as a statefull proxy that stores the per-pledge state until the as a statefull proxy that stores the per-pledge state until the
response is received or timed out, but this comes at a price of an response is received or timed out, but this comes at a price of a DoS
additional DoS vector. vector.
7.2. Recommended Settings 7.2. Recommended Settings
This section gives RECOMMENDED values of CoAP settings during the This section gives RECOMMENDED values of CoAP settings during the
join process. join process.
+-------------------+-----------------------+-------------------+ +-------------------+-----------------------+-------------------+
| Name | Default Value: Pledge | Default Value: JP | | Name | Default Value: Pledge | Default Value: JP |
+-------------------+-----------------------+-------------------+ +-------------------+-----------------------+-------------------+
| ACK_TIMEOUT | 10 seconds | (10 seconds) | | ACK_TIMEOUT | 10 seconds | (10 seconds) |
skipping to change at page 16, line 13 skipping to change at page 15, line 48
initially acts as a CoAP server. initially acts as a CoAP server.
o the Algorithm MUST be set to the value from [RFC8152], agreed out- o the Algorithm MUST be set to the value from [RFC8152], agreed out-
of-band by the same mechanism used to provision the PSK. The of-band by the same mechanism used to provision the PSK. The
default is AES-CCM-16-64-128. default is AES-CCM-16-64-128.
o the Key Derivation Function MUST be agreed out-of-band by the same o the Key Derivation Function MUST be agreed out-of-band by the same
mechanism used to provision the PSK. Default is HKDF SHA-256 mechanism used to provision the PSK. Default is HKDF SHA-256
[RFC5869]. [RFC5869].
Since the pledge's OSCORE ID is the empty byte string, when Since the pledge's OSCORE Sender ID is the empty byte string, when
constructing the OSCORE option, the pledge sets the k bit in the constructing the OSCORE option, the pledge sets the k bit in the
OSCORE flag byte, but indicates a 0-length kid. The pledge OSCORE flag byte, but indicates a 0-length kid. The pledge
transports its pledge identifier within the kid context field of the transports its pledge identifier within the kid context field of the
OSCORE option. The derivation in [I-D.ietf-core-object-security] OSCORE option. The derivation in [I-D.ietf-core-object-security]
results in OSCORE keys and a common IV for each side of the results in OSCORE keys and a common IV for each side of the
conversation. Nonces are constructed by XOR'ing the common IV with conversation. Nonces are constructed by XOR'ing the common IV with
the current sequence number. For details on nonce and OSCORE option the current sequence number. For details on nonce and OSCORE option
construction, refer to [I-D.ietf-core-object-security]. construction, refer to [I-D.ietf-core-object-security].
Implementations MUST ensure that multiple CoAP requests to different Implementations MUST ensure that multiple CoAP requests, including to
JRCs are properly incrementing the sequence numbers in the OSCORE different JRCs, are properly incrementing the sequence numbers, so
security context for each message, so that the same sequence number that the same sequence number is never reused in distinct requests.
is never reused in distinct requests. The pledge typically sends The pledge typically sends requests to different JRCs if it is not
requests to different JRCs if it is not provisioned with the network provisioned with the network identifier and attempts to join one
identifier and attempts to join one network at a time. A simple network at a time. Failure to comply will break the security
implementation technique is to instantiate the OSCORE security guarantees of the Authenticated Encryption with Associated Data
context with a given PSK only once and use it for all subsequent (AEAD) algorithm because of nonce reuse.
requests. Failure to comply will break the security guarantees of
the Authenticated Encryption with Associated Data (AEAD) algorithm
because of nonce reuse.
This OSCORE security context is used for initial joining of the This OSCORE security context is used for initial joining of the
(6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well
as for any later parameter updates, where the JRC acts as a CoAP as for any later parameter updates, where the JRC acts as a CoAP
client and the joined node as a CoAP server, as discussed in client and the joined node as a CoAP server, as discussed in
Section 8.2. The (6LBR) pledge and the JRC use the OSCORE security Section 8.2. Note that when the (6LBR) pledge and the JRC change
context parameters (e.g. sender and recipient identifiers) as they roles between CoAP client and CoAP server, the same OSCORE security
were used at the moment of context derivation, regardless of whether context as initially derived remains in use and the derived
they currently act as a CoAP client or a CoAP server. A (6LBR) parameters are unchanged, for example Sender ID when sending and
pledge is expected to have exactly one OSCORE security context with Recipient ID when receiving (see Section 3.1 of
the JRC. [I-D.ietf-core-object-security]). A (6LBR) pledge is expected to
have exactly one OSCORE security context with the JRC.
7.3.1. Replay Window and Persistency 7.3.1. Replay Window and Persistency
Both (6LBR) pledge and the JRC MUST implement a replay protection Both (6LBR) pledge and the JRC MUST implement a replay protection
mechanism. The use of the default OSCORE replay protection mechanism mechanism. The use of the default OSCORE replay protection mechanism
specified in Section 3.2.2 of [I-D.ietf-core-object-security] is specified in Section 3.2.2 of [I-D.ietf-core-object-security] is
RECOMMENDED. RECOMMENDED.
Implementations MUST ensure that mutable OSCORE context parameters Implementations MUST ensure that mutable OSCORE context parameters
(Sender Sequence Number, Replay Window) are stored in persistent (Sender Sequence Number, Replay Window) are stored in persistent
memory. A technique that prevents reuse of sequence numbers, memory. A technique that prevents reuse of sequence numbers,
detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be detailed in Appendix B.1.1 of [I-D.ietf-core-object-security], MUST
implemented. Each update of the OSCORE Replay Window MUST be written be implemented. Each update of the OSCORE Replay Window MUST be
to persistent memory. written to persistent memory.
This is an important security requirement in order to guarantee nonce This is an important security requirement in order to guarantee nonce
uniqueness and resistance to replay attacks across reboots and uniqueness and resistance to replay attacks across reboots and
rejoins. Traffic between the (6LBR) pledge and the JRC is rare, rejoins. Traffic between the (6LBR) pledge and the JRC is rare,
making security outweigh the cost of writing to persistent memory. making security outweigh the cost of writing to persistent memory.
7.3.2. OSCORE Error Handling 7.3.2. OSCORE Error Handling
Errors raised by OSCORE during the join process MUST be silently Errors raised by OSCORE during the join process MUST be silently
dropped, with no error response being signaled. The pledge MUST dropped, with no error response being signaled. The pledge MUST
skipping to change at page 22, line 9 skipping to change at page 21, line 39
the JRC SHALL be mapped to a CoAP response: the JRC SHALL be mapped to a CoAP response:
o The response Code is 2.04 (Changed). o The response Code is 2.04 (Changed).
o The payload is empty. o The payload is empty.
8.3. Error Handling 8.3. Error Handling
8.3.1. CoJP CBOR Object Processing 8.3.1. CoJP CBOR Object Processing
This section describes error handling when processing CoJP CBOR
objects that are transported within the payload of different CoJP
messages. See Section 7.3.2 for the handling of errors that may be
raised by the underlying OSCORE implementation.
CoJP CBOR objects are transported within both CoAP requests and CoJP CBOR objects are transported within both CoAP requests and
responses. When an error is detected while processing CoJP objects responses. This section describes handling in case certain CoJP CBOR
in a CoAP request (Join Request message, Parameter Update message), object parameters are not supported by the implementation or their
an Error Response message MUST be returned. An Error Response processing fails. See Section 7.3.2 for the handling of errors that
message maps to a CoAP response and is specified in Section 8.3.2. may be raised by the underlying OSCORE implementation.
When an error is detected while processing a CoJP object in a CoAP When such a parameter is detected in a CoAP request (Join Request
response (Join Response message), a (6LBR) pledge SHOULD reattempt to message, Parameter Update message), a Diagnostic Response message
join. In this case, the (6LBR) pledge SHOULD include the Error CBOR MUST be returned. A Diagnostic Response message maps to a CoAP
object within the Join Request object in the following Join Request response and is specified in Section 8.3.2.
message. A (6LBR) pledge MUST NOT attempt more than MAX_RETRANSMIT
number of attempts to join if the processing of the Join Response
message fails each time. If COJP_MAX_JOIN_ATTEMPTS number of
attempts is reached without success, the (6LBR) pledge SHOULD signal
to the user the presence of an error condition, through some out-of-
band mechanism.
8.3.2. Error Response Message When a parameter that cannot be acted upon is encountered while
processing a CoJP object in a CoAP response (Join Response message),
a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR)
pledge SHOULD include the Unsupported Configuration CBOR object
within the Join Request object in the following Join Request message.
The Unsupported Configuration CBOR object is self-contained and
enables the (6LBR) pledge to signal any parameters that the
implementation of the networking stack may not support. A (6LBR)
pledge MUST NOT attempt more than MAX_RETRANSMIT number of attempts
to join if the processing of the Join Response message fails each
time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached
without success, the (6LBR) pledge SHOULD signal to the user the
presence of an error condition, through some out-of-band mechanism.
The Error Response Message is returned for any CoJP request when the 8.3.2. Diagnostic Response Message
processing of the payload failed. The Error Response message is
protected by OSCORE as any other CoJP protocol message.
The Error Response message SHALL be mapped to a CoAP response: The Diagnostic Response message is returned for any CoJP request when
the processing of the payload failed. The Diagnostic Response
message is protected by OSCORE as any other CoJP protocol message.
The Diagnostic Response message SHALL be mapped to a CoAP response:
o The response Code is 4.00 (Bad Request). o The response Code is 4.00 (Bad Request).
o The payload is an Error CBOR object, as defined in Section 8.4.5, o The payload is an Unsupported Configuration CBOR object, as
containing the error code that triggered the sending of this defined in Section 8.4.5, containing more information about the
message. parameter that triggered the sending of this message.
8.3.3. Failure Handling 8.3.3. Failure Handling
The Parameter Update exchange may be triggered at any time during the The Parameter Update exchange may be triggered at any time during the
network lifetime, which may span several years. During this period, network lifetime, which may span several years. During this period,
it may occur that a joined node or the JRC experience unexpected it may occur that a joined node or the JRC experience unexpected
events such as reboots or complete failures. events such as reboots or complete failures.
This document mandates that the mutable parameters in the security This document mandates that the mutable parameters in the security
context are written to persistent memory (see Section 7.3.1) by both context are written to persistent memory (see Section 7.3.1) by both
the JRC and pledges (joined nodes). In case of a reboot on either the JRC and pledges (joined nodes). As the joined node (pledge) is
side, the retrieval of mutable security context parameters is typically a constrained device that handles the write operations to
feasible from the persistent memory such that there is no risk of persistent memory in a predictable manner, the retrieval of mutable
AEAD nonce reuse due to a reinitialized Sender Sequence number, or of security context parameters is feasible across reboots such that
a replay attack due to the reinitialized replay window. there is no risk of AEAD nonce reuse due to reinitialized Sender
Sequence numbers, or of a replay attack due to the reinitialized
replay window. JRC may be hosted on a generic machine where the
write operation to persistent memory may lead to unpredictable delays
due to caching. In case of a reboot event at JRC occurring before
the cached data is written to persistent memory, the loss of mutable
security context parameters is likely which consequently poses the
risk of AEAD nonce reuse.
In the case of a complete failure, where the mutable security context In the event of a complete device failure, where the mutable security
parameters cannot be retrieved, it is expected that a failed joined context parameters cannot be retrieved, it is expected that a failed
node is replaced with a new physical device, using a new pledge joined node is replaced with a new physical device, using a new
identifier and a PSK. When such an event occurs at the JRC, it is pledge identifier and a PSK. When such a failure event occurs at the
likely that the information about joined nodes, their assigned short JRC, it is possible that the static information on provisioned
identifiers and mutable security context parameters is lost. If this pledges, like PSKs and pledge identifiers, can be retrieved through
is the case, during the process of JRC replacement, the network available backups. However, it is likely that the information about
administrator MUST force all the networks managed by the failed JRC joined nodes, their assigned short identifiers and mutable security
to rejoin, through e.g. the reinitialization of the 6LBR nodes. context parameters is lost. If this is the case, during the process
Since the joined nodes kept track of their mutable security context of JRC reinitialization, the network administrator MUST force through
parameters, they will use these during the (re)join exchange without out-of-band means all the networks managed by the failed JRC to
a risk of AEAD nonce reuse. However, even after all the nodes rejoin, through e.g. the reinitialization of the 6LBR nodes and
rejoined, the AEAD nonce reuse risk exists during the first Parameter freshly generated dynamic cryptographic keys and other parameters
Update exchange, as the new JRC does not possess the last Sender that have influence on the security properties of the network.
Sequence number used, and can only initialize it to zero. Since the
sending of this first Parameter Update message by the new JRC results
in AEAD nonce reuse, the JRC MUST set the payload to a randomly
generated byte string, at least 40 bytes long.
When such a message arrives at the joined node, the OSCORE In order to recover from such a failure event, the reinitialized JRC
implementation rejects it due to the Partial IV being largely below can trigger the renegotiation of the OSCORE security context through
the acceptable replay window state and does not process the payload. the procedure described in Appendix B.2 of
When this is detected, the joined node MUST send a 4.01 Unauthorized [I-D.ietf-core-object-security]. Aware of the failure event, the
response, as per Section 7.4 of [I-D.ietf-core-object-security]. The reinitialized JRC responds to the first join request of each pledge
payload of the response MUST be the Error object specified in it is managing with a 4.01 Unauthorized error and a random nonce.
Section 8.4.5, with error code set to "Significant OSCORE partial IV The pledge verifies the error response and then initiates the CoJP
mismatch" from Table 4 and Additional information set to the next join exchange using a new OSCORE security context derived from an ID
Partial IV the joined node will expect. When protecting this error Context consisting of the concatenation of two nonces, one that it
response by OSCORE, the joined node MUST use its Sender Sequence received from the JRC and the other that the pledge generates
number to generate a new nonce and include the corresponding Partial locally. After verifying the join request with the new ID Context
IV in the CoAP OSCORE option, as detailed in Section 8.3 of and the derived OSCORE security context, the JRC should consequently
[I-D.ietf-core-object-security]. Upon successful OSCORE verification take action in mapping the new ID Context with the previously used
of the received CoJP message, the JRC processes the error response pledge identifier. How JRC handles this mapping is implementation
and configures the Sender Sequence number to the one indicated in the specific.
Additional information field. The next Parameter Update exchange
triggered by the JRC will therefore use the proper Sender Sequence The described procedure is specified in Appendix B.2 of
number and will be accepted by the joined node. [I-D.ietf-core-object-security] and is RECOMMENDED in order to handle
the failure events or any other event that may lead to the loss of
mutable security context parameters. The length of nonces exchanged
using this procedure SHOULD be at least 8 bytes.
The procedure does require both the pledge and the JRC to have good
sources of randomness. While this is typically not an issue at the
JRC side, the constrained device hosting the pledge may pose
limitations in this regard. If the procedure outlined in
Appendix B.2 of [I-D.ietf-core-object-security] is not supported by
the pledge, the network administrator MUST take action in
reprovisioning the concerned devices with freshly generated
parameters, through out-of-band means.
8.4. CoJP Objects 8.4. CoJP Objects
This section specifies the structure of CoJP CBOR objects that may be This section specifies the structure of CoJP CBOR objects that may be
carried as the payload of CoJP messages. Some of these objects may carried as the payload of CoJP messages. Some of these objects may
be received both as part of the CoJP join exchange when the device be received both as part of the CoJP join exchange when the device
operates as a (CoJP) pledge, or the parameter update exchange, when operates as a (CoJP) pledge, or the parameter update exchange, when
the device operates as a joined (6LBR) node. the device operates as a joined (6LBR) node.
8.4.1. Join Request Object 8.4.1. Join Request Object
skipping to change at page 24, line 35 skipping to change at page 24, line 35
0, i.e. the role "6TiSCH Node", MUST be assumed. 0, i.e. the role "6TiSCH Node", MUST be assumed.
o network identifier: The identifier of the network, as discussed in o network identifier: The identifier of the network, as discussed in
Section 3, encoded as a CBOR byte string. When present in the Section 3, encoded as a CBOR byte string. When present in the
Join_Request, it hints to the JRC the network that the pledge is Join_Request, it hints to the JRC the network that the pledge is
requesting to join, enabling the JRC to manage multiple networks. requesting to join, enabling the JRC to manage multiple networks.
The pledge obtains the value of the network identifier from the The pledge obtains the value of the network identifier from the
received EB frames. This parameter MUST be included in a received EB frames. This parameter MUST be included in a
Join_Request object regardless of the role parameter value. Join_Request object regardless of the role parameter value.
o response processing error: The identifier of the error from the o unsupported configuration: The identifier of the parameters that
previous join attempt, encoded as an Error object described in are not supported by the implementation, encoded as an
Section 8.4.5. This parameter MAY be included. If a (6LBR) Unsupported_Configuration object described in Section 8.4.5. This
pledge previously attempted to join and received a valid Join parameter MAY be included. If a (6LBR) pledge previously
Response message over OSCORE, but failed to process its payload attempted to join and received a valid Join Response message over
(Configuration object), it SHOULD include this parameter to OSCORE, but failed to act on its payload (Configuration object),
facilitate the debugging process. it SHOULD include this parameter to facilitate the recovery and
debugging.
The CDDL fragment that represents the text above for the Join_Request The CDDL fragment that represents the text above for the Join_Request
follows. follows.
Join_Request = { Join_Request = {
? 1 : uint, ; role ? 1 : uint, ; role
? 5 : bstr, ; network identifier ? 5 : bstr, ; network identifier
? 8 : Error, ; response processing error ? 8 : Unsupported_Configuration ; unsupported configuration
} }
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| Name | Value | Description | Reference | | Name | Value | Description | Reference |
+--------+-------+-------------------------------------+------------+ +--------+-------+-------------------------------------+------------+
| 6TiSCH | 0 | The pledge requests to play the | [[this | | 6TiSCH | 0 | The pledge requests to play the | [[this |
| Node | | role of a regular 6TiSCH node, i.e. | document]] | | Node | | role of a regular 6TiSCH node, i.e. | document]] |
| | | non-6LBR node. | | | | | non-6LBR node. | |
| | | | | | | | | |
| 6LBR | 1 | The pledge requests to play the | [[this | | 6LBR | 1 | The pledge requests to play the | [[this |
| | | role of 6LoWPAN Border Router | document]] | | | | role of 6LoWPAN Border Router | document]] |
skipping to change at page 25, line 31 skipping to change at page 25, line 31
of parameters that can appear in a Configuration object is summarized of parameters that can appear in a Configuration object is summarized
below. The labels can be found in "CoJP Parameters" registry below. The labels can be found in "CoJP Parameters" registry
Section 11.1. Section 11.1.
o link-layer key set: An array encompassing a set of cryptographic o link-layer key set: An array encompassing a set of cryptographic
keys and their identifiers that are currently in use in the keys and their identifiers that are currently in use in the
network, or that are scheduled to be used in the future. The network, or that are scheduled to be used in the future. The
encoding of individual keys is described in Section 8.4.3. The encoding of individual keys is described in Section 8.4.3. The
link-layer key set parameter MAY be included in a Configuration link-layer key set parameter MAY be included in a Configuration
object. When present, the link-layer key set parameter MUST object. When present, the link-layer key set parameter MUST
contain at least one key. How the keys are installed and used contain at least one key. When a pledge is joining for the first
differs for the 6LBR and other nodes. When 6LBR receives this time and receives this parameter, before sending the first
parameter, it MUST immediately install and start using the new outgoing frame secured with a received key, the pledge needs to
keys for all outgoing traffic, and remove any old keys it has
installed from the previous key set after a delay of
COJP_REKEYING_GUARD_TIME has passed. When a non-6LBR node
receives this parameter, it MUST install the keys, use them for
any incoming traffic matching the key identifier, but keep using
the old keys for all outgoing traffic. 6LBR and non-6LBR nodes
accept any frame for which they have keys: both old and new keys.
Upon reception and successful security processing of a link-layer
frame secured with a key from the new key set, a non-6LBR node
MUST start using the keys from the new set for all outgoing
traffic. A non-6LBR node MUST remove any old keys it has
installed from the previous key set after a delay of
COJP_REKEYING_GUARD_TIME has passed. In the case when the pledge
is joining for the first time, before sending the first outgoing
frame secured with a received key, the pledge needs to
successfully complete the security processing of an incoming successfully complete the security processing of an incoming
frame. To do so, the pledge can wait to receive a new frame, or frame. To do so, the pledge can wait to receive a new frame, or
it can store an EB frame that it used to find the JP and use it it can store an EB frame that it used to find the JP and use it
for immediate security processing upon reception of the key set. for immediate security processing upon reception of the key set.
The described mechanism permits the JRC to provision the new key This parameter is also used to implement rekeying in the network.
set to all the nodes while the network continues to use the How the keys are installed and used differs for the 6LBR and other
existing keys. When the JRC is certain that all (or enough) nodes (regular) nodes, and this is explained in Section 8.4.3.1 and
have been provisioned with the new keys, then the JRC updates the Section 8.4.3.2.
6LBR. In the special case when the JRC is co-located with the
6LBR, it can simply trigger the sending of a new broadcast frame
(e.g. EB), secured with a key from the new key set. The frame
goes out with the new key, and upon reception and successful
security processing of the new frame all receiving nodes will
switch to the new active keys. Outgoing traffic from those nodes
will then use the new key, which causes an update of additional
peers, and the network will switch over in a flood-fill fashion.
o short identifier: a compact identifier assigned to the pledge. o short identifier: a compact identifier assigned to the pledge.
The short identifier structure is described in Section 8.4.4. The The short identifier structure is described in Section 8.4.4. The
short identifier parameter MAY be included in a Configuration short identifier parameter MAY be included in a Configuration
object. object.
o JRC address: the IPv6 address of the JRC, encoded as a byte o JRC address: the IPv6 address of the JRC, encoded as a byte
string, with the length of 16 bytes. If the length of the byte string, with the length of 16 bytes. If the length of the byte
string is different from 16, the parameter MUST be discarded. If string is different from 16, the parameter MUST be discarded. If
the JRC is not co-located with the 6LBR and has a different IPv6 the JRC is not co-located with the 6LBR and has a different IPv6
skipping to change at page 28, line 4 skipping to change at page 28, line 4
Configuration follows. Structures Link_Layer_Key and Configuration follows. Structures Link_Layer_Key and
Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. Short_Identifier are specified in Section 8.4.3 and Section 8.4.4.
Configuration = { Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Identifier, ; short identifier ? 3 : Short_Identifier, ; short identifier
? 4 : bstr, ; JRC address ? 4 : bstr, ; JRC address
? 6 : [ *bstr ], ; blacklist ? 6 : [ *bstr ], ; blacklist
? 7 : uint ; join rate ? 7 : uint ; join rate
} }
+------------+-------+----------+----------------------+------------+ +---------------+-------+----------+-------------------+------------+
| Name | Label | CBOR | Description | Reference | | Name | Label | CBOR | Description | Reference |
| | | type | | | | | | type | | |
+------------+-------+----------+----------------------+------------+ +---------------+-------+----------+-------------------+------------+
| role | 1 | unsigned | Identifies the role | [[this | | role | 1 | unsigned | Identifies the | [[this |
| | | integer | parameter | document]] | | | | integer | role parameter | document]] |
| | | | | | | | | | | |
| link-layer | 2 | array | Identifies the array | [[this | | link-layer | 2 | array | Identifies the | [[this |
| key set | | | carrying one or more | document]] | | key set | | | array carrying | document]] |
| | | | link-level | | | | | | one or more link- | |
| | | | cryptographic keys | | | | | | level | |
| | | | | | | | | | cryptographic | |
| short | 3 | array | Identifies the | [[this | | | | | keys | |
| identifier | | | assigned short | document]] | | | | | | |
| | | | identifier | | | short | 3 | array | Identifies the | [[this |
| | | | | | | identifier | | | assigned short | document]] |
| JRC | 4 | byte | Identifies the IPv6 | [[this | | | | | identifier | |
| address | | string | address of the JRC | document]] | | | | | | |
| | | | | | | JRC address | 4 | byte | Identifies the | [[this |
| network | 5 | byte | Identifies the | [[this | | | | string | IPv6 address of | document]] |
| identifier | | string | network identifier | document]] | | | | | the JRC | |
| | | | parameter | | | | | | | |
| | | | | | | network | 5 | byte | Identifies the | [[this |
| blacklist | 6 | array | Identifies the | [[this | | identifier | | string | network | document]] |
| | | | blacklist parameter | document]] | | | | | identifier | |
| | | | | | | | | | parameter | |
| join rate | 7 | unsigned | Identifier the join | [[this | | | | | | |
| | | integer | rate parameter | document]] | | blacklist | 6 | array | Identifies the | [[this |
| | | | | | | | | | blacklist | document]] |
| error | 8 | array | Identifies the error | [[this | | | | | parameter | |
| | | | parameter | document]] | | | | | | |
+------------+-------+----------+----------------------+------------+ | join rate | 7 | unsigned | Identifier the | [[this |
| | | integer | join rate | document]] |
| | | | parameter | |
| | | | | |
| unsupported | 8 | array | Identifies the | [[this |
| configuration | | | unsupported | document]] |
| | | | configuration | |
| | | | parameter | |
+---------------+-------+----------+-------------------+------------+
Table 2: CoJP parameters map labels. Table 2: CoJP parameters map labels.
8.4.3. Link-Layer Key 8.4.3. Link-Layer Key
The Link_Layer_Key structure encompasses the parameters needed to The Link_Layer_Key structure encompasses the parameters needed to
configure the link-layer security module: the key identifier; the configure the link-layer security module: the key identifier; the
value of the cryptographic key; the link-layer algorithm identifier value of the cryptographic key; the link-layer algorithm identifier
and the security level and the frame types that it should be used and the security level and the frame types that it should be used
with, both for outgoing and incoming security operations; and any with, both for outgoing and incoming security operations; and any
skipping to change at page 31, line 44 skipping to change at page 32, line 4
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
| | | | | | | | | | | |
| 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d |
| MIC128 | | CCM-128 | MIC-128 for | ocument] | | MIC128 | | CCM-128 | MIC-128 for | ocument] |
| | | | DATA and AC | ] | | | | | DATA and AC | ] |
| | | | KNOWLEDGMEN | | | | | | KNOWLEDGMEN | |
| | | | T. | | | | | | T. | |
+-----------------+-----+------------------+-------------+----------+ +-----------------+-----+------------------+-------------+----------+
Table 3: Key Usage values. Table 3: Key Usage values.
8.4.3.1. Use in IEEE Std 802.15.4 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR)
When the 6LoWPAN Border Router (6LBR) receives the Configuration
object containing a link-layer key set, it MUST immediately install
and start using the new keys for all outgoing traffic, and remove any
old keys it has installed from the previous key set after a delay of
COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the
JRC to force the 6LBR to start sending traffic with the new key. The
decision is taken by the JRC when it has determined that the new key
has been made available to all (or some overwhelming majority) of
nodes. Any node that the JRC has not yet reached at that point is
either non-functional or in extended sleep such that it will not be
reached. To get the key update, such node needs to go through the
join process anew.
8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN)
When a regular 6LN node receives the Configuration object with a
link-layer key set, it MUST install the new keys. The 6LN will use
both the old and the new keys to decrypt and authenticate any
incoming traffic that arrives based upon the key identifier in the
packet. It MUST continue to use the old keys for all outgoing
traffic until it has detected that the network has switched to the
new key set.
The detection of network switch is based upon the receipt of traffic
secured with the new keys. Upon reception and successful security
processing of a link-layer frame secured with a key from the new key
set, a 6LN node MUST then switch to sending outgoing traffic using
the keys from the new set for all outgoing traffic. The 6LN node
MUST remove any old keys it has installed from the previous key set
after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts
using the new key set.
Sending of traffic with the new keys signals to other downstream
nodes to switch to their new key, and the affect is that there is a
ripple of key updates in outward concentric circles around each 6LBR.
8.4.3.3. Use in IEEE Std 802.15.4
When Link_Layer_Key is used in the context of [IEEE802.15.4], the When Link_Layer_Key is used in the context of [IEEE802.15.4], the
following considerations apply. following considerations apply.
Signaling of different keying modes of [IEEE802.15.4] is done based Signaling of different keying modes of [IEEE802.15.4] is done based
on the parameter values present in a Link_Layer_Key object. on the parameter values present in a Link_Layer_Key object.
o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be
set to 0. key_addinfo parameter MUST be present. key_addinfo set to 0. key_addinfo parameter MUST be present. key_addinfo
parameter MUST be set to the link-layer address(es) of a single parameter MUST be set to the link-layer address(es) of a single
skipping to change at page 34, line 26 skipping to change at page 35, line 26
short identifiers being used under the same link-layer key. If the short identifiers being used under the same link-layer key. If the
lease_time parameter of a given Short_Identifier object is set to lease_time parameter of a given Short_Identifier object is set to
positive infinity, care needs to be taken that the corresponding positive infinity, care needs to be taken that the corresponding
identifier is not assigned to another node until the JRC is certain identifier is not assigned to another node until the JRC is certain
that it is no longer in use, potentially through out-of-band that it is no longer in use, potentially through out-of-band
signaling. If the lease_time parameter expires for any reason, the signaling. If the lease_time parameter expires for any reason, the
JRC should take into consideration potential ongoing transmissions by JRC should take into consideration potential ongoing transmissions by
the joined node, which may be hanging in the queues, before assigning the joined node, which may be hanging in the queues, before assigning
the same identifier to another node. the same identifier to another node.
8.4.5. Error Object 8.4.5. Unsupported Configuration Object
The Error object is encoded as a CBOR array object, containing in The Unsupported_Configuration object is encoded as a CBOR array,
order: containing at least one Unsupported_Parameter object. Each
Unsupported_Parameter object is a sequence of CBOR elements without
an enclosing top-level CBOR object for compactness. The set of
parameters that appear in an Unsupported_Parameter object is
summarized below, in order:
o error_code: Error code for the first encountered error while o code: Indicates the capability of acting on the parameter signaled
processing a CoJP object, encoded as an integer. This parameter by parameter_label, encoded as an integer. This parameter MUST be
MUST be included. Possible values of this parameter are specified included. Possible values of this parameter are specified in the
in the IANA "CoJP Error Registry" (Section 11.3). IANA "CoJP Unsupported Configuration Code Registry"
(Section 11.3).
o error_addinfo: Additional information relevant to the error. This o parameter_label: Indicates the parameter. This parameter MUST be
parameter MUST be included. This parameter MUST be set as included. Possible values of this parameter are specified in the
described by the "Additional info" column of the "CoJP Error label column of the IANA "CoJP Parameters" registry
Registry" (Section 11.3). (Section 11.1).
o error_description: Human-readable description of the error, o parameter_addinfo: Additional information about the parameter that
encoded as a text string. This parameter MAY be included. The cannot be acted upon. This parameter MUST be included. In case
RECOMMENDED setting of this parameter is the "Description" column the code is set to "Unsupported", parameter_addinfo gives
of the "CoJP Error Registry" Section 11.3). additional information to the JRC. If the parameter indicated by
parameter_label cannot be acted upon regardless of its value,
parameter_addinfo MUST be set to null, signaling to the JRC that
it SHOULD NOT attempt to configure the parameter again. If the
pledge can act on the parameter, but cannot configure the setting
indicated by the parameter value, the pledge can hint this to the
JRC. In this case, parameter_addinfo MUST be set to the value of
the parameter that cannot be acted upon following the normative
parameter structure specified in this document. For example, it
is possible to include only a subset of the link-layer key set
object, signaling the keys that cannot be acted upon, or the
entire key set that was received. In case the code is set to
"Malformed", parameter_addinfo MUST be set to null, signaling to
the JRC that it SHOULD NOT attempt to configure the parameter
again.
The CDDL fragment that represents the text above for the Error object The CDDL fragment that represents the text above for
follows. Unsupported_Configuration and Unsupported_Parameter objects follows.
Error = [ Unsupported_Configuration = [
error_code : int, + parameter : Unsupported_Parameter
error_addinfo : int / bstr / tstr / nil,
? error_description : tstr,
] ]
+-----------------+-------+---------------+------------+------------+ Unsupported_Parameter = (
| Description | Value | Additional | Additional | Reference | code : int,
| | | info | info type | | parameter_label : int,
+-----------------+-------+---------------+------------+------------+ parameter_addinfo : nil / any
| Invalid | 0 | None | nil | [[this | )
| Join_Request | | | | document]] |
| object | | | | |
| | | | | |
| Invalid | 1 | None | nil | [[this |
| Configuration | | | | document]] |
| object | | | | |
| | | | | |
| Invalid | 2 | Label of the | int | [[this |
| parameter | | invalid | | document]] |
| | | parameter | | |
| | | | | |
| Invalid link- | 3 | Index of the | uint | [[this |
| layer key | | invalid key | | document]] |
| | | | | |
| Significant | 4 | Next | bstr | [[this |
| OSCORE partial | | acceptable | | document]] |
| IV mismatch | | OSCORE | | |
| | | partial IV | | |
+-----------------+-------+---------------+------------+------------+
Table 4: CoJP error codes. +-------------+-------+--------------------------------+------------+
| Name | Value | Description | Reference |
+-------------+-------+--------------------------------+------------+
| Unsupported | 0 | The indicated setting is not | [[this |
| | | supported by the networking | document]] |
| | | stack implementation. | |
| | | | |
| Malformed | 1 | The indicated parameter value | [[this |
| | | is malformed. | document]] |
+-------------+-------+--------------------------------+------------+
Table 4: Unsupported Configuration code values.
8.5. Recommended Settings 8.5. Recommended Settings
This section gives RECOMMENDED values of CoJP settings discussed in This section gives RECOMMENDED values of CoJP settings.
this section.
+--------------------------+---------------+ +--------------------------+---------------+
| Name | Default Value | | Name | Default Value |
+--------------------------+---------------+ +--------------------------+---------------+
| COJP_MAX_JOIN_ATTEMPTS | 4 | | COJP_MAX_JOIN_ATTEMPTS | 4 |
| | | | | |
| COJP_REKEYING_GUARD_TIME | 12 seconds | | COJP_REKEYING_GUARD_TIME | 12 seconds |
+--------------------------+---------------+ +--------------------------+---------------+
Recommended CoJP settings. Recommended CoJP settings.
skipping to change at page 39, line 41 skipping to change at page 41, line 5
This registry is to be populated with the values in Table 3. This registry is to be populated with the values in Table 3.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
11.3. CoJP Error Registry 11.3. CoJP Unsupported Configuration Code Registry
This section defines a sub-registries within the "IPv6 over the TSCH This section defines a sub-registries within the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
"Constrained Join Protocol Error Registry". "Constrained Join Protocol Unsupported Configuration Code Registry".
The columns of this registry are: The columns of this registry are:
Description: This is a descriptive human-readable name. The Name: This is a descriptive name that enables easier reference to the
description MUST be unique. It is not used in the encoding. item. The name MUST be unique. It is not used in the encoding.
Value: This is the value used to identify the error. These values
MUST be unique. The value is an integer.
Additional information: This is a descriptive name of additional Value: This is the value used to identify the diagnostic code. These
information that is meaningful for the error. The name is not used values MUST be unique. The value is an integer.
in the encoding.
Additional information type: A CBOR type of the additional Description: This is a descriptive human-readable name. The
information field. description MUST be unique. It is not used in the encoding.
Reference: This contains a pointer to the public specification for Reference: This contains a pointer to the public specification for
the field, if one exists. the field, if one exists.
This registry is to be populated with the values in Table 4. This registry is to be populated with the values in Table 4.
The amending formula for this sub-registry is: Different ranges of The amending formula for this sub-registry is: Different ranges of
values use different registration policies [RFC8126]. Integer values values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer values from -256 to 255 are designated as Standards Action. Integer values
from -65536 to -257 and from 256 to 65535 are designated as from -65536 to -257 and from 256 to 65535 are designated as
skipping to change at page 40, line 37 skipping to change at page 41, line 44
12. Acknowledgments 12. Acknowledgments
The work on this document has been partially supported by the The work on this document has been partially supported by the
European Union's H2020 Programme for research, technological European Union's H2020 Programme for research, technological
development and demonstration under grant agreements: No 644852, development and demonstration under grant agreements: No 644852,
project ARMOUR; No 687884, project F-Interop and open-call project project ARMOUR; No 687884, project F-Interop and open-call project
SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA.
The following individuals provided input to this document (in The following individuals provided input to this document (in
alphabetic order): Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke,
Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal
Vignat, Xavier Vilajosana, Thomas Watteyne. Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>. <https://www.rfc-editor.org/info/rfc2597>.
skipping to change at page 41, line 44 skipping to change at page 43, line 7
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.hartke-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-hartke-
core-stateless-02 (work in progress), October 2018.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work
in progress), October 2018. in progress), March 2019.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-06 (work in progress), November 2018. cddl-08 (work in progress), March 2019.
[I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-ietf-core-
stateless-01 (work in progress), March 2019.
[IEEE802.15.4] [IEEE802.15.4]
IEEE standard for Information Technology, ., "IEEE Std IEEE standard for Information Technology, ., "IEEE Std
802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 802.15.4 Standard for Low-Rate Wireless Networks", n.d..
[NIST800-90A] [NIST800-90A]
NIST Special Publication 800-90A, Revision 1, ., Barker, NIST Special Publication 800-90A, Revision 1, ., Barker,
E., and J. Kelsey, "Recommendation for Random Number E., and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators", Generation Using Deterministic Random Bit Generators",
2015. 2015.
 End of changes. 53 change blocks. 
278 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/