Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

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

(snip)

On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen <[e-mail]> wrote:

>
> I would like at least some text in the security considerations section
> warning about the common wrong ways of generating PSK. The IoT vendors
> are quite often care more about the time to market than the security,
> thus do use unsafe practices as they do not know better.
>

That's fine for me. I will get back to you with specific text/commit when I
implement this.


>
> >     In section 5.3.2 there is text saying:
> >
> >                                 The JP operates as the application-
> >        layer proxy, and does not keep any state to forward the message.
> >
> >     This is not completely true. It needs to keep state to know when the
> >     pledge starts joining process and it needs to keep it until the
> pledge
> >     finishes it as it needs to allow pledge to send unencrypted and
> >     unauthenticated frames through it as explained in section 6.
> >
> >     I.e., JP do store state for each pledge, at least for the secExempt.
> >     Also during this phase the pledge will be using its extended address,
> >     so that is also used by the JP to know which pledges are in progess
> of
> >     joining.
> >
> > The point that you bring up here is essentially an implementation
> > decision. There is nothing that prevents a JP from creating an
> > ephemeral unsecured ND entry and setting secExempt for it in MAC
> > security tables once JP receives a CoAP response with
> > Stateless-Proxy option set. The value of Stateless-Proxy option is a
> > byte string meaningful only to the JP, so JP can encode there
> > whatever it may need to operate statelessly. Off the top of my head,
> > I don't really see what else it would need to transport in
> > Stateless-Proxy except for the pledge's EUI-64.
>
> Actually if you follow the 802.15.4 and someone sends you unsecured
> frame the security processing will reject it with
> IMPROPER_SECURITY_LEVEL error (section 9.2.4 f) of 802.15.4-2015). The
> MAC will then indicate (section 6.7.2) this to the upper layer with
> MLME-COMM-STATUS.indication primitive which will get the addresses
> etc, but does not get the actual frame. Then the upper layer can
> install the secExempt flag in the security tables (== creates state),
> and then next packet from the same node will be allowed to go through
> the security processing. So there is always some state stored, just to
> be able to receive the unprotected frame.
>
> Note, that node is allowed NOT to ack the incoming frame if the
> security processing fails, so this second frame will be MAC layer
> retransmit, not upper layer retransmit.
>

Assumption (1): JP has the information that the join process is *allowed*.
I see this as a centralized decision, JP simply enforces it.

Assumption (2): JP removes all the state about the pledge, including L2
security table entry with secExempt set, as soon as it forwards a packet
originating from the pledge towards the JRC.

Assumption (3): JP adds an entry with secExempt set for the pledge as soon
as it receives a Stateless-Proxy. Issue: When does JP remove this entry?
See below.

You seem to agree that there is no problem for the frames going from JP to
the pledge. Right?

The issue you raise on keeping state at JP is to allow the pledge to sends
frame(s) to the JP.

Let me try to summarize:

(1) The very first frame sent by the pledge, in a fully-compliant
implementation of 802.15.4 security processing gets rejected no matter
what. A logical choice for the JP is then *not* to ACK this frame at L2.

(2) Upper layer of JP then adds an entry for the source address of the
rejected frame and sets the secExempt for it. (because join process is
allowed)

(3) L2 retransmission of the frame dropped in (1) is sent by the pledge.
The frame falls into the secExempt case while processing at JP and is
passed to the upper layer.

(4) JP keeps the entry with secExempt (i.e. state) *until* an upper layer
creates a packet destined for the JRC with Stateless-Proxy set. In that
moment, no more state for the pledge exists at JP. Issue: CoAP message sent
by the pledge is malformed and JP discards it, DoS attack where pledge does
ND but does not send Join Request. It would therefore be prudent to expire
this entry at JP after a short timeout.

For the upper-layer protocol, this seems to degrade performance in case a
pledge generates a frame  *after* JP has already forwarded one packet from
the pledge to the JRC and used Stateless-Proxy. In that case, pledge will
need to do one L2 retransmission to get the packet processed by JP. Agreed?

For CoJP, this will be the case for CoAP-layer (CoJP-layer to be precise)
retransmissions. You are also worried for future extensions where pledge
sends more than one *packet* (multiple L2 fragments are OK) before getting
a response from the JP.

