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

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

Hi Tero,

Thank you for this extensive review! See my responses inline.

Mališa

On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen <[e-mail]> wrote:

> In section 3 there is text saying:
>
>    The "network identifier" uniquely identifies the 6TiSCH network in
>    the namespace managed by a JRC.  Typically, this is the 16-bit
>    Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
>
> Note, that the PAN ID is not stable. The PAN coordinator is expected
> to change to use new PAN ID if it detect another network using the
> same PAN ID, i.e., if there is PAN ID conflict. See section 6.3.2 of
> the IEEE 802.15.4-2015.
>
> Because of this it might be better to use something else as PAN ID if
> stable network identifier is needed. Also in quite many cases the PAN
> ID is not known beforehand, so configuring the PAN ID to the pledge is
> challenging, as is describied in the section 4.
>
> Using something like Network ID from the
> draft-richardson-6tisch-enrollment-enhanced-beacon, would provide
> better alternative.
>

Good point: we use the term "network_identifier" for precisely this purpose
-- allow future extensions where an extended ID from e.g.
draft-richardson-6tisch-enrollment-enhanced-beacon can be used. The current
text in the draft leaves open what ID is actually used, and as such PAN ID
is supported. I wouldn't want to preclude the use of PAN ID now, since this
is how most of the people currently deploy their networks.

Would a following resolution work for you:

OLD:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4]. Companion documents can specify the use of a
different network identifier for join purposes, but this is out of scope of
this specification.  Such identifier needs to be carried within Enhanced
Beacon (EB) frames.

NEW:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4].  *However, PAN ID is not considered a stable
network identifier as it may change during network lifetime if a collision
with another network is detected.* Companion documents can specify the use
of a different network identifier for join purposes, but this is out of
scope of this specification.  Such identifier needs to be carried within
Enhanced Beacon (EB) frames.

In section 4 there is text saying:
>
>     o Pre-Shared Key (PSK).  The JRC additionally needs to store the
>       pledge identifier bound to the given PSK.  The PSK SHOULD be at
>       least 128 bits in length, generated uniformly at random.  It is
>       RECOMMENDED to generate the PSK with a cryptographically secure
>       pseudorandom number generator.  Each (6LBR) pledge SHOULD be
>       provisioned with a unique PSK.
>
> This text is fine, but knowing that most of the vendors in this space
> have been known to use unsafe methods like scrambling, encrypting,
> hashing, or macing serial number or EUI-64 address to generate "random
> unique PSKs" (or simply using fixed PSK for all devices), it might be
> good idea to provide bit more emphasis on the unique properly
> generated PSK, even when it is outside the actual scope of this
> document. Or add something like that to the security considerations
> section.
>

Göran Selander also raised an issue about this text. My response was:

> I would like to avoid referencing any particular method of generating the
PSK, I think that it would be enough to stress that the PSK that ends up
being provisioned to the pledge should meet certain statistical properties
(e.g. unpredictability, entropy).

Is this OK for you?


> In section 5.2 there is text saying "How JP accepts these unprotected
> frames is discussed in Section 6. ", but this same thing also applies
> to the section 5.3.1 too. I.e., the Join request from the pledge to JP
> is also unauthenticated and unencrypted.
>
> Perhaps that should be noted also there.
>

Sounds good.

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.

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.


> Also section 7 says that JP does keep separate neighbor cache for
> untrusted entries, so that is even more state it will keep...
>

In fact, we were quite close on removing the need for ND between the pledge
and the JP but it was finally deemed to risky in terms of compliance with
IPv6 specs.

The current configuration in the draft mandates that insecure and secure
caches are separated. JP can implement this as a single insecure entry,
that is ephemerally instantiated every time a Join Response is received
from JRC with Stateless-Proxy set, as discussed above. In this case, if N
pledges join over a single JP, no more than a single entry at a time needs
to be filled, reducing significantly the DoS space.


> In section 6 there is text saying:
>
>
>                                            How the JP learns
>    whether the join process is ongoing is out of scope of this
>    specification.
>
> This is very important part of the process, and I think it should be
> part of this document, and not out of scope for this document. Which
> document will specify this if not this?
>

I brought up this comment as part of my IETF102 presentation. We discussed
the issue during IETF98 in Prague.

Essentially, we need to signal in EBs whether the join process is ongoing
and to propagate this information from DAG root downwards. One proposal at
IETF98 was to (ab)use one value of the Join Metric, e.g. 0xFF, for
signaling that join is not permitted. When a JP sees Join Metric == 0xFF in
the EB of its RPL preferred parent, it diffuses it in the EBs it generates
itself.

It was deemed better to define a special IE that would carry this and other
potentially useful information. Michael has been leading this work ever
since with draft-richardson-6tisch-enrollment-enhanced-beacon, and I think
"proxy prio" serves this purpose.

The basic idea was to allow for e.g. a button press on the DAG root that
will enable the join in the whole network.

Options to proceed:

Option 1) Keep this work in
draft-richardson-6tisch-enrollment-enhanced-beacon. Not ideal because of
the timeline.

Option 2) Use simplified version of (ab)using Join Metric and add that to
draft-ietf-6tisch-minimal-security.

Option 3) Add a new CoJP parameter that JRC can set using the *Parameter
Update Request* message that would mean "start acting as a JP for N
minutes" or something similar. With this, JRC would be able to instruct
each node in the network to start accepting join packets, but it would
require JRC to reach out to each node individually.

Not sure what is the best way to proceed, let's discuss tomorrow.

My guess is that JP willing to act as JP will receive first frame from
> pledge and when it sees it, it will start joining process, start
> forwarding the frames and mark that given extended address as
> something that is allowed to bypass security by setting secExempt for
> that extended address.
>

As explained above, JP does not need to do this as it can instantiate all
this information from Stateless-Proxy on-the-fly.


> The question is how can the JP know when the pledge is done. Can it
> just trust that there will be exactly one Join Response, and forward
> that and then clear out the secExempt flag from its tables and forget
> the pledge? Or should it just timeout the secExempt entries after
> certain number of seconds of inactivity? Or even pledge sending some
> kind of notify to JP using its extended address and link key to tell
> he is done?
>

No need for any of this if a bandwidth cap is implemented at JP to protect
the network and the intermediate nodes do not react with the Scheduling
Functions to unauthenticated traffic.

JP does not need to know if a given pledge is done. There is no relation
between the pledge and the JP once the join protocol is over. Pledge may
very well never again speak to this JP if it finds a better parent once it
is able to decrypt RPL DIOs.

Fixing this here by specifying method for is solves the issue for
> good, leaving it out of scope will make hard to debug problems when
> different JPs uses different methods to know when pledge is done.
>

See above.

Again the section 7 says that it is out of scope how JP decides to
> transtion from "untrusted to trusted cache".
>

Indeed, this sentence needs to be rephrased. The pledge and JP do not
"transition" each other from insecure to secure cache. When pledge becomes
a regular node and has L2 keys, a node that formerly acted as a JP may add
it to the ND table following a new ND  exchange, that *is* now protected
with L2 security.

There is no relation between this exchange and the one during join, where
pledge did not have keys.

I will take as an action point to clarify this in the draft.


> The proposed solution given there does not work. The text says:
>
>                                        One implementation
>    technique is to use the information whether the incoming frames are
>    secured at the link layer.
>
> The unauthenticated and unencrypted frames use extended address as
> their level 2 addresses. After joining process the pledge might move
> to use short address provided to it by the JRC. As far as I understand
> the message from JRC to pledge is encrypted, and JP cannot read it,
> thus JP cannot learn what will be the short address matching the
> pledge it has in its tables.
>

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?

A pledge obtains a short address, configures it in L2 and L3 and starts
using it. Neighbor nodes (some of them formerly acted as a JP) do not need
to be aware who this node was as a pledge, as long as the node proves
possession of correct L2 keys by generating fresh, L2-secured frames.

Does that make sense?

>
> Of course it can guess, that if there is pledge with extended address
> of 0x1234567812345678 and then suddenly there is new node with short
> address of 0x0010, then most likely they are same, but this might not
> be good idea to try to do guessing of the identities.


See above.


> 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?

I think the overall protocol would be better if the JP would get
> information about the successful completion of the joining process.
> I.e., if the JRC sending frame to be forwarded to pledge by JP, would
> also indicate something in the frame that tells JP that this pledge is
> now done, and it can be removed from the untrusted neighbor cache, and
> from the secExempt list.
>

See explanations above and let me know if it makes sense.

In section 8.1. the ID of the pledge is 0x00, but ID of JRC is
> 0x4a5243. As far as I understood the OSCORE for the security it would
> be enough to just use any different value for them, i.e., using 0x00
> for pledge and 0x01 for JRC. Why does the JRC use 0x4a5243 ("JRC")
> instead of just 0x01?
>

The OSCORE ID of the JRC ("JRC") is present in the packets only for
Parameter Update Request messages, i.e. from JRC to nodes. It is not
present in Join Request or Join Response messages and therefore does not
take any space there.

When a Parameter Update Request arrives at a node, "JRC" ID is used to look
up if there is a security context available. I thought it would be better
to use something more explicit than 0x01 for this ID in order to allow
nodes to have other OSCORE contexts for application purposes, whose ID can
be a single byte value, e.g. 0x01.

Does that make sense?


> The pledge identifier is used as ID context, which is added to both
> sender and recipient key generation so in all cases the final keys are
> different even if the PSK is same as long as the pledge identifier is
> unique. If pledge identifier and PSK are not unique, then we do have
> nonce collision as both devices start with sequence number of 0.
>

Right, the use of a 3-byte identifier was simply for being (more) explicit.
Let me know if you agree or not with the reasoning above.


> I was just about to point out about the persistency of the sequence
> numbers, and I was more than happy to see that it was actually already
> mentioned in the draft. Good work!
>

Thanks!


>
> (My guess is that there is huge number of IoT devices which do not do
> that properly)
>
>
> In section 9.3.2 there is description about the rekey algorithm which
> has following sentence:
>
>                                                         Upon
>       reception and successful security processing of a link-layer frame
>       secured with a key from the new key set, a non-6LBR node MUST
>       remove any old keys it has installed from the previous key set.
>
> I think it would be better to wait for a while before deleting the old
> set, but immediately move to use the new set for transmissions. I.e.,
> we might have node B and C, which both have old and new keys, their
> parent A sends an EB with new keys out, but node C is not able to
> receive it correctly. Now if C wants to send frame to A or B, it will
> still be using old key as it has not yet seen any new frames. Both A
> and B will throw that frame out as it is using old key. If this would
> be changed to say that "node MUST remove any old keys after delay of N
> seconds" (or delay of N slotframes or whatever).
>

I agree with this resolution. Let's see if there are any opposing opinions
for including this change tomorrow at the meeting.


>
> In section 9.3.2 there is text about link-layer short address, but
> there is no requirement for the JRC, that mandates it to ensure that
> it will be unique at any given time. I.e., the security of the network
> will depend that there is never two sort address using same keys at
> the same time. I.e., if JRC is restarted and its loosing the state of
> which short addresses are allocated it MUST rekey the whole network
> with newly generated key (and as it cannot do that by sending updates,
> as it does not know who is part of network, it must force everybody to
> rejoin).



> If JRC gives out the short address without giving lease_time, it MUST
> not ever reuse those short addresses. If it does give lease time it
> should wait for some guard time before reusing short address that has
> already been expired. This guard time should include cases where node
> has sent out message and the message is waiting in transmit queue, but
> has not been sent out yet, while the address expires, and node might
> not have code to purge the tranmission from the queue. So adding guard
> time that is in order of maximum wait time for sending frame or so,
> would be good.
>

Sounds good. Are you ok to add an explanation encompassing your two
paragraphs from above in Security Considerations section and point to it in
the CBOR parameter definition paragraph?


> 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.


>
> I do understand that the text is trying to say it does not need to be
> unique in the global internet, but in the local network it needs to be
> unique globally inside the whole network.
>
> Note, that short address of 0xfffe (associated, but not given short
> address) and 0xffff (broadcast) are reserved in 802.15.4-2015 and
> cannot be used. Also some other 802.15.4 extensions like L2R (layer 2
> routing) 802.15.10 do reserve additional set of short addresses for
> example for multicast (0xff00-0xfffd).
>
> Most likely this text should be reflected to that, saying that if
> address is 0xfffe, then pledge has joined the network, but JRC decided
> not to give him short address (for example it is running out of them),
> and the device should use extended address to talk to others.
>
> If JRC gives out short address of 0xffff, then it should be considered
> invalid.
>

All good points, thanks! In CoJP section, I tried to make the text a bit
generic in order to enable the use of CoJP with different link-layer
technologies, i.e. other than 6TisCH, but I will definitely add these in
the context of 802.15.4.