--- 1/draft-ietf-6tisch-minimal-security-11.txt 2019-07-29 09:13:21.282002965 -0700 +++ 2/draft-ietf-6tisch-minimal-security-12.txt 2019-07-29 09:13:21.390005693 -0700 @@ -1,23 +1,23 @@ 6TiSCH Working Group M. Vucinic, Ed. Internet-Draft Inria Intended status: Standards Track J. Simon -Expires: December 15, 2019 Analog Devices +Expires: January 30, 2020 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software Works - June 13, 2019 + July 29, 2019 Minimal Security Framework for 6TiSCH - draft-ietf-6tisch-minimal-security-11 + draft-ietf-6tisch-minimal-security-12 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,21 +38,21 @@ 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 December 15, 2019. + This Internet-Draft will expire on January 30, 2020. Copyright Notice 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 @@ -66,45 +66,46 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 + 5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 21 + 7. Application-level Configuration . . . . . . . . . . . . . . . 14 + 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 14 + 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 15 + 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18 + 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20 + 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21 + 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 - 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 + 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 37 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 40 + 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 41 + 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 42 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 + 13.2. Informative References . . . . . . . . . . . . . . . . . 44 + Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45 + Appendix B. Lightweight Implementation Option . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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 @@ -462,24 +463,66 @@ synchronize to the network, as EBs are not encrypted [RFC8180]. When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames. The JP accepts these unsecured frames for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. How the JP learns whether the join process is ongoing is out of scope of this specification. - As the EB itself cannot be authenticated by the pledge, an attacker - may craft a frame that appears to be a valid EB, since the pledge can - neither verify the freshness nor verify the address of the JP. This - opens up a DoS vector, as discussed in Section 9. + When the pledge initially synchronizes to the network, it has no + means of verifying the authenticity of EB frames. As an attacker can + craft a frame that looks like a legitimate EB frame, this opens up a + DoS vector, as discussed in Section 9. + +5.1. Distribution of Time + + Nodes in a 6TiSCH network keep a global notion of time known as the + absolute slot number (ASN). ASN is used in the construction of the + link-layer nonce, as defined in [IEEE802.15.4]. The pledge initially + synchronizes to the EB frame sent by the JP, and uses the value of + the ASN found in the TSCH Synchronization Information Element. At + the time of the synchronization, the EB frame can neither be + authenticated nor its freshness verified. During the join process, + the pledge sends frames that are unprotected at the link-layer and + protected end-to-end instead. The pledge does not obtain the time + information as the output of the join process as this information is + local to the network and may not be known at the JRC. + + This enables an attack on the pledge where the attacker replays to + the pledge legitimate EB frames obtained from the network and acts as + a man-in-the-middle between the pledge and the JP. The EB frames + will make the pledge believe that the replayed ASN value is the + current notion of time in the network. By forwarding the join + traffic to the legitimate JP, the attacker enables the pledge to join + the network. Under different conditions relating to the reuse of the + pledge's short address by the JRC or its attempt to rejoin the + network, this may cause the pledge to reuse the link-layer nonce in + the first frame it sends protected after the join process is + completed. + + For this reason, all frames originated at the JP and destined to the + pledge during the join process MUST be authenticated at the link- + layer using the key that is normally in use in the network. Link- + layer security processing at the pledge for these frames will fail as + the pledge is not yet in possession of the key. The pledge + acknowledges these frames without link-layer security, and JP accepts + the unsecured acknowledgment due to the secExempt attribute set for + the pledge. The frames should be passed to the upper layer for + processing using the promiscuous mode of [IEEE802.15.4] or another + appropriate mechanism. When the upper layer processing is completed + and the link-layer keys are configured, the upper layer MUST trigger + the security processing of the corresponding frame. Once the + security processing of the frame carrying the Join Response message + is successful, the current ASN kept locally at the pledge SHALL be + declared as valid. 6. Network-layer Configuration The pledge and the JP SHOULD keep a separate neighbor cache for untrusted entries and use it to store each other's information during the join process. Mixing neighbor entries belonging to pledges and nodes that are part of the network opens up the JP to a DoS attack, as the attacker may fill JP's neighbor table and prevent the discovery of legitimate neighbors. @@ -1501,35 +1544,42 @@ 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 + 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 + 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. + Implementations MUST use different link-layer keys when using + different authentication tag (MIC) lengths, as using the same key + with different authentication tag lengths might be unsafe. For + example, this prohibits the usage of the same key for both MIC-32 and + MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more + information. + 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 @@ -1934,22 +1984,22 @@ . [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.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. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work + in progress), July 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