draft-ietf-6tisch-minimal-security-14.txt   draft-ietf-6tisch-minimal-security-15.txt 
6TiSCH Working Group M. Vucinic, Ed. 6TiSCH Working Group M. Vucinic, Ed.
Internet-Draft Inria Internet-Draft Inria
Intended status: Standards Track J. Simon Intended status: Standards Track J. Simon
Expires: June 7, 2020 Analog Devices Expires: June 12, 2020 Analog Devices
K. Pister K. Pister
University of California Berkeley University of California Berkeley
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
December 05, 2019 December 10, 2019
Constrained Join Protocol (CoJP) for 6TiSCH Constrained Join Protocol (CoJP) for 6TiSCH
draft-ietf-6tisch-minimal-security-14 draft-ietf-6tisch-minimal-security-15
Abstract Abstract
This document describes the minimal framework required for a new This document describes the minimal framework required for a new
device, called "pledge", to securely join a 6TiSCH (IPv6 over the device, called "pledge", to securely join a 6TiSCH (IPv6 over the
TSCH mode of IEEE 802.15.4e) network. The framework requires that TSCH mode of IEEE 802.15.4e) network. The framework requires that
the pledge and the JRC (join registrar/coordinator, a central the pledge and the JRC (join registrar/coordinator, a central
entity), share a symmetric key. How this key is provisioned is out entity), share a symmetric key. How this key is provisioned is out
of scope of this document. Through a single CoAP (Constrained of scope of this document. Through a single CoAP (Constrained
Application Protocol) request-response exchange secured by OSCORE Application Protocol) request-response exchange secured by OSCORE
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23
8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25
8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42
11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43
11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Lightweight Implementation Option . . . . . . . . . 50 Appendix B. Lightweight Implementation Option . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document defines a "secure join" solution for a new device, This document defines a "secure join" solution for a new device,
called "pledge", to securely join a 6TiSCH network. The term "secure called "pledge", to securely join a 6TiSCH network. The term "secure
join" refers to network access authentication, authorization and join" refers to network access authentication, authorization and
parameter distribution, as defined in [I-D.ietf-6tisch-architecture]. parameter distribution, as defined in [I-D.ietf-6tisch-architecture].
The Constrained Join Protocol (CoJP) defined in this document handles The Constrained Join Protocol (CoJP) defined in this document handles
parameter distribution needed for a pledge to become a joined node. parameter distribution needed for a pledge to become a joined node.
Mutual authentication during network access and implicit Mutual authentication during network access and implicit
skipping to change at page 14, line 16 skipping to change at page 14, line 16
The Join Proxy SHOULD set the DSCP of packets that it produces as 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 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 [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 on traffic forwarded should set it to zero so that it is compressed
out. out.
A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT
allocate additional cells as a result of traffic with code point allocate additional cells as a result of traffic with code point
AF43. Companion SF documents SHOULD specify how this recommended 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 6.1.2. Traffic from JRC to JP
The JRC SHOULD set the DSCP of join response packets addressed to the 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 Join Proxy to AF42 code point. AF42 has lower drop probability than
AF43, giving this traffic priority in buffers over the traffic going AF43, giving this traffic priority in buffers over the traffic going
towards the JRC. towards the JRC.
The 6LBR links are often the most congested within a DODAG, and from The 6LBR links are often the most congested within a DODAG, and from
that point down there is progressively less (or equal) congestion. that point down there is progressively less (or equal) congestion.
skipping to change at page 42, line 6 skipping to change at page 42, line 6
The join solution specified in this document relies on the uniqueness The join solution specified in this document relies on the uniqueness
of the pledge identifier in the set of all pledge identifiers managed 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 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 context. The use of the globally unique EUI-64 as pledge identifier
simplifies the management but comes with certain privacy risks. The simplifies the management but comes with certain privacy risks. The
implications are thoroughly discussed in [RFC7721] and comprise implications are thoroughly discussed in [RFC7721] and comprise
correlation of activities over time, location tracking, address correlation of activities over time, location tracking, address
scanning and device-specific vulnerability exploitation. Since the scanning and device-specific vulnerability exploitation. Since the
join process occurs rarely compared to the network lifetime, long- join process occurs rarely compared to the network lifetime, long-
term threats that arise from using EUI-64 as the pledge identifier term threats that arise from using EUI-64 as the pledge identifier
are minimal. In addition, the Join Response message contains a short are minimal. However, the use of EUI-64 after the join process
address which is assigned by the JRC to the (6LBR) pledge. The completes, in the form of a layer-2 or layer-3 address, extends the
assigned short address SHOULD be uncorrelated with the long-term aforementioned privacy threats to long term.
pledge identifier. The short address is encrypted in the response.
Once the join process completes, the new node uses the short As an optional mitigation technique, the Join Response message may
addresses for all further layer 2 (and layer-3) operations. This contain a short address which is assigned by the JRC to the (6LBR)
reduces the aforementioned privacy risks as the short layer-2 address pledge. The assigned short address SHOULD be uncorrelated with the
(visible even when the network is encrypted) is not traceable between long-term pledge identifier. The short address is encrypted in the
locations and does not disclose the manufacturer, as is the case of response. Once the join process completes, the new node may use the
EUI-64. However, an eavesdropper with access to the radio medium short addresses for all further layer-2 (and layer-3) operations.
during the join process may be able to correlate the assigned short This reduces the privacy threats as the short layer-2 address
address with the extended address based on timing information with a (visible even when the network is encrypted) does not disclose the
non-negligible probability. This probability decreases with an manufacturer, as is the case of EUI-64. However, an eavesdropper
increasing number of pledges joining concurrently. 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 11. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification. document]]" with the RFC number of this specification.
This document allocates a well-known name under the .arpa name space This document allocates a well-known name under the .arpa name space
according to the rules given in [RFC3172]. The name "6tisch.arpa" is according to the rules given in [RFC3172]. The name "6tisch.arpa" is
requested. No subdomains are expected, and addition of any such requested. No subdomains are expected, and addition of any such
subdomains requires the publication of an IETF standards-track RFC. subdomains requires the publication of an IETF standards-track RFC.
skipping to change at page 45, line 35 skipping to change at page 45, line 38
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>. <https://www.rfc-editor.org/info/rfc2597>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>. September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
skipping to change at page 46, line 46 skipping to change at page 47, line 5
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
13.2. Informative References 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] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-08 (work in progress), March 2019. cddl-08 (work in progress), March 2019.
skipping to change at page 47, line 37 skipping to change at page 48, line 5
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[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>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
 End of changes. 11 change blocks. 
27 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/