The question now is when to remove the entry with secExempt for pledge at
JP, once it was installed from Stateless-Proxy. From the security point of
view, the easiest is to remove it immediately once L2 ACK from the pledge
is received at JP, but this will degrade performance in case of future
extensions where there are more messages in the protocol before join
completes as the first corresponding frame from the pledge to the JP will
need to be retransmitted.

What do you think?



> > Regarding the point that JP needs to know which pledges are in
> > progress of joining, I don't see why this is at all relevant to the
> > JP. JP simply forwards everything that it receives into the network
> > (bandwidth caps assumed), for "the duration of the join process".
> > Now, the last part is a bit tricky as the network needs to propagate
> > coordinator's decision whether joining is permitted. See below.
>
> JP needs to know when it can clear the secExempt flag for the node in
> the security tables. If it does not clear it, then it will attackers
> to send clear text packets claiming to come from the joining node,
> even after it has already joined, and should have installed the keys.
>
> Normally this is done when the JP would install pairwise keys for the
> joining node, but in this case I think we global keys which means
> there is no pairwise keys, but clearing the secExempt is still
> important.
>

See above.


>
> Note, that we most likely do want to keep it until the node actually
> finishes the join process, and not for just one frame, just in case in
> the future the joining process takes more than one round trip.
>

Yes, I see your point. This seems to be a performance vs security tradeoff,
i.e.:

(A) do we want to degrade performance with one L2 retransmission of the
first frame coming from the pledge when JP does not have an entry, in order
to reduce DoS space at JP.

(B) keep this state at JP for the whole duration of the join process of a
pledge.

Consider that the DoS metric of importance is the number of pledges that
can join over a single JP: N / T, where N is the number of insecure entries
for pledges at JP, and T is the time JP has to keep them.
- N is the same both in (A) and (B).
- In (A), T is the worst-case timeout in case of an attack where JP needs
to expire the entry, because pledge did not send conformant traffic to JRC
in due time. Say a couple of seconds.
- In (B), T is the duration of the join process of a pledge. Much greater
than a couple of seconds with multiple hops to 6LBR, and JRC in the cloud.
With multiple pledges joining and contending for the minimal cell, this is
on the order of several minutes [1].

Finally, while I understand that there are vendors out there that sell
closed implementations of 802.15.4 MAC where the behavior that you describe
of having to reject a frame before adding an entry in the security table is
set in stone, please note that there are also many implementations out
there, e.g. Contiki, Contiki-NG, OpenWSN, RIOT, and also proprietary ones
that I personally worked on, where this is easily implemented without *any*
performance hits. With that, JP can process once the frame, see that it
doesn't pass security processing, but add a special check if the join
process is ongoing so that the frame should be passed to the upper layer.
There, we get increased security without any performance hits.

[1] Broadcasting strategies in 6TiSCH networks:
http://ckan.iotlab.eu/dataset/3b96c98c-b5a4-4153-82ee-6c7cd6707232/resource/68289058-b646-441f-b37a-c138fa25549f/download/broadcasting-strategies-in-6tisch-networks.pdf


> I.e., thats why I think perhaps the messages from the JRC should have
> also something that the JP can check to see whether the joining
> process of the joining node is finished and successful (meaning that
> after sending that frame to the joining node, it can remove secExempt
> and ND entries for the node), or whether it failed (in which case it
> can blacklist the node, so no new joining process can be retried for
> next n minutes or hours etc).
>

I agree with you on the blacklisting part, see below. I don't agree on
adding signaling to JP, as explained above.


> On the other hand blacklisting someone who has failed joining process
> is also good idea, but this stateless method does not allow it and
> then one joining node which have any kind of misconfuguration will
> simply consume network resources all the time, with repeated tries to
> join the network.
>

While blacklisting does not add much in terms of security, as source
addresses can be spoofed,  I agree that it's beneficial to have
blacklisting as a feature in case of misconfiguration, for performance
reasons. I think that the JRC should be the one who decides if a given
address should be blacklisted, from the amount of traffic it receives and
other information it possesses.

