Hello Malisa
Please find below the proposed text; note that last paragraph is commented out
to leave space for minimal to complete the story.
<t>
The operation of 6TiSCH Tracks inherits its high level operation from DetNet
and is subject to the observations in section 5 of
<xref target="I-D.ietf-detnet-architecture"/>. As discussed there, measures
must be taken to protect the time synchronization, and for 6TiSCH this
includes ensuring that the Absolute Slot Number (ASN), which is used as ever
incrementing counter for the computation of the Link-Layer security nonce,
is not compromised, more below on this. Also, the installation and the
maintenance of the 6TiSCH Tracks depends on the availability of a controller
with a PCE to compute and push them in the network. When that connectivity
is lost, existing Tracks may continue to operate until the end of their
lifetime, but cannot be removed or updated, and new Tracks cannot be
installed. As with DetNet in general, the communication with the PCE must be
secured and should be protected against DoS attacks, and the discussion on
the security considerations defined for Abstraction and Control of Traffic
Engineered Networks (ACTN) in Section 9 of <xref target="RFC8453"/>, applies
equally to 6TiSCH.
</t>
<t>
In a TSCH network as specified by
<xref target="IEEE802154">IEEE Std. 802.15.4</xref>, the nonce that is used
to secure Link-Layer frames includes an address of the source and the ASN.
The ASN itself is supposed to be distributed securely by other means. With
TSCH, the ASN is included in the CCM* nonce for the computation of the
Message Integrity Code (MIC), but it is only implicit in the data frames.
This is not considered as a complete replay protection and upper layer
protocols must provide a way to detect duplicates and cope with them.
</t>
<t>
If the receiver and the sender have a different sense of ASN, the MIC will
not validate and the frame will be dropped. In that sense, TSCH induces an
event horizon whereby only nodes that have a common sense of ASN can talk to
one another in an authenticated manner. With 6TiSCH, the pledge discovers a
tentative ASN in beacons from nodes that have already joined the network.
But even if the beacon can be authenticated, the ASN cannot be trusted as it
could be a replay by an attacker and thus could announce an ASN that
represents a time in the past. If the pledge uses an ASN that is learned
from a replayed beacon for an encrypted transmission, a nonce-reuse attack
becomes possible and the network keys may be compromised.
</t>
<t>
Time Synchronization in TSCH induces another event horizon whereby a node
will only communicate with another node if they are synchronized within a
guard time. The pledge discovers the synchronization of the network based
on the time of reception of the beacon. If an attacker synchronizes a pledge
outside of the guard time of the legitimate nodes then the pledge will never
see a legitimate beacon and may not discover the attack.
</t>
<t>
After obtaining the tentative ASN, the pledge authenticates itself to the
network using some mechanism outside of IEEE Std. 802.15.4. With 6TiSCH,
a Join Proxy (JP) helps the pledge for the join procedure by relaying the
link-scope Join Request over the IP network to a Join Registrar/Coordinator
(JRC) that can authenticate the pledge and validate that it is attached to
the appropriate network. As a result of this exchange the pledge is in
possession of a Link-Layer material including keys and a short address, and
if the ASN is known to be correct, all traffic can now be secured using CCM*
at the Link-Layer.
</t>
<t>
The authentication steps must be such that they cannot be replayed by an
attacker, and they must not depend on the tentative ASN being valid.
During the authentication, the keying material that the pledge obtains from
the JRC does not provide protection against spoofed ASN. Once the pledge has
obtained the keys to use in the network, it may still need to verify the
ASN.
If the nonce used in the Layer-2 security derives from the extended (MAC-64)
address, then replaying the ASN alone cannot enable a nonce-reuse attack
unless the same node is lost its state with a previous ASN. But
if the nonce derives from the short address (e.g., assigned by the JRC) then
the JRC must ensure that it never assigns short addresses that were already
given to this or other nodes with the same keys. In other words, the network
must be rekeyed before the JRC runs out of short addresses.
</t>
<t>
These issues is are discussed in more details in
<xref target="I-D.ietf-6tisch-minimal-security"/>.
</t>
<!--t>
Once the node obtains the keys from the JRC, an additional step may be
required to ensure that the ASN is correct before encrypting any message.
If the ASN is not guaranteed to be correct by other means, the pledge should
perform a non-replayable exchange (e.g., using a nonce in the payload that
does not derive from ASN) with a peer node that is trusted and has already
joined (e.g., the JP or a RPL time parent). The request by the pledge should
not be encrypted at the Link-Layer but only authenticated to avoid
nonce-replay attacks. A successful authenticated exchange proves a common
sense of ASN and encrypted traffic can now happen.
</t-->
All the best,
Pascal
From: Mališa Vučinić <[email protected]>
Sent: jeudi 27 juin 2019 12:48
To: Pascal Thubert (pthubert) <[email protected]>
Cc: Michael Richardson <[email protected]>; [email protected]; Tero Kivinen
<[email protected]>
Subject: Re: [6tisch] [secdir] secdir review of
draft-ietf-6tisch-architecture-21
Pascal,
Before the pledge selects a JP, the text from RFC8180 that is relevant seems to
be (Section 6.2):
When a node joins a network, it may hear EBs sent by different nodes
already in the network. The decision of which neighbor to
synchronize to (e.g., which neighbor becomes the node's initial time-
source neighbor) is implementation specific. For example, after
having received the first EB, a node MAY listen for at most
MAX_EB_DELAY seconds until it has received EBs from
NUM_NEIGHBOURS_TO_WAIT distinct neighbors. Recommended values for
MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5.
When receiving EBs from distinct neighbors, the node MAY use the Join
Metric field in each EB to select the initial time-source neighbor,
as described in Section
6.3.6<https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4
[IEEE.802.15.4<https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>].
To me, this text is ambiguous on whether the pledge should duty cycle its radio
according to the schedule found in the first received EB. In case the pledge
does not duty cycle its radio upon receiving the first EB that happens to be a
replay, the attacker cannot really desync the pledge due to its radio being on
100% of the time waiting for additional beacons. Eventually, as Michael noted,
one fresh EB will arrive from a legitimate node with a higher ASN, at which
point it becomes critical for the pledge to select the JP with the largest
available ASN for a given advertised PAN ID. I believe this text deserves
expanded discussion in the Security Considerations of minimal-security but I am
not convinced on the need for a special mechanism to exchange/sign the ASN.
Mališa
On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> wrote:
Hello Michael
Both ASN and sync create event horizons.
* A wrong ASN will cause MIC processing to fail and the packet will be ignored.
* If an attacker syncs a pledge outside of the network sync's beyond guard
time, the pledge will not even see that legitimate nodes are sending.
In both cases, a node that believes an attacker has no way to validate ASN
right there. It needs an additional one-hop authenticated exchange with a
legitimate node with a, e.g., random nonce in payload. Some people will want
that step even if the window is narrow. I think we should describe it in archie
and in minimal sec.
6P or MSF could be used for that purpose when present but cannot be the only
way since they are optional.
All the best,
Pascal
-----Original Message-----
From: 6tisch <[email protected]<mailto:[email protected]>> On
Behalf Of Michael Richardson
Sent: mercredi 26 juin 2019 17:49
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?=
<[email protected]<mailto:[email protected]>>
Cc: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Tero
Kivinen <[email protected]<mailto:[email protected]>>
Subject: Re: [6tisch] [secdir] secdir review of
draft-ietf-6tisch-architecture-21
Mališa Vučinić <[email protected]<mailto:[email protected]>> wrote:
Mališa Vučinić <[email protected]<mailto:[email protected]>> wrote:
Instead, as with traditional TSCH, the joined node can obtain its time
information from its time source neighbor, i.e. RPL preferred parent,
by triggering an exchange of link-layer frames with L2 security
features enabled. The MSF draft already mandates that the first
outgoing message from the joined node after joining is the 6P ADD
message to its preferred parent, which consequently gets protected
with
L2 security.
But, how can the L2-security work if the newly-joined node has an
ancient
ASN? Won't the parent just drop the packet as being a replay, and then
what?
Yes, so the node will desynchronize eventually, fall out of network and
restart the join process, hopefully with a different network.
hmm. Or, it sees a new beacon, which it can integrity check, and then sees
the ASN jump forward. This would be the same as if it had slept for awhile.
Unless the attacker can continuously *block* the node from seeing the latest
beacons, and continuously feeds it old beacons, the problem should go away.
So maybe this is really not as a big a deal as I thought.
What needs to be specified clearly is that this first 6P
exchange should not be encrypted but only authenticated at L2.
Upon successful completion of the first 6P exchange with its time
(routing)
parent, the joined node obtains a negotiated cell and as a side effect
proves freshness of the ASN used.
I'd rather that we added a new exchange, rather than special casing some
6P
interaction here. An RPL DIS would be a better choice here, I think, with
an RPL DAO unicast reply. Still, I hate to special case this as being
authenticated only.
Doesn't that have to happen first?
Whatever packet we send here, be it DIS or 6P, they need to have
special handling in terms of L2 security… Is DIS mandatory to send upon
preferred parent selection?
I think that we can do nothing.
Maybe the replayed beacon attack (and solution: wait for another beacon)
belongs in the Security Considerations of the Architecture.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected]<mailto:[email protected]> http://www.sandelman.ca/
| ruby on rails [
--
Michael Richardson <[email protected]<mailto:[email protected]>>,
Sandelman Software Works -
= IPv6 IoT consulting =-
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
