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

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

Hello Pascal,

Thanks, this text is fine by me.

Mališa

> On 27 Jun 2019, at 14:06, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> 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/ <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 <https://www.ietf.org/mailman/listinfo/6tisch>
>  
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch