Informal security comments on
draft-richardson-6tisch--security-6top-04.txt

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. This is an early review, so these comments are mostly useful for
the draft authors.

Tero Kivinen has already sent his comments, and he clearly knows more
about the details of 6tisch than I do, but I'll weigh in with my own
impressions anyway.  The draft is daunting for a neophyte in this
801.15.4e world, and I have to admit that I almost gave up when I
reached this text:

  The joining node will not participate in the route-over RPL mesh,
  but rather will be seen by the network as being a 6lowpan only
  leaf-node.

I was fortunate to find an IPSO Alliance document that is a fairly
good introduction to the technology and the acronyms.

The problem is to use an existing protocol to provide a way for a
pre-provisioned node to securely join a wireless network.  
Because the node initially has no IP address, the authentication
must take place without requiring the node to use layer 3 protocols.

The solution uses a special "Join Network" with a well-known key and
an untrusted intermediate node (Join Assistant).  The Join Assistant
helps the joining node by acting as a cache for certificates and a
proxy for requests to join the routing mesh.  The joining node's join
request is forwarded to a border router and thence to an authoritative
entity, the Join Coordination Entity (JCE).  The JCE initiates a
conversation with the joining node using DTLS; the traffic is relayed
through the Join Assistant.

A minor issue with the protocol is the encryption with a well-known
key.  This serves no security purpose, but it allows traffic filtering
to keep the traffic on the special Join Network separate from the
regular network.  That confuses me --- surely some packet marker would
be better for filtering than encryption would?

Another confusing point is step 1B "send router solicitation".  I'm
not sure what destination address is in this.  Perhaps the beacon
provides the information for use by the joining node.

Overall, the problem with the draft's suggested framework for mutual
authentication between the joining node and the JCE is that there is a
great deal of setup using an trusted node.  The joining node has no
reason to the trust the Join Assistant or anything it receives from
it.  Thus, it can be easily fooled into trying to join the wrong
network, and the long conversation that this entails before ultimately
failing may be quite a burden.  Kivinen notes that replay attacks are
possible, and these will always be a problem with unauthenticated
exchanges.  It seems better to avoid them rather than to leave someone
the problem of proving later than none of them succeed.

It seems clear that the initial communication must have mutual
authentication.  I'd expect the joining node to start with a signed
join request, and nothing would proceed further until the JCE found
the device ID in its access list and decided to proceed with
further authentication.  The joining node should not communicate
further until it has some reason to believe it is on the correct
network.

Even with that change, there is always the possibility of a malicious
relay node-in-the-middle.  It could cause the joining node to
communicate with a very distant instance of the correct network, for
example.  This might violate some proximity assumptions.  The
malicious node could arbitrarily block communication and cause
unintended behavior of the network.