Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9031.
|
|
|---|---|---|---|
| Authors | Mališa Vučinić , Jonathan Simon , Kris Pister , Michael Richardson | ||
| Last updated | 2019-07-11 (Latest revision 2019-06-13) | ||
| Replaces | draft-vucinic-6tisch-minimal-security | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Pascal Thubert | ||
| Shepherd write-up | Show Last changed 2019-06-21 | ||
| IESG | IESG state | Became RFC 9031 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Suresh Krishnan | ||
| Send notices to | Pascal Thubert <pthubert@cisco.com> |
draft-ietf-6tisch-minimal-security-11
| | | | T. | | | | | | | | | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | | MIC32 | | CCM-128 | MIC-32 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | | MIC64 | | CCM-128 | MIC-64 for | ocument] | | | | | 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. | | +-----------------+-----+------------------+-------------+----------+ Vucinic, et al. Expires December 15, 2019 [Page 31] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 Table 3: Key Usage values. 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. Vucinic, et al. Expires December 15, 2019 [Page 32] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 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 peer with whom the key should be used. Depending on the configuration of the network, key_addinfo may carry the peer's long link-layer address (i.e. pledge identifier), short link-layer address, or their concatenation with the long address being encoded first. Which address is carried is determined from the length of the byte string. o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST NOT be present. o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST be present. key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long. key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4]. o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST be present. key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long. key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4]. In all cases, key_usage parameter determines how a particular key should be used in respect to incoming and outgoing security policies. For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" parameter of {{IEEE802.15.4} that is signaled in all outgoing frames secured with a given key. The maximum value key_id can have is 254. The value of 255 is reserved in {{IEEE802.15.4} and is therefore considered invalid. Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a trusted third party and assign pairwise keys between nodes in the network. How JRC learns about the network topology is out of scope of this specification, but could be done through 6LBR - JRC signaling for example. Pairwise keys could also be derived through a key agreement protocol executed between the peers directly, where the authentication is based on the symmetric cryptographic material provided to both peers by the JRC. Such a protocol is out of scope of this specification. Vucinic, et al. Expires December 15, 2019 [Page 33] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 8.4.4. Short Identifier The Short_Identifier object represents an identifier assigned to the pledge. It is encoded as a CBOR array object, containing, in order: o identifier: The short identifier assigned to the pledge, encoded as a byte string. This parameter MUST be included. The identifier MUST be unique in the set of all identifiers assigned in a network that is managed by a JRC. In case the identifier is invalid, the decoder MUST silently ignore the Short_Identifier object. o lease_time: The validity of the identifier in hours after the reception of the CBOR object, encoded as a CBOR unsigned integer. This parameter MAY be included. The node MUST stop using the assigned short identifier after the expiry of the lease_time interval. It is up to the JRC to renew the lease before the expiry of the previous interval. The JRC updates the lease by executing the Parameter Update exchange with the node and including the Short_Identifier in the Configuration object, as described in Section 8.2. In case the lease expires, the node SHOULD initiate a new join exchange, as described in Section 8.1. In case this parameter is omitted, the value of positive infinity MUST be assumed, meaning that the identifier is valid for as long as the node participates in the network. The CDDL fragment that represents the text above for the Short_Identifier follows. Short_Identifier = [ identifier : bstr, ? lease_time : uint ] 8.4.4.1. Use in IEEE Std 802.15.4 When Short_Identifier is used in the context of [IEEE802.15.4], the following considerations apply. The identifier MUST be used to set the short address of IEEE Std 802.15.4 module. When operating in TSCH mode, the identifier MUST be unique in the set of all identifiers assigned in multiple networks that share link-layer key(s). If the length of the byte string corresponding to the identifier parameter is different than 2, the identifier is considered invalid. The values 0xfffe and 0xffff are reserved by [IEEE802.15.4] and their use is considered invalid. Vucinic, et al. Expires December 15, 2019 [Page 34] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 The security properties offered by the [IEEE802.15.4] link-layer in TSCH mode are conditioned on the uniqueness requirement of the short identifier (i.e. short address). The short address is one of the inputs in the construction of the nonce, which is used to protect link-layer frames. If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is eminent. For this reason, practices where the pledge generates the short identifier locally are not safe and are likely to result in the loss of link-layer security properties. The JRC MUST ensure that at any given time there are never two same 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. Unsupported Configuration Object 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 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 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 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 Vucinic, et al. Expires December 15, 2019 [Page 35] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 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 Unsupported_Configuration and Unsupported_Parameter objects follows. Unsupported_Configuration = [ + parameter : Unsupported_Parameter ] Unsupported_Parameter = ( code : int, parameter_label : int, parameter_addinfo : nil / any ) +-------------+-------+--------------------------------+------------+ | 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. Vucinic, et al. Expires December 15, 2019 [Page 36] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 +--------------------------+---------------+ | Name | Default Value | +--------------------------+---------------+ | COJP_MAX_JOIN_ATTEMPTS | 4 | | | | | COJP_REKEYING_GUARD_TIME | 12 seconds | +--------------------------+---------------+ Recommended CoJP settings. The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible retransmissions at the link layer due to imperfect wireless links. 9. Security Considerations Since this document uses the pledge identifier to set the ID Context parameter of OSCORE, an important security requirement is that the pledge identifier is unique in the set of all pledge identifiers managed by a JRC. The uniqueness of the pledge identifier ensures unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also allows the JRC to retrieve the correct security context, upon the reception of a Join Request message. The management of pledge identifiers is simplified if the globally unique EUI-64 is used, but this comes with privacy risks, as discussed in Section 10. This document further mandates that the (6LBR) pledge and the JRC are provisioned with unique PSKs. The PSK is used to set the OSCORE Master Secret during security context derivation. This derivation process results in OSCORE keys that are important for mutual authentication of the (6LBR) pledge and the JRC. Should an attacker come to know the PSK, then a man-in-the-middle attack is possible. Many vendors are known to use unsafe practices when generating and provisioning PSKs. The use of a single PSK shared among a group of devices is a common pitfall that results in poor security. In this case, the compromise of a single device is likely to lead to a compromise of the entire batch, with the attacker having the ability to impersonate a legitimate device and join the network, generate bogus data and disturb the network operation. As a reminder, recall the well-known problem with Bluetooth headsets with a "0000" pin. Additionally, some vendors use methods such as scrambling or hashing of device serial numbers or their EUI-64 to generate "unique" PSKs. Without any secret information involved, the effort that the attacker needs to invest into breaking these unsafe derivation methods is quite low, resulting in the possible impersonation of any device from the batch, without even needing to compromise a single device. The use of cryptographically secure random number generators to generate Vucinic, et al. Expires December 15, 2019 [Page 37] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms using deterministic methods. The JP forwards the unauthenticated join traffic into the network. A data cap on the JP prevents it from forwarding more traffic than the network can handle. The data cap can be configured by the JRC by including a join rate parameter in the Join Response and it is implemented through the CoAP's PROBING_RATE setting. The use of a data cap at a JP forces attackers to use more than one JP if they wish to overwhelm the network. Marking the join traffic packets with a non-zero DSCP allows the network to carry the traffic if it has capacity, but encourages the network to drop the extra traffic rather than add bandwidth due to that traffic. The shared nature of the "minimal" cell used for the join traffic makes the network prone to a DoS attack by congesting the JP with bogus traffic. Such an attacker is limited by its maximum transmit power. The redundancy in the number of deployed JPs alleviates the issue and also gives the pledge a possibility to use the best available link for joining. How a network node decides to become a JP is out of scope of this specification. At the beginning of the join process, the pledge has no means of verifying the content in the EB, and has to accept it at "face value". In case the pledge tries to join an attacker's network, the Join Response message will either fail the security check or time out. The pledge may implement a temporary blacklist in order to filter out undesired EBs and try to join using the next seemingly valid EB. This blacklist alleviates the issue, but is effectively limited by the node's available memory. Note that this temporary blacklist is different from the one communicated as part of the CoJP Configuration object as it helps pledge fight a DoS attack. These bogus beacons prolong the join time of the pledge, and so the time spent in "minimal" [RFC8180] duty cycle mode. The blacklist communicated as part of the CoJP Configuration object helps JP fight a DoS attack by a malicious pledge. 10. Privacy Considerations The join solution specified in this document relies on the uniqueness of the pledge identifier in the set of all pledge identifiers managed by a JRC. This identifier is transferred in clear as an OSCORE kid context. The use of the globally unique EUI-64 as pledge identifier simplifies the management but comes with certain privacy risks. The implications are thoroughly discussed in [RFC7721] and comprise correlation of activities over time, location tracking, address scanning and device-specific vulnerability exploitation. Since the join process occurs rarely compared to the network lifetime, long- Vucinic, et al. Expires December 15, 2019 [Page 38] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 term threats that arise from using EUI-64 as the pledge identifier are minimal. In addition, the Join Response message contains a short address which is assigned by the JRC to the (6LBR) pledge. The assigned short address SHOULD be uncorrelated with the long-term pledge identifier. The short address is encrypted in the response. Once the join process completes, the new node uses the short addresses for all further layer 2 (and layer-3) operations. This reduces the aforementioned privacy risks as the short layer-2 address (visible even when the network is encrypted) is not traceable between locations and does not disclose the manufacturer, as is the case of EUI-64. However, an eavesdropper with access to the radio medium during the join process may be able to correlate the assigned short address with the extended address based on timing information with a non-negligible probability. This probability decreases with an increasing number of pledges joining concurrently. 11. IANA Considerations Note to RFC Editor: Please replace all occurrences of "[[this document]]" with the RFC number of this specification. This document allocates a well-known name under the .arpa name space according to the rules given in [RFC3172]. The name "6tisch.arpa" is requested. No subdomains are expected. No A, AAAA or PTR record is requested. 11.1. CoJP Parameters Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Parameters Registry". The columns of the registry are: Name: This is a descriptive name that enables an easier reference to the item. It is not used in the encoding. Label: The value to be used to identify this parameter. The label is an integer. CBOR type: This field contains the CBOR type for the field. Description: This field contains a brief description for the field. Reference: This field contains a pointer to the public specification for the field, if one exists. This registry is to be populated with the values in Table 2. Vucinic, et al. Expires December 15, 2019 [Page 39] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 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.2. CoJP Key Usage Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Key Usage Registry". The columns of this registry are: 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. Value: This is the value used to identify the key usage setting. These values MUST be unique. The value is an integer. Algorithm: This is a descriptive name of the link-layer algorithm in use and uniquely determines the key length. The name is not used in the encoding. Description: This field contains a description of the key usage setting. The field should describe in enough detail how the key is to be used with different frame types, specific for the link-layer technology in question. 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 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. Vucinic, et al. Expires December 15, 2019 [Page 40] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 11.3. CoJP Unsupported Configuration Code Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Unsupported Configuration Code Registry". The columns of this registry are: 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. Value: This is the value used to identify the diagnostic code. These values MUST be unique. The value is an integer. 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 Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. 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): Christian Amsuss, Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 13. References Vucinic, et al. Expires December 15, 2019 [Page 41] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 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-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, <https://www.rfc-editor.org/info/rfc2119>. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>. [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. Vucinic, et al. Expires December 15, 2019 [Page 42] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 13.2. Informative References [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode 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-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. [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, <https://www.rfc-editor.org/info/rfc4231>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>. Vucinic, et al. Expires December 15, 2019 [Page 43] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>. [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>. [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>. [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>. [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, <https://www.rfc-editor.org/info/rfc8480>. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>. Appendix A. Example Figure 3 illustrates a successful join protocol exchange. The pledge instantiates the OSCORE context and derives the OSCORE keys and nonces from the PSK. It uses the instantiated context to protect the Join Request addressed with a Proxy-Scheme option, the well-known host name of the JRC in the Uri-Host option, and its EUI-64 as pledge identifier and OSCORE kid context. Triggered by the presence of a Proxy-Scheme option, the JP forwards the request to the JRC and sets the CoAP token to the internally needed state. The JP has learned the IPv6 address of the JRC when it acted as a pledge and joined the network. Once the JRC receives the request, it looks up the correct context based on the kid context parameter. The OSCORE data authenticity verification ensures that the request has not been Vucinic, et al. Expires December 15, 2019 [Page 44] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 modified in transit. In addition, replay protection is ensured through persistent handling of mutable context parameters. Once the JP receives the Join Response, it authenticates the state within the CoAP token before deciding where to forward. The JP sets its internal state to that found in the token, and forwards the Join Response to the correct pledge. Note that the JP does not possess the key to decrypt the CBOR object (configuration) present in the payload. The Join Response is matched to the Join Request and verified for replay protection at the pledge using OSCORE processing rules. In this example, the Join Response does not contain the IPv6 address of the JRC, the pledge hence understands the JRC is co- located with the 6LBR. Vucinic, et al. Expires December 15, 2019 [Page 45] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 <---E2E OSCORE--> Client Proxy Server Pledge JP JRC | | | | Join | | Code: 0.02 (POST) | Request | | Token: - +--------->| | Proxy-Scheme: coap | | | Uri-Host: 6tisch.arpa | | | OSCORE: kid: -, | | | kid_context: EUI-64, | | | Partial IV: 1 | | | Payload: { Code: 0.02 (POST), | | | Uri-Path: "j", | | | join_request, <Tag> } | | | | | Join | Code: 0.02 (POST) | | Request | Token: opaque state | +--------->| OSCORE: kid: -, | | | kid_context: EUI-64, | | | Partial IV: 1 | | | Payload: { Code: 0.02 (POST), | | | Uri-Path: "j", | | | join_request, <Tag> } | | | | | | | | Join | Code: 2.04 (Changed) | | Response | Token: opaque state | |<---------+ OSCORE: - | | | Payload: { Code: 2.04 (Changed), | | | configuration, <Tag> } | | | | | | | Join | | Code: 2.04 (Changed) | Response | | Token: - |<---------+ | OSCORE: - | | | Payload: { Code: 2.04 (Changed), | | | configuration, <Tag> } | | | Figure 3: Example of a successful join protocol exchange. { ... } denotes authenticated encryption, <Tag> denotes the authentication tag. Where the join_request object is: Vucinic, et al. Expires December 15, 2019 [Page 46] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 join_request: { 5 : h'cafe' / PAN ID of the network pledge is attempting to join / } Since the role parameter is not present, the default role of "6TiSCH Node" is implied. The join_request object encodes to h'a10542cafe' with a size of 5 bytes. And the configuration object is: configuration: { 2 : [ / link-layer key set / 1, / key_id / h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / ], 3 : [ / short identifier / h'af93' / assigned short address / ] } Since the key_usage parameter is not present in the link-layer key set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. Since key_addinfo parameter is not present and key_id is different than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since the lease_time parameter is not present in the short identifier object, the default value of positive infinity is implied. The configuration object encodes to h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 bytes. Appendix B. Lightweight Implementation Option In environments where optimizing the implementation footprint is important, it is possible to implement this specification without having the implementations of HKDF [RFC5869] and SHA [RFC4231] on constrained devices. HKDF and SHA are used during the OSCORE security context derivation phase. This derivation can also be done by the JRC or a provisioning device, on behalf of the (6LBR) pledge during the provisioning phase. In that case, the derived OSCORE security context parameters are written directly into the (6LBR) pledge, without requiring the PSK be provisioned to the (6LBR) pledge. Vucinic, et al. Expires December 15, 2019 [Page 47] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 The use of HKDF to derive OSCORE security context parameters ensures that the resulting OSCORE keys have good security properties, and are unique as long as the input for different pledges varies. This specification ensures the uniqueness by mandating unique pledge identifiers and a unique PSK for each (6LBR) pledge. From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a sufficient condition. However, as discussed in Section 9, the use of a single PSK shared among many devices is a common security pitfall. The compromise of this shared PSK on a single device would lead to the compromise of the entire batch. When using the implementation/ deployment scheme outlined above, the PSK does not need to be written to individual pledges. As a consequence, even if a shared PSK is used, the scheme offers the same level of security as in the scenario where each pledge is provisioned with a unique PSK. Authors' Addresses Malisa Vucinic (editor) Inria 2 Rue Simone Iff Paris 75012 France Email: malisa.vucinic@inria.fr Jonathan Simon Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 USA Email: jonathan.simon@analog.com Kris Pister University of California Berkeley 512 Cory Hall Berkeley, CA 94720 USA Email: pister@eecs.berkeley.edu Vucinic, et al. Expires December 15, 2019 [Page 48] Internet-Draft Minimal Security Framework for 6TiSCH June 2019 Michael Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z5V7 Canada Email: mcr+ietf@sandelman.ca Vucinic, et al. Expires December 15, 2019 [Page 49]