draft-ietf-6tisch-minimal-security-11.txt   draft-ietf-6tisch-minimal-security-12.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: December 15, 2019 Analog Devices Expires: January 30, 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
June 13, 2019 July 29, 2019
Minimal Security Framework for 6TiSCH Minimal Security Framework for 6TiSCH
draft-ietf-6tisch-minimal-security-11 draft-ietf-6tisch-minimal-security-12
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 December 15, 2019. This Internet-Draft will expire on January 30, 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 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5
4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7
4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8
4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9
4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10
5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10
5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11
6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11
6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 6.1. Identification of Unauthenticated Traffic . . . . . . . . 12
7. Application-level Configuration . . . . . . . . . . . . . . . 13 7. Application-level Configuration . . . . . . . . . . . . . . . 14
7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 14
7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 15
7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 17 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18
8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21
8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22
8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24
8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 36 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 39 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 40
11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 40 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 41
11.3. CoJP Unsupported Configuration Code Registry . . . . . . 41 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 44 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Lightweight Implementation Option . . . . . . . . . 47 Appendix B. Lightweight Implementation Option . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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-terminology]. parameter distribution, as defined in [I-D.ietf-6tisch-terminology].
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.
Authorization mechanisms are considered out of scope. Mutual Authorization mechanisms are considered out of scope. Mutual
skipping to change at page 10, line 49 skipping to change at page 10, line 49
synchronize to the network, as EBs are not encrypted [RFC8180]. synchronize to the network, as EBs are not encrypted [RFC8180].
When sending frames during the join process, the pledge sends When sending frames during the join process, the pledge sends
unencrypted and unauthenticated frames. The JP accepts these unencrypted and unauthenticated frames. The JP accepts these
unsecured frames for the duration of the join process. This behavior unsecured frames for the duration of the join process. This behavior
may be implemented by setting the "secExempt" attribute in the IEEE may be implemented by setting the "secExempt" attribute in the IEEE
Std 802.15.4 security configuration tables. How the JP learns Std 802.15.4 security configuration tables. How the JP learns
whether the join process is ongoing is out of scope of this whether the join process is ongoing is out of scope of this
specification. specification.
As the EB itself cannot be authenticated by the pledge, an attacker When the pledge initially synchronizes to the network, it has no
may craft a frame that appears to be a valid EB, since the pledge can means of verifying the authenticity of EB frames. As an attacker can
neither verify the freshness nor verify the address of the JP. This craft a frame that looks like a legitimate EB frame, this opens up a
opens up a DoS vector, as discussed in Section 9. 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 6. Network-layer Configuration
The pledge and the JP SHOULD keep a separate neighbor cache for The pledge and the JP SHOULD keep a separate neighbor cache for
untrusted entries and use it to store each other's information during untrusted entries and use it to store each other's information during
the join process. Mixing neighbor entries belonging to pledges and 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, 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 as the attacker may fill JP's neighbor table and prevent the
discovery of legitimate neighbors. discovery of legitimate neighbors.
skipping to change at page 33, line 35 skipping to change at page 34, line 35
o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 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 set to a value different than 0. key_addinfo parameter
MUST be present. key_addinfo parameter MUST be set to a byte MUST be present. key_addinfo parameter MUST be set to a byte
string, exactly 8 bytes long. key_addinfo parameter carries the string, exactly 8 bytes long. key_addinfo parameter carries the
Key Source parameter used to configure [IEEE802.15.4]. Key Source parameter used to configure [IEEE802.15.4].
In all cases, key_usage parameter determines how a particular key In all cases, key_usage parameter determines how a particular key
should be used in respect to incoming and outgoing security policies. should be used in respect to incoming and outgoing security policies.
For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 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. 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. considered invalid.
Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a
trusted third party and assign pairwise keys between nodes in the trusted third party and assign pairwise keys between nodes in the
network. How JRC learns about the network topology is out of scope network. How JRC learns about the network topology is out of scope
of this specification, but could be done through 6LBR - JRC signaling of this specification, but could be done through 6LBR - JRC signaling
for example. Pairwise keys could also be derived through a key for example. Pairwise keys could also be derived through a key
agreement protocol executed between the peers directly, where the agreement protocol executed between the peers directly, where the
authentication is based on the symmetric cryptographic material authentication is based on the symmetric cryptographic material
provided to both peers by the JRC. Such a protocol is out of scope provided to both peers by the JRC. Such a protocol is out of scope
of this specification. 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 8.4.4. Short Identifier
The Short_Identifier object represents an identifier assigned to the The Short_Identifier object represents an identifier assigned to the
pledge. It is encoded as a CBOR array object, containing, in order: pledge. It is encoded as a CBOR array object, containing, in order:
o identifier: The short identifier assigned to the pledge, encoded o identifier: The short identifier assigned to the pledge, encoded
as a byte string. This parameter MUST be included. The as a byte string. This parameter MUST be included. The
identifier MUST be unique in the set of all identifiers assigned 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 in a network that is managed by a JRC. In case the identifier is
invalid, the decoder MUST silently ignore the Short_Identifier invalid, the decoder MUST silently ignore the Short_Identifier
skipping to change at page 43, line 9 skipping to change at page 44, line 9
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
in progress), March 2019. in progress), July 2019.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 2018.
[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
 End of changes. 12 change blocks. 
34 lines changed or deleted 84 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/