One document matched: draft-richardson-6tisch--security-6top-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY IEEE8021AR SYSTEM "http://www.sandelman.ca/rfc/xml/reference.802.1AR.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-richardson-6tisch--security-6top-04"
ipr="trust200902">
<front>
<title abbrev="6tisch-6top">6tisch secure join using 6top</title>
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization abbrev="SSW">Sandelman Software Works</organization>
<address>
<postal>
<street>470 Dawson Avenue</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Z 5V7</code>
<country>CA</country>
</postal>
<email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/</uri>
</address>
</author>
<date year="2014"/>
<abstract>
<t>This document details a security architecture that permits a new
6tisch compliant node to join an 802.15.4e network. The process
bootstraps the new node authenticating the node to the network, and the
network to the node, and configuring the new node with the required
6tisch schedule. Any resemblance to WirelessHART/IEC62591 is entirely
intentional.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
A challenging part with constructing an LLN with nodes from multiple vendors is
providing enough security context to each node such that the network communication can
form and remain secure. Most LLNs are small and have no operator interfaces at all,
and even if they have debug interfaces (such as JTAG) with personnel trained to use that,
doing any kind of interaction involving electrical connections in a dirty environment such
as a factory or refinery is hopeless.
</t>
<t>
It is necessary to have a way to introduce new nodes into a 6tisch network that does not
involve any direct manipulation of the nodes themselves. This act has been called "zero-touch"
provisioning, and it does not occur by chance, but requires coordination between the manufacturer
of the node, the service operator running the LLN, and the installers actually taking the devices
out of the shipping boxes.
</t>
<!-- section 1.1 -->
<section title="Assumptions">
<t>
For the process described in this document to work, some assumptions about available
infrastructure are made. These are perhaps more than assumptions, but rather architectural
requirements; the exact operation of said infrastructure to be defined in a subsequent document.
</t>
<t>
In the diagrams and text that follows entities are named (and defined in the terminology
section). Unless otherwise stated these are roles, not actual machines/systems. The roles
are seperated by network protocols in order that they roles can be performed by different
systems, not because they have to be. Different deployments will have different scaling
requirements for those entities. Smaller deployments might co-located many roles together
into a single ruggedized platform, while other deployments might operate all of the roles
on distinct, multiply-redundant server classes located in a fully equipped datacentre.
</t>
</section>
</section>
<!-- section 2 -->
<section title="Terminology and Roles">
<t>
Most terminology should be taken from <xref target="I-D.ietf-6tisch-architecture"/>
and from <xref target="I-D.ietf-6tisch-6top-interface"/> and
<xref target="I-D.wang-6tisch-6top-sublayer" />. As well, many terms are taken from
<xref target="RFC6775" />.
</t>
<t>The following roles/things are defined:
<list hangIndent="20" style="hanging">
<t hangText="PCE">the Path Computation Engine. This entity reaches out to each of the nodes in the LLN, and configures an appropriate schedule using 6top.</t>
<t hangText="Authz Server/ACE">the Authorization Server. This offloads calculation of access control lists and other access control decisions for constrainted nodes. See <xref target="I-D.seitz-ace-problem-description"/></t>
<t hangText="6top">the 6top protocol is defined abstractly in
<xref target="I-D.ietf-6tisch-6top-interface"/> and mapped to run over CoAP in
<xref target="I-D.ietf-6tisch-coap" />. The 6top protocol is defined primarily
to provision the 6TiSCH schedule; this document proposes to extend it for also
provisioning of layer-2 security parameters.
</t>
<t hangText="JCE">the Join Coordination Entity. This acronym is chosen to parallel the PCE.</t>
<t hangText="joining node"> The newly unboxed constrained node that needs to join a network.</t>
<t hangText="join protocol"> the protocol which secures initial communication between the joining node and the JCE</t>
<t hangText="join assistant"> A constrained node near the joining node that will act as it's first
6LR, and will relay traffic to/from the joining node.</t>
<t hangText="join network"> A 802.15.4e network whose encryption and authentication key is "JOIN6TISCH".</t>
<t hangText="unique join key"> a key shared between a newly joining node, and the JCE </t>
<t hangText="production network"> A 802.15.4e network whose encryption/authentication keys are
determined by some algorithm. There may have network-wide group keys, or per-link keys.</t>
<t hangText="production network key"> A shared L2-key known by all authorized nodes. This key can be used to derive other keys.</t>
<t hangText="per-peer L2 key"> a key that results from an exchange (such as MLE) that creates a pair-wise L2 key which is known only to the two nodes involved, <xref target="I-D.piro-6tisch-security-issues"/> calls this a LinkKey</t>
</list>
</t>
<t>The following terms are used in this document and come from other documents:
<list hangIndent="20" style="hanging">
<t hangText="DevID"><xref target="IEEE.802.1AR" /> defines the
secure DEVice IDentifier as
a device identifier that is cryptographically bound to the device and
is composed of the Secure Device Identifier Secret and the
Secure Device Identifier Credential.</t>
<t hangText="IDevID">The Initial secure DEVice IDentifier (IDevID)
is the Device Identifier which was installed on the device by the manufacturer.</t>
<t hangText="LDevID">A Locally significant secure DEVice IDentifiers (LDevIDs) is
a Secure Device Identifier credential that is unique in the local administrative
domain in which the device is used. The LDevID is usually a new certificate
provisioned by some local means, such as the 6top mechanism defined in this document.
</t>
<t hangText="CoAP">The CoAP protocol, defined in <xref target="RFC7252" /> is an HTTP-like
resource access protocol. CoAP runs over UDP.</t>
<t hangText="DTLS"> The datagram version of TLS, defined in <xref target="RFC6347" />, and which can be used to secure CoAP in the same way that TLS secures HTTP.</t>
<t hangText="ARO"> <xref target="RFC6775" />defines a number of new Neighbor Discovery options including the Address Registration Option</t>
<t hangText="DAR/DAC"> <xref target="RFC6775" />defines the Duplicate Address Request and Duplicate Address Confirmation options to turn the multicasted Duplicate Address Detection protocol into a client/server process</t>
<t hangText="EARO"> <xref target="I-D.thubert-6lo-rfc6775-update-reqs" />extends the ARO option to include some additional fields necessary to distinguish duplicate addresses from
nodes that have moved networks when there are mulitple LLNs linked over a backbone.</t>
</list>
</t>
</section>
<!-- section 3: ARCHITECTURE -->
<section title="Architectural requirements of join protocol">
<section title="Entities involves in the join processions">
<t>
The following actors are involved: there is a new joining
node. It is (radio) adjacent to the join assistant. The
join assistant is part of the production network, and
participates in one or more DODAGs, such that it is reachable from
the 6LBR, and the JCE.
</t>
</section>
<section title="Join Protocol deliverables">
<t>This section works from the ultimate goal, and goes backwards to prerequisite actions.
(<xref target="tsd" /> presents the protocol from beginning to end order)</t>
<t>
The ultimate goal of the join protocol is to provide a new node with a locally
significant security credentials that it is able to take part in the network directly.
The credentials may vary by deployment. They can be one of:
<list hangIndent="4" style="format %d)">
<t>a network-wide shared symmetric key (this is the production network key, or MasterKey)</t>
<t>a locally significant (one-level only) 802.11AR type LDevID certificate (which allows it to negotiate a pair-wise keys)</t>
</list>
One of these two items is delivered by JCE to the joining node using
the 6top protocol. That is, the JCE provisions using a secure "northbound" interface.
The authentication of this interface the subject of the Join Protocol as explained below.
</t>
<t>The above credential are used for authentication to generate
per-peer L2, using a key exchange protocol. The choice of key exchange
protocol, and what kind of link and multicast keying needs to be done
is also provisioned by the JCE. There are a number of options for doing this, such as:
<list hangIndent="4" style="format %d)">
<t>Mesh Link Exchange <xref target="I-D.kelsey-intarea-mesh-link-establishment"/> (IMPORTANT, a good option. Uses certificates from common CA)</t>
<t>work in 802.15.9 (uses certificates from common CA)</t>
<t>Security Framework and Key Management Protocol Requirements for 6TiSCH <xref target="I-D.ohba-6tisch-security"/> (this document provides the phase 0 required, using the network-wide shared key)</t>
<t>Layer-2 security aspects for the IEEE 802.15.4e MAC <xref target="I-D.piro-6tisch-security-issues"/>: the MasterKey is used to derive per-peer L2 keys</t> <!-- https://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues/ -->
</list>
</t>
<t>Per-peer L2 keying is critical when doing peer-2-peer schedule
negotiation over 15.4 Information Elements. Therefore a network-wide
layer-2 key is inappropriate for the self-organizing networks, and a
protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.</t>
<t>For networks where there is a PCE present and it will do all schedule
computation, then the only trust relationship necessary is between the
individual node and the PCE, and it MAY be acceptable to have a
network-wide L2 key derived in ways such as
<xref target="I-D.piro-6tisch-security-issues"/> describes in section ?.
The trust relationship between the PCE and the joining node flows from
the LDevID certificate loaded by the JCE. When the PCE and JCE are
co-located, the existing 6top/DTLS security association could be reused.
</t>
</section>
<section title="Join Protocol connection setup">
<t>
The intermediate level goal of the join protocol is to enable a Join
Coordination Entity (JCE) to reach out to the new node, and install
the credentials detailed above. The JCE must authenticate itself to
the joining node so that the joining node will know that it has
joined the correct network, and the joining node must authenticate
itself to the JCE so that the JCE will know that this node belongs in
the network. This two way authentication occurs in the
6top/CoAP/DTLS session that is established between the JCE and the joining node.
</t>
<t>
<xref target="I-D.ietf-6tisch-6top-interface"/> presents a way to interface to a 6top
information model (defined in YANG).
<xref target="I-D.ietf-6tisch-coap" /> explains how to access that
information model using CoAP.
This information model will include security attributes for the network. The JCE would
therefore reach out to the joining node and simply provision appropriate security properties
into the joining node, much like the PCE will provision schedules.
</t>
<t>
This 6top-based secure join protocol has defined a push model for security provisioning by
the JCE. This has been done for three reasons:
<list hangIndent="4" style="format %d)">
<t>6tisch nodes already have to have a 6top CoAP server for schedule provising</t>
<t>this permits the JCE to manage how many nodes are trying to join at the same time,
and limit how much bandwidth/energy is used for the join operation, and also for the
JCE to prioritize the join order for nodes.</t>
<t>making the JCE initiate the DTLS connection significantly simplies the certificate
chains that must be exchanged as the most constrained side (the joining node) provides
it's credentials first, and lets the less constrained JCE figure out what kind of certificate
chain will be required to authenticate the JCE to the joining node. In EAP-TLS/802.1x situations, the TLS
channel is created in the opposite direction, and it would have to complete in a tentative
way, and then further authorization occur in-band.
</t>
</list>
</t>
</section>
<section title="End to End considerations for Join Protocol">
<t>
In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node,
there needs to be end-to-end IPv6 connectivity between those two entities. The joining
node will not participate in the route-over RPL mesh, but rather will be seen by the
network as being a 6lowpan only leaf-node.
</t>
<t>
The joining node sends traffic to the join assistant, which
forwards it using the normal RPL DODAG upwards routes, and which
will reach the JCE using regular routing.
</t>
<t>
The challenge is getting connectivity from the JCE to the joining
node, as the DODAG will have no information about this
node. Instead, the JCE will use loose-source routes to address
packets first to the Join Assistant, which will then forward to the
joining node. This has an interaction with the (strict) source
routes used by non-storing DODAGs which would be used by the 6LBR
to reach the Join Assistant.
</t>
<t>
There are some alternatives to having full end to end connectivity
which are discussed in the security considerations section.
</t>
<section title="Security Considerations: alternatives to source routes">
<t>This goes into security-considerations section</t>
<t>
A number of alternatives were considered for creating end to end
connectivity between the joining node and the JCE, but were rejected.
<list style="format (%d)">
<t> IPIP tunnel between Join Assistant and JCE</t>
<t> using straight RPL routing: the Join Assistant sends a DAO</t>
<t> using a separate RPL DODAG for join traffic</t>
<t> establishing a specific multi-hop 6tisch track for join traffic for each Join Assistant</t>
</list>
</t>
<section title="IPIP tunnel">
<t>This mechanism requires 40 bytes overhead per packet, and may
require specific state to be created on the Join Assistant, or
may open the network up to a resource exhaustion by malicious
join nodes.
</t>
<t>
This mechanism was rejected on due to byte count, because it would require
code only needed for join, and because doing it securely may require a per-tunnel
state to be maintained on the join assistant.
</t>
</section>
<section title="join existing DODAG">
<t>
This mechanism is to just have the new node join the DODAG as a leaf node.
The join assistant would issue a DAO for the new node. If a storing DODAG
was used, this would directly cost state in all parent nodes of the
Join Assistant, subjecting the lower-rank parts of the network to significant
denial of service attacks.
</t>
<t>On a non-storing DODAG the situation is significantly better: no state is
created by the presence of the leaf node except in the 6LBR, where available
resources may be higher.
</t>
<t> This mechanism was rejected in favour of the loose source routed option as
this the loose source routed option always works even for storing DODAGs, and
is otherwise exactly equivalent in terms of network bandwidth cost.
</t>
</section>
<section title="join a DODOAG for joining">
<t>
One option to deal with the problem of resource consumption in the storing DODAG
case is to use a second DODAG.
</t>
<t>
This mechanism was rejected as it consumes resources in all nodes for the second
DODAG, and many implementations support on a single DODAG. While storing DODAGs
have a lighter network impact than non-storing ones (due to the lack of source
routes), the PCE can control how much network bandwidth can be wasted by
malicious join nodes using the regular 6tisch mechanisms, and this can be tuned.
A second DODAG would be a sunk cost with no tuning possible.
</t>
</section>
<section title="create 6tisch track to form mesh-under">
<t>
This mechanism would use 6tisch tracks so that traffic from the JCE would be
switched from 6LBR to join node. A track would be required to each join
assistant. This is an optimized form of source routing.
</t>
<t>
This mechanism was not rejected, rather it was observed that it may be applied
to any mechanism that uses source routing, and is an optimization; it has a
certain cost in the form of intermediary node state, but that this state is
not created by a malicious join node, rather it is created by the PCE.
</t>
</section>
</section>
</section>
<section title="Join node discovery mechanism">
<t>
Continuing to work backwards, in order the JCE reach out to provision the Joining Node,
it needs to know that the new node is present. This is done by taking advantage of
the 6lowPAN
Address Resolution Option (ARO) (<xref target="RFC6775">section 4.1</xref>). The
ARO causes
the new address to also be sent up to the 6LBR for duplicate detection using the
DAR/DAC mechanism.
The 6LBR simply needs to tell the JCE about this. A new protocol may be required for
the situation where the JCE, PCE and 6LBR are not co-located; it may be that this
protocol could be simply a DAR in some encapsulation. The details of this are
currently out of scope for the architecture, as they affect interoperability
between different vendors of JCE/6LBR/PCE rather than interoperability between
the assistance/offload infrastructure, and the contrained nodes. Future work may
specify this part.
</t>
<t>
In addition to needing to know the joining devices address from the DAR/NS, the JCE
also needs to know the joining node's IDevID. This is to determine if the node
should even get any attention. At this point, the IDevID can be forged, it will be
authenticated during the setup of the 6top control protocol in the DTLS certificate
exchange.
If the serialNumber attribute of the IDevID is less than 64 bits, then it is possible
that it could be placed into the EUI-64 option of the ARO, or the OUI of the
<xref target="I-D.thubert-6lo-rfc6775-update-reqs"/> EARO. The JCE needs to know the
joining node's serialNumber to know if this is device that it should even attempt to
provision; and if so, it may need to retrieve an appropriate certificate chain
(see <xref target="I-D.richardson-6tisch-idevid-cert" />) from the Factory in order
for the JCE to prove it is the legitimate owner of the joining node.
</t>
<t>
Neither 802.1AR nor <xref target="RFC5280" /> provide any structure for the
serialNumber, except that they are positive integers of up-to 20 octets in size
(numbers up to 2^160).
This specification would require that the serialNumber encoded in the IDevID be the same
as the EUI-64 used by the device. Some consideration needs to be given as to whether
there are privacy considerations to doing this: any observer that can see the join
traffic, can also see the source MAC address of the node as well.
</t>
<t>
Prior to being able to announce itself in a NS, the joining node needs to find the
Join Network. This is done by listening to an extended beacon which are broadcast
in designated slotframes by Join Assistants. The Extended Beacon provides a way for
the Joining Node to synchronize itself to the overall timeslot schedule and provides
an Aloha period in which the Joining Node can send a Router Soliticiation, and receive
an appropriate Router Advertisement giving the
Joining Node a prefix and default route to which to send join traffic.
</t>
<t>
It may be possible to eliminate a message exchange if space for a Router
Advertisement can be found as part of the Join Network Extended Beacon.
This Enhanced Beacon would be distinct to
the Join Network, and would be encrypted with the well-known Join Network key.
</t>
<section title="prefixes to use for join traffic">
<t>
What prefix would the joining node for communication? There are three options:
<list style="format (%d)">
<t> just use link-local addresses (this may require that some traffic between
6LBR and JCE be IPIP tunneled)</t>
<t> use a prefix specifically for join traffic (may be easier with a
join-only DODAG)</t>
<t> use the same prefix as the rest of the traffic (may require more complex ACLs,
and leaks
information to attackers)</t>
</list>
</t>
<t> The simplest method is to use the link-local addresses for the 6top connection,
and the cost of an IPIP tunnel between the unconstrained 6LBR and the JCE is not
considered significant.
</t>
</section>
</section>
</section>
<!-- section 4 -->
<section title="security requirements">
<section title="threat model">
<t>There are three kinds of threats that a join process must deal with: threats to the
joining node, threats to the resources of the network, and threats to other joining nodes.
</t>
<section title="threats to the joining node">
<t>
A node may be taken out of it's box by a malicious entity and powered on. This could happen
during shipping, while being stored in a warehouse. The device may be subject to physical theft,
or the goal of the attacker may be to turn the device into a trojan horse of some kind. Physical
protection of the device is out of scope for this document; this document will henceforth assume
that the device is sealed in some tamper-evident way and this document deals with attacks over
the network.
</t>
<t>
An attacker may attempt to convince the joining node that it is the legitimate Production
Network; this is done by putting up a legitimate looking Join Network, and following the protocol
as described in this document. The Joining Node can not know if it has the corrrect Production
Network until steps 11-13, when it attempts to validate the ClientCertificate provided by
the JCE.
</t>
<t>
When the joining node determines that this is the incorrect network, it must remember the
PANID of the network that it has attempted to join, and then look for another network
to try. It SHOULD have some limit as the number of times it will try before going back
to sleep, or shutting down, and it SHOULD take care not to consume more than some specified
percentage of any battery it might have.
</t>
<t>
Should a malicious production network be present at the same time/place as the legitimate
production network, a the malicious agent could intercept and replay various packets from
the proper join network, but ultimately this either results in a jamming-like denial of service,
and/or the the ClientCertificate will not validate.
</t>
<t>
It is a legitimate situation for there to be multiple possible join networks, and the joining
node may have to try each one before it finds the network that it the right one for it.
The incorrect, but non-malicious networks will not attempt the 6top provisioning step, and
SHOULD return a negative result in steps 8/9, refusing the node's NS. Those incorrect networks
will be recognize that the node does not belong to them, because they will be able to see
the Joining Node's IDevID in the ARO of step 4.
</t>
</section>
<section title="threats to the resources of the network">
<t>
The production network has two important resources that may be attacked by malicious
Joining nodes: 1) energy/bandwidth, 2) memory for routing entries.
</t>
<t>
A malicious joining node could send many NS messages to the Join Assistant (from many made
up addresses), which would
send many NS/DAR messages to the 6LBR, and this would consume bandwidth, and therefore
energy from the members of the mesh along the path to the 6LBR. This can be mitigated
by limited the total bandwidth available for joining.
</t>
<t>
A malicious joining node could send many NS messages, and if the 6LBR agreed to accept the
new node (by IDevID), then the Join Assistant would MAY inject routing information into
mesh for the Joining node. Non-storing DODAGs store are routing information in the DODAG
Root (probably the 6LBR), which is generally not a constrained node. Storing DODAGs
store routing entries at all nodes up to the DODAG, and those are constrained nodes.
Using a separate Join DODAG, and having that DODAG be non-storing will reduce any impact
on intermediate nodes, but it does cause resources to be used for the second DODAG, and
it may have a code impact if the nodes otherwise would not implement non-storing RPL.
</t>
</section>
<section title="threats to other joining nodes">
<t>
A joining node (or the nodes of a malicious network, co-located near the legitimate production
network) may mount attacks on legitimate nodes which have not yet joined.
</t>
<t>
The malicious nodes may attempt to perform 6top operations against the joining node to keep
it from being able to respond to the legitimate 6top session from the legitimate JCE.
During the Join phase, the Joining node MUST have all other resources and protocols turned
off, even if they would normally be accessible as read-only unauthenticated CoAP resources.
</t>
<t>
Malicious nodes could use the Join Network to mount various DTLS based attacks against
the joining node, such as sending very long certificate chains to validate. One might think
to limit the length of such chains, but as shown in <xref target="I-D.richardson-6tisch-idevid-cert" />
the chain may as a long as the supplier chain, plus may include additional certificates due
to resales of plants/equipment/etc. Validating from a trusted certificate down to the
specific certificate which proves ownership would eliminate random certificate chains,
but the attacker could just feed the joining node legitimate chains that it observed
(and replayed) from the legitimate JCE. This does no good; the Joining node finds
that the DTLS connection is invalid, but it may significantly run batteries down.
</t>
</section>
</section>
<section title="implementation cost">
<t>(storage of security material, computational cost)</t>
</section>
<section title="denial of service">
<t>other communication impacts of security protocol mechanics</t>
</section>
</section>
<!-- section 5 -->
<section title="protocol requirements/constraints/assumptions">
<t/>
<section title="inline/offline">
<t>dependencies on centralized or external functionality, inline and
offline</t>
</section>
</section>
<section title="time sequence diagram" anchor="tsd">
<t>
<figure align="center" anchor="TimeSequenceJoin"
title="Message sequence for JOIN message">
<preamble/>
<artwork align="left">
<![CDATA[
+-----+ +------+ +----------+ +-----------+
| | | | | JOIN | | Joining |
| JCE | | 6LBR | | Assistant| | Node |
+-----+ +------+ | (proxy) | | |
| | +----------+ +-----------+
| | | |
| | |-------BEACON (1)---------->|
| | | |
| | |<----Router Solicitation----|
| | |---Router Advertisement---->|
| | | |
| | |<------CERT CACHE-----------|
| | | LOAD (2) |
| | | |
| | | |
| | |-------CERT CACHE---------->|
| | | RESPONSE (multiple) |
| | | (packets) |
| | | |
| | |<-----JOIN REQUEST (4) -----|
| | | (NS w/ARO ) |
| | | |
| |<---NS (DAR) (5)-----| |
|<--??(6)-| | |
| | | |
|--??(7)->| | |
| | | |
| |----NS (DAC)-(8)---->| |
| | +------+ | |
| |<DAO-| mesh |<--DAO--| |
| |-DAO-| node |--DACK->| |
| | ACK +------+ | |
| | |-------JOIN ACK (9)-------->|
| | | |
| | | |
|================(10)==========>|----------6top----(11)----->|
| | | DTLS |
|<===============(13)===========|<---------CoAP----(12)------|
| | | (many packets) |
]]>
</artwork>
<postamble/>
</figure>
</t>
<section title="explanation of each step">
<t/>
<section title="step (1): enhanced beacon">
<t>A 6tisch join/synchronization beacon is broadcast periodically,
and is authenticated with a symmetric “beacon key”:<list>
<t>well known JOIN key, such "JOIN6TISCH"</t>
<t>another key, provisioned in advance (OOB)</t>
<t>a shared symmetric key derived from public part of top level
certificate (a closely held "secret")</t>
</list>The purpose of this key is not to provide a high level of
assurance, but rather to filter out 6tisch traffic from another
random traffic that may be sharing the same radio frequencies.</t>
<t>These beacons are used for JOIN purpose only, and are not related
to the Enhanced Beacons used in the rest of 6tisch.</t>
</section>
<section title="step (1B): send router solicitation">
<t>
The joining node sends a router solicitation during the Aloha
period of the beacon.
</t>
</section>
<section title="step (1C): receive router advertisement">
<t>
The joining node receives a router advertisement from the
Join Assistant. It could include 6CO options to help compress
packets, and should contain a prefix appropriate for join traffic.
</t>
</section>
<section title="step (2): certificate cache load">
<t>At step 10, the JCE will need to present a certificate chain
anchored at a trusted CA built into the joining node.
It has been speculated that a significant amount of traffic could
be avoided at step (10) if the common parts of the certificate chains
could be cached in the join assistant.
</t>
<t>
This optional step involves the joining node asking for certificates
from the join assistant.
</t>
</section>
<section title="step (3): receive certificate cache">
<t>the proxy neighbour sends requested cached certificates to the
joining node
</t>
</section>
<section title="step (4): join request">
<t>A regular Neighbour Solicitation is sent. This should contain an ARO
(or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO will be
proxied by the Join Assistant as part of normal 6LowPAN processing for leaf
nodes (non-RPL nodes) upwards to the 6LBR</t>
</section>
<section title="step (5): NS duplicate address request (DAR)">
<t></t>
</section>
<section title="step (7): 6LBR informs JCE of new node">
<t></t>
</section>
<section title="step (8): JCE informs/acks to 6LBR of new node">
<t>The JCE could reply in the negative, and this would cause a DAC failure, TBD</t>
</section>
<section title="step (9): NS duplicate address confirmation (DAC)">
<t></t>
</section>
<section title="step (10): JCE initiates connection to joining node">
<t>The double lines indicate that an IPIP tunnel operation may be required.
If a straight DAO or seperate Join DODAG is used, then this is just a straight
forwarding root to leaf node forwarding operation, and involves either
using source routes (non-storing), or just forwarding for storing DODAGs.
</t>
<t>A specific bandwidth allocation would be used for this join traffic</t>
<t>The production network encryption keys would be used for the join traffic</t>
</section>
<section title="step (11): Join Assistant forwards packet to joining node">
<t>The JOIN Assistant would forward traffic to the Joining Node. Recognizing
that this traffic the JOIN Network, the JOIN Assistant would use the JOIN
Network key.</t>
</section>
<section title="step (12): Joining node replies">
<t>The joining node replies, using JOIN Network key.
</t>
</section>
<section title="step (13): Join Assistant forwards reply to JCE">
<t>
The JOIN Assistant, recognizing that the traffic came from the JOIN
Network, restricts the destination that can be reached to the
the JCE only. It can do this in a stateless way, and it does NOT
need to track the traffic at (10) to open pinhole, etc.
</t>
<t>Recognizing that the traffic came from the JOIN Network, the
traffic would be placed into a bandwidth allocation (track?) that
allows such traffic.
</t>
</section>
</section>
<section title="size of each packet">
<t>and number of frames needed to contain it.</t>
</section>
</section>
<section title="resulting security properties obtained from this process">
<t>
An end to end IPv6 CoAP/DTLS connection is created between the JCE and the
Joining Node. This connection carries 6top commands to update security
parameters. This results in either deployment of a single-level, locally
relevant certificate (LDevID), or deployment of a network-wide symmetric "Master Key"
</t>
</section>
<section title="deployment scenarios underlying protocol requirements">
<t/>
</section>
<section title="device identification">
<t>
The JCE authenticates the joining node using a certificate chain provided inline during the
DTLS negotiation. The certificate chain is rooted in a vendor certificate that the JCE
must have preloaded, and is a statement as to the node's 802.1AR IDevID.
The joining node authenticates the
</t>
<section title="PCE/Proxy vs Node identification">
<t/>
</section>
<section title="Time source authentication / time validation">
<t>Note: RPL Root authentication is a chartered item</t>
</section>
<section title="description of certificate contents">
<t/>
</section>
<section title="privacy aspects">
<t>
The EUI-64 of the Joining node is transmitted using a Well Known layer-2 encryption key.
Within the ARO/EARO of the Neighbour Solicitation is an OUI, which may be identical
to the EUI-64 of the Joining node, or it might be an unrelated IDevID.
</t>
<t>
An eavesdropper can therefore learn something about the manufacturer of every device
as it joins.
</t>
</section>
</section>
<!-- section 10 -->
<section title="slotframes to be used during join">
<t>how is this communicated in the (extended) beacon.</t>
</section>
<section title="configuration aspects">
<t>(allocation of slotframes after join, network statistics,
neighboetc.)</t>
</section>
<section title="authorization aspects">
<t>lifecycle (key management, trust management)</t>
<section title="how to determine a proxy/PCE from a end node">
<t/>
</section>
<section title="security considerations">
<t>what prevents a node from transmitting when it is not their turn
(part one: jamming)</t>
<t>can a node successfully communicate with a peer at a time when not
supposed to, may be tied to link layer security, or will it be policed
by receiver?</t>
</section>
</section>
<!-- section 13 -->
<section title="security architecture">
<t>security architecture and fit of e.g. join protocol and provisioning
into this</t>
</section>
<section title="Posture Maintenance">
<t>(SACM related work)</t>
</section>
<section title="Security Considerations">
<t/>
</section>
<section title="Other Related Protocols"/>
<section title="IANA Considerations">
<t/>
</section>
<section title="Acknowledgements"/>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.6550" ?>
<?rfc include="reference.RFC.6775" ?>
&IEEE8021AR;
<?rfc include="reference.I-D.ietf-6tisch-coap" ?>
<?rfc include="reference.I-D.ietf-6tisch-6top-interface" ?>
<?rfc include="reference.I-D.ietf-6tisch-architecture" ?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions" ?>
<?rfc include="reference.I-D.seitz-ace-problem-description" ?>
<?rfc include="reference.I-D.richardson-6tisch-idevid-cert" ?>
<?rfc include="reference.I-D.wang-6tisch-6top-sublayer" ?>
<?ref include="reference.I-D.thubert-6lo-rfc6775-update-reqs" ?>
</references>
<references title="Informative references">
<?rfc include="reference.RFC.5280" ?>
<?rfc include="reference.RFC.7252" ?>
<?rfc include="reference.RFC.6347" ?>
<?rfc include="reference.I-D.thubert-6lowpan-backbone-router" ?>
<?rfc include="reference.I-D.ietf-netconf-zerotouch" ?>
<?rfc include="reference.I-D.kelsey-intarea-mesh-link-establishment" ?>
<?rfc include="reference.I-D.ohba-6tisch-security" ?>
<?rfc include="reference.I-D.piro-6tisch-security-issues" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 00:16:10 |