How about we add a CoJP parameter "blacklist" that can be signaled in
Parameter Update Request messages that carries a list of blacklisted
addresses. The JRC sends this at any time to JP(s) over their secure
channel, and JP can then filter these frames in hardware for example, since
many chips support this already. What do you think?


> > JP does not need to match the long address of a given pledge to the
> > newly assigned short address. The L2 nonce is constructed from the
> > short address and PAN ID, no?
>
> Nonce can be constructed using short address, but security tables do
> require extended address also. See table 9-14 of the 802.15.4-2015.
> I.e., extended address is always needed, short address can have value
> 0xfffe or 0xffff if they are not used or known.
>
> There is no text in the 802.15.4 that would lift that requirement for
> the TSCH, i.e. extended address is always needed for security. That is
> the primary key for the node. The table 9-14 is used to map the short
> address to extended address (think it as arp table).
>

Consider nodes A and B, neighbors, both are aware of each other's short
addresses. Group security keys used, i.e. index mode.

You are essentially saying that even though nodes A and B do not need each
other's extended addresses for any interoperability or security relevant
reason, they need to store this information in their memory. Not ideal..

On the other hand node only need to know extended and short address
> for nodes it is talking to, so if there is some other mechanism to get
> them that is fine.
>

Yes, all of this happens once the pledge joined and obtained the group
key(s).We could maybe use ND for this purpose but how neighbor nodes
discover and map their extended addresses to short seems definitely out of
scope of minimal-security.


> Note, that TSCH mode is a mode than can be turned on/off in the
> 802.15.4 device, and the security still needs to be work, so even if
> the node would be able to do security with only short addresses when
> TschMode is turned on, it cannot do that when TschMode is turned off.
> The security is written so it works regardless whether TschMode is on
> or off.


> On the other hand there is nonce collision possibility if same key is
> used when TschMode is off and TschMode is on, as TschMode on uses ASN
> in nonce and TschMode off uses frame counter and security level. In
> theory there could be combination that causes collision, so there
> might be need to add text to the 802.15.4 that says that node shall
> not use same keys for both modes.
>

I am not sure I fully understand how this would work. Network A is a TSCH
network. Pledge joins network A. Pledge decides to switch off TSCH mode.
Won't it need to join another network (i.e. beacon-enabled, CSMA), with a
completely different set of keys then?


>     Also outsiders
> >     can also do the same guess, so they will be able to coordinate the
> >     short address 0x0010 to the extended address quite easily, even when
> >     the section 11 claims otherwise.
> >
> > I see this as a privacy concern, where based on the timing, an
> > attacker would be able to correlate an extended address of the
> > pledge with the short address. Do you have a proposal on how we
> > could tackle this?
>
> No. I think privacy concerns are so hard that we cannot solve them. We
> can help them by doing things we do here, i.e., assigning short
> addresses which are transmitted in encrypted format, but that does not
> solve the problem, it just makes it harder. I think that is only thing
> we can do, but we should not try to claim this solves the problem.
>

If I rephrase the Privacy Considerations text adding something like:

 "Note that an eavesdropper with access to the radio medium during the join
process is able to correlate the assigned short address with the extended
address based on timing information with a non-negligable probability. This
probability decreases with an increasing number of pledges joining
concurrently."

and relax the statement that the assignment of short addresses "mitigates"
the risks to "reduces", would that be OK for you?


> >     In section 9.3.2.2 there is text saying that "short address is unique
> >     LOCALLY in the network". This is incorrect. It needs to be unique in
> >     the whole network using the same key, i.e., globally in the network
> >     using the same key and part of the same TSCH network. I know that
> some
> >     vendors have been using duplicate short addresses for different parts
> >     of the network, when there is no risk of them overhearing each other
> >     for other 802.15.4 networks, but that is not safe to do in TSCH when
> >     short addresses are used in the nonce.
> >
> > Good point. I will add this to security considerations.
>
> This of course also means that short addresses cannot be generated by
> hashing of the extended address or similar means locallly and then
> sending out neighbor discovery to see if someone is using that
> address, and if so regenerate new one. The node using the same short
> address might not be in radio range, or might be sleepign etc.
>
> So it is really important that short addresses are always assigned by
> JRC and JRC takes care of them being unique.
>

Good point, will get back to you with text/commit when I implement this.