--- 1/draft-ietf-6tisch-minimal-security-14.txt 2019-12-10 02:13:14.005067010 -0800 +++ 2/draft-ietf-6tisch-minimal-security-15.txt 2019-12-10 02:13:14.113069768 -0800 @@ -1,23 +1,23 @@ 6TiSCH Working Group M. Vucinic, Ed. Internet-Draft Inria Intended status: Standards Track J. Simon -Expires: June 7, 2020 Analog Devices +Expires: June 12, 2020 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software Works - December 05, 2019 + December 10, 2019 Constrained Join Protocol (CoJP) for 6TiSCH - draft-ietf-6tisch-minimal-security-14 + draft-ietf-6tisch-minimal-security-15 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 @@ -39,21 +39,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 June 7, 2020. + This Internet-Draft will expire on June 12, 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 @@ -87,26 +87,26 @@ 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 46 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48 - Appendix B. Lightweight Implementation Option . . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 + Appendix B. Lightweight Implementation Option . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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-architecture]. The Constrained Join Protocol (CoJP) defined in this document handles parameter distribution needed for a pledge to become a joined node. Mutual authentication during network access and implicit @@ -617,21 +617,22 @@ The Join Proxy SHOULD set the DSCP of packets that it produces as part of the forwarding process to AF43 code point (See Section 6 of [RFC2597]). A Join Proxy that does not require a specific DSCP value on traffic forwarded should set it to zero so that it is compressed out. A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additional cells as a result of traffic with code point AF43. Companion SF documents SHOULD specify how this recommended - behavior is achieved. + behavior is achieved. One example is the 6TiSCH Minimal Scheduling + Function [I-D.ietf-6tisch-msf]. 6.1.2. Traffic from JRC to JP The JRC SHOULD set the DSCP of join response packets addressed to the Join Proxy to AF42 code point. AF42 has lower drop probability than AF43, giving this traffic priority in buffers over the traffic going towards the JRC. The 6LBR links are often the most congested within a DODAG, and from that point down there is progressively less (or equal) congestion. @@ -1897,34 +1898,38 @@ 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- 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. + are minimal. However, the use of EUI-64 after the join process + completes, in the form of a layer-2 or layer-3 address, extends the + aforementioned privacy threats to long term. + + As an optional mitigation technique, the Join Response message may + contain 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 may use the + short addresses for all further layer-2 (and layer-3) operations. + This reduces the privacy threats as the short layer-2 address + (visible even when the network is encrypted) 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, and addition of any such subdomains requires the publication of an IETF standards-track RFC. @@ -2065,20 +2071,25 @@ [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, . [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, . + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + . + [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, @@ -2119,20 +2130,26 @@ Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . 13.2. Informative References + [I-D.ietf-6tisch-msf] + Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and + D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", + draft-ietf-6tisch-msf-08 (work in progress), November + 2019. + [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [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. @@ -2156,25 +2173,20 @@ [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, . [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, - 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, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, .