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