Hello Pascal, Thanks, this text is fine by me.
Mališa > On 27 Jun 2019, at 14:06, Pascal Thubert (pthubert) <pthub...@cisco.com> > 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ć <malisa.vuci...@inria.fr> > Sent: jeudi 27 juin 2019 12:48 > To: Pascal Thubert (pthubert) <pthub...@cisco.com> > Cc: Michael Richardson <mcr+i...@sandelman.ca>; 6tisch@ietf.org; Tero Kivinen > <kivi...@iki.fi> > 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) <pthub...@cisco.com > <mailto:pthub...@cisco.com>> 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 <6tisch-boun...@ietf.org <mailto:6tisch-boun...@ietf.org>> On > Behalf Of Michael Richardson > Sent: mercredi 26 juin 2019 17:49 > To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malis...@gmail.com > <mailto:malis...@gmail.com>> > Cc: Pascal Thubert (pthubert) <pthub...@cisco.com > <mailto:pthub...@cisco.com>>; 6tisch@ietf.org <mailto:6tisch@ietf.org>; Tero > Kivinen <kivi...@iki.fi <mailto:kivi...@iki.fi>> > Subject: Re: [6tisch] [secdir] secdir review of > draft-ietf-6tisch-architecture-21 > > > Mališa Vučinić <malis...@gmail.com <mailto:malis...@gmail.com>> wrote: > > Mališa Vučinić <malis...@gmail.com <mailto:malis...@gmail.com>> 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 [ > ] m...@sandelman.ca <mailto:m...@sandelman.ca> http://www.sandelman.ca/ > <http://www.sandelman.ca/> | ruby on rails [ > > > -- > Michael Richardson <mcr+i...@sandelman.ca <mailto:mcr+i...@sandelman.ca>>, > Sandelman Software Works - > = IPv6 IoT consulting =- > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org <mailto:6tisch@ietf.org> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
