Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

["Pascal Thubert (pthubert)" <[e-mail]>]

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ć <[e-mail]>
Sent: jeudi 27 juin 2019 12:48
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]; Tero Kivinen <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael Richardson
Sent: mercredi 26 juin 2019 17:49
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tero
Kivinen <[e-mail]<mailto:[e-mail]>>
Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21


Mališa Vučinić <[e-mail]<mailto:[e-mail]>> wrote:

Mališa Vučinić <[e-mail]<mailto:[e-mail]>> 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   [
]     [e-mail]<mailto:[e-mail]>  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works  -
= IPv6 IoT consulting =-


_______________________________________________
6tisch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch