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

[Tero Kivinen <[e-mail]>]

Mališa Vučinić writes:
> 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.

Yes, I think so. 

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

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.

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

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

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.

Also to be able to allow node to send ack back to you requires you to
have secExempt flag for that node when you are sending him a frame
with too lower security level.

I.e., you cannot even transmit a frame to joining node and get ACK
back unless you have secExempt for joining node.

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

I read that text differently, i.e., not to indicate wheter joins are
allowed in the network, but whether this specific joining node is
doing join process through this JP just now.

For example if someone is doing joining process through the JP, then
it would not be nice for the JP to decide that now it is good idea to
save energy and go to sleep for next 5 minutes.

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

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

I think that is separate issue, and I think that might be left out
from this document. 

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

I assume you mean it just need to create state for very short periods
of time, not for the whole joining process duration?

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. 

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

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

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.

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.

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

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.

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

Sure.

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

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

Good.
-- 
[e-mail]