--- 1/draft-ietf-6tisch-minimal-security-10.txt 2019-06-13 09:15:38.785001673 -0700 +++ 2/draft-ietf-6tisch-minimal-security-11.txt 2019-06-13 09:15:38.905004698 -0700 @@ -1,23 +1,23 @@ 6TiSCH Working Group M. Vucinic, Ed. Internet-Draft Inria Intended status: Standards Track J. Simon -Expires: October 7, 2019 Analog Devices +Expires: December 15, 2019 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software Works - April 05, 2019 + June 13, 2019 Minimal Security Framework for 6TiSCH - draft-ietf-6tisch-minimal-security-10 + draft-ietf-6tisch-minimal-security-11 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 October 7, 2019. + This Internet-Draft will expire on December 15, 2019. 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 @@ -186,21 +186,21 @@ o join proxy (JP) o join registrar/coordinator (JRC) o enhanced beacon (EB) o join protocol o join process - The following terms defined in [RFC6775] are also used throughout + The following terms defined in [RFC8505] 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]. @@ -381,22 +381,22 @@ that has sent the EB to the pledge acts as the JP. At this point, the pledge may proceed to step 2, or continue to listen for additional EBs. 4.2. Step 2 - Neighbor Discovery The pledge forms its link-local IPv6 address based on the interface identifier, as per [RFC4944]. The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchange with the JP, as per - Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- - local IPv6 addresses for all subsequent communication during the join + Section 5.6 of [RFC8505]. The pledge and the JP use their link-local + IPv6 addresses for all subsequent communication during the join process. Note that Neighbor Discovery exchanges at this point are not protected with link-layer security as the pledge is not in possession of the keys. How JP accepts these unprotected frames is discussed in Section 5. 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution The pledge triggers the join exchange of the Constrained Join @@ -481,21 +481,21 @@ 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. Once the pledge obtains link-layer keys and becomes a joined node, it is able to securely communicate with its neighbors, obtain the network IPv6 prefix and form its global IPv6 address. The joined node then undergoes an independent process to bootstrap its neighbor cache entries, possibly with a node that formerly acted as a JP, - following [RFC6775]. From the point of view of the JP, there is no + following [RFC8505]. From the point of view of the JP, there is no relationship between the neighbor cache entry belonging to a pledge and the joined node that formerly acted as a pledge. The pledge does not communicate with the JRC at the network layer. This allows the pledge to join without knowing the IPv6 address of the JRC. Instead, the pledge communicates with the JP at the network layer using link-local addressing, and with the JRC at the application layer, as specified in Section 7. The JP communicates with the JRC over global IPv6 addresses. The JP @@ -569,21 +569,23 @@ Due to the convergecast nature of the DODAG, the 6LBR links are often the most congested, and from that point down there is progressively less (or equal) congestion. If the 6LBR paces itself when sending join response traffic then it ought to never exceed the bandwidth allocated to the best effort traffic cells. If the 6LBR has the capacity (if it is not constrained) then it should provide some buffers in order to satisfy the Assured Forwarding behavior. Companion SF documents SHOULD specify how traffic with code point - AF42 is handled with respect to cell allocation. + AF42 is handled with respect to cell allocation. In case the + recommended behavior described in this section is not followed, the + network may become prone to the attack discussed in Section 6.1. 7. Application-level Configuration The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and the secure channel provided by OSCORE [I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server. The JP implements CoAP forward proxy functionality [RFC7252]. Because the JP can also be a constrained device, it cannot implement a cache. @@ -1774,21 +1776,21 @@ 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-registries within the "IPv6 over the TSCH + 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. @@ -1805,21 +1807,21 @@ 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-registries within the "IPv6 over the TSCH + 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. @@ -1841,21 +1843,21 @@ 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 Unsupported Configuration Code Registry - This section defines a sub-registries within the "IPv6 over the TSCH + 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. @@ -1984,26 +1986,20 @@ DOI 10.17487/RFC5869, May 2010, . [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, . - [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. - Bormann, "Neighbor Discovery Optimization for IPv6 over - Low-Power Wireless Personal Area Networks (6LoWPANs)", - RFC 6775, DOI 10.17487/RFC6775, November 2012, - . - [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, . [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, . @@ -2011,20 +2007,26 @@ [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, . [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, . + [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, + . + 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