Subject: [6tisch-security] Comments on draft-richardson-6tisch-security-6top

From: Michael StJohns <[email-masked]>
Date: Sat, 12 Jul 2014 19:04:46 -0400

Michael Richardson asked me to comment on the subject draft.  I'm not a 
subscriber to the list, so any replies need to be cc'd to me.

I took a look at the document primarily with respect to whether or not 
the as described model made sense.

Comments:

1) The document has more than its share of unexplained acronyms. While I 
appreciate that this references back to other WG documents, it makes 
this document somewhat difficult to evaluate on its own merits.  Of 
special note, is the use of IDevID (and an apparently incorrect 
reference to DevID) which is an 802.1AR term.  The general rule for the 
IETF document series is that it's OK to point to other RFC's for general 
acronyms, but to explain in sufficient detail any acronyms that come 
from other document series.

2) There needs to be a discussion of pre-conditions.  For example, where 
exactly did the IDevID come from?  If manufactured in, what are the 
assumptions about the provisioning of the roots of trust (manufactured 
and local) to the various nodes in the system?

3) It's unclear why you're proposing specialized "join assistant" 
nodes.  If you intend for this to be a distinct role, then a discussion 
of how that role is assigned, and why it needs to be distinct from the 
"non-leaf node with routing" role is necessary. My personal opinion is 
that making them distinct is a bad idea as it adds to the complexity of 
provisioning a mesh and probably requires real world geography and 
topology information to be sure you cover all the places that joins 
could happen.  (E.g. what happens if a joining node can only see a 
non-join assistant node?)

4) In section (3) you refer to a locally significant DevID - I assume 
you mean an 802.1AR LDevId?  Or something else?

5) DOS attacks on the "join assistant" are probably less problematic 
than DOS attacks on the mesh as a whole.  Why not have the join 
assistant verify the cert chain of the joiner (to include a signed 
challenge for timeliness and proof of possession of the related private 
key)?  Then have the JA send just the mac address of the joiner to ask 
if that MAC is a legitimate joiner.  If you get a yes answer back, the 
JA sends the rest of the joiner cert chain upstream and gets back the 
LDevID which it then gives to the joiner.  The Joiner now uses the 
LDevID as its credential to join the network. It's possible to DOS any 
given node with join attempts, but its pretty easy for such a node to 
throttle them (handle not more than one distinct MAC per 5 minutes 
unless you're in mesh building mode), but since the JA never sends up 
unauthenticated IDevIDs and the associated cruft, you don't translate 
that DOS on the JA to a DOS on the mesh. Since the MAC is tied to the 
IDevID you have a pretty good protection against MAC forgery doing it 
that way.

6) You need to handle the case where there are two legitimate meshes 
within earshot of each other.  There needs to be a mechanism for a node 
to figure out which mesh it needs to belong to.  The specific case of a 
legitimate mesh next to an illegitimate attacker suggests that you need 
a way for the joining node to be pre-provisioned with the root of trust 
for the LDevIDs for a particular system.  E.g. as much as you need to 
authenticate the joiner to the mesh, you need to be able to authenticate 
the mesh to the joiner.  Steps 2 & 3 seem to be where you install the 
"authorizer"s certificate as the controlling entity for the mesh - if 
you install the wrong one, how do you recover?

7) A discussion of permanent storage would be helpful - e.g. what's on 
the node at manufacture, what's on the node after enrollment, and how 
much of that has to stay on the node after a power cycle.

8) A discussion of disenrollment, both from the ejection model (e.g. 
controller says that the node is no longer welcome both in an emergency 
- this node is compromised sense - and in a non-emergency routine 
deletion) and from the removal model (node powered off and moved to 
another location to be joined to a new mesh).  The former needs protocol 
elements and perhaps a discussion of LDevID revocation.  The latter 
needs a discussion of minimum UIs on the node (e.g. a reset switch, a 
magic control cert, etc - doesn't need specification, but does need a 
"you need to think about this" paragraph).

9) Steps 12 and 13 are specified to use the JOIN key rather than having 
the joining node (which should at this point have its credentials) join 
the network as a full member.  Why?

10) Continuing my comments from (5) above, there's no need to include 
address assignment in this flow.  That should be deferred until the node 
can register with its own LDevID (or its own copy of the master key).

11) There's no need to set up a DTLS connection between the JCE and the 
joining node.  You're either passing back an LDevID, or you're passing 
back a key.  The former is just a signed blob that can be passed along 
from the JCE to the JA and thence to the joining node. The latter is an 
encrypted blob (using something like ECIES using the IDevID of the 
joining node) that can be passed along from the JCE to the JA and to the 
joining node where it can then be decrypted - it might be signed by the 
JCE.  Unless there's a real need for setting up a security association 
between the JCE and the joining node, avoid it.

12) Have I mentioned how much I hate master keys?

13)  You have (page 7)

> If the
> IDevID is less than 64 bits, then it is possible that it could be
> placed into the EUI-64 option of the ARO

which confuses me.  An IDevID is an X509 certificate and in no way is 
less than 64 bits.

I hope this helps.  Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jul 2014 09:04:23 -0400

> 1) The document has more than its share of unexplained acronyms. While
    > I appreciate that this references back to other WG documents, it makes

okay. I will import more definitions that I need.
Were there particular TLAs that gave you pause?

    > IETF document series is that it's OK to point to other RFC's for
    > general acronyms, but to explain in sufficient detail any acronyms that
    > come from other document series.

Sure, I can do that.

    > 2) There needs to be a discussion of pre-conditions.  For example,
    > where exactly did the IDevID come from?  If manufactured in, what are
    > the assumptions about the provisioning of the roots of trust
    > (manufactured and local) to the various nodes in the system?

okay.

    > non-join assistant node?)

The goal was not to have distinct join assistant nodes, but rather that this
is a role that a node may be told to take on, provided it has the ability
(code), and also power budget to be able to do so.  Further, a goal was that
any additional things that the Join Assistant would not be uniquely for Join
Operation.

So a Join Assistant needs to:
   1) send enhanced BEACONs for the JOIN network: it would do so for the production
      network too.
   2) send RAs for the Join network: it would do so for the production
      network too.
   3) send DAR/DAC upstream for leaf nodes that do not participate as
      routers.
   4) send DAO messages upstream for leaf nodes.
   5) restrict (but forward) traffic from the JOIN network to timeslots allocated for
   this purpose.
   6) restrict (but forward) traffic from the JOIN network to only for
   the address of the JCE.

So, only point 6 is particularly unique to being a join assistant.
Point 5 may be already be there; in general traffic coming in on certain
timeslots will often only be forwarded in designated other timeslots
(GMPLS-like), so this is just extended it slightly to recognize which
encryption key was used.

    > you mean an 802.1AR LDevId?  Or something else?

Yes, thanks for catching this.

    > if that MAC is a legitimate joiner.

That would imply that the join assistant has the right trust anchors, as well
as the CPU, RAM and energy to verify the new node, and can do this during
some kind of denial of service.    We also can't expect the Join Assistant to
know which joiners belong on which network, nor can we expect the joiner to
be able to verify that this is a legitimate join assistant.

    > If you get a yes answer back, the
    > LDevID as its credential to join the network.

How would the joiner know that this is the right network?
That's why this step has been moved to being yet-another-parameter to be
provisioned during the 6top transaction.

    > It's possible to DOS any

Whether or not the MAC is related to the IDevID is a good question which we
have not yet resolved.  It seems like it is good idea; but there may also be
(privacy) reasons why it would be better to make them different.  Yet the
IDevID should ideally have OUI-like vendor/unique-number properties.

    > authenticate the joiner to the mesh, you need to be able to
    > authenticate the mesh to the joiner.

Yes, this is a legitimate concern; we have been told of real examples from
the oil refinery industry where different mesh networks legitimately overlap,
and also may overlap with a legitimate mesh network at the 7/11 just outside
the gate.

The zerotouch process is to avoid any such pre-provisioning: the legitimate
mesh will possess a certificate rooted in the vendor, assigning ownership of
that particular joining node to the operator of that mesh.

I'm wondering how to best capture my email:
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

into the draft.  I have recently (IETF90 reception...) learnt that DOCSIS 3.0
does something like this.

    > much of that has to stay on the node after a power cycle.

okay, I've opened ticket: https://tools.ietf.org/wg/6tisch/trac/ticket/20

    > 8) A discussion of disenrollment, both from the ejection model
    > (e.g. controller says that the node is no longer welcome both in an
    > emergency - this node is compromised sense - and in a non-emergency
    > routine deletion) and from the removal model (node powered off and
    > moved to another location to be joined to a new mesh).  The former
    > needs protocol elements and perhaps a discussion of LDevID revocation.
    > The latter needs a discussion of minimum UIs on the node (e.g. a reset
    > switch, a magic control cert, etc - doesn't need specification, but
    > does need a "you need to think about this" paragraph).

I've opened ticket: https://tools.ietf.org/wg/6tisch/trac/ticket/21

    > the network as a full member.  Why?

Step (2) and (3) probably confused you.  Wow.  re-reading, yeah, it totally
messed you up.

This isn't a certificate request for the joining node, it's the joining node
asking for information about the network it is joining from a nearby node.
The idea is to help the joining node decide that "this isn't the right
network" earlier.

I think that I will rename them, but I'm not sure exactly what to rename it
to yet.

This is what I changed:

dooku-[/corp/ietf/richardson/6tisch-security] mcr 9394 %git add -p
diff --git a/draft-richardson-6tisch-security-6top.xml
b/draft-richardson-6tisch-security-6top.xml
index 3e790b1..28dc45a 100644
--- a/draft-richardson-6tisch-security-6top.xml
+++ b/draft-richardson-6tisch-security-6top.xml
@@ -485,21 +485,23 @@
             packets, and should contain a prefix appropriate for join
traffic.
           </t>
         </section>
-        <section title="step (2): acquire authorizer key">
-          <t>Step (4) will involve doing a public key encryption to node
-          performing the authorization management role. In order to do this,
-          the new node needs to know the public key of the manager, and so
in
-          this step it requests that certificate from the neighbour that
that
-          it received the beacon from.</t>
-          <t>This step is optional, and it's benefit has not been
demonstrated by
-          a real world use case, but has been retained for now</t>
+        <section title="step (2): certificate cache load">
+          <t>At step 10, the JCE will need to present a certificate chain
+          anchored at a trusted CA built into the joining node.
+          It has been speculated that a significant amount of traffic could
+          be avoided at step (10) if the common parts of the certificate
chains
+          could be cached in the join assistant.
+          </t>
+          <t>
+            This optional step involves the joining node asking for
certificates
+            from the join assistant.
+          </t>
         </section>

-        <section title="step (3): receive authorizer key">
-          <t>the proxy neighbour sends the key in one or more messages,
-          along
-          with the address of the authorizing server. The address of the
-          authorization server could be an attribute of the certificate that
-          is received.</t>
+        <section title="step (3): receive certificate cache">
+          <t>the proxy neighbour sends requested cached certificates to the
+          joining node
+          </t>
         </section>

So steps 12/13 are before the joining node has it's credential, it's the step
where it gets it's credentials.

    > 12) Have I mentioned how much I hate master keys?

Yes, me too.

    >> If the IDevID is less than 64 bits, then it is possible that it could
    >> be placed into the EUI-64 option of the ARO

    > which confuses me.  An IDevID is an X509 certificate and in no way is

Good point.  The intention was to actually put the serialNumber (802.1AR
7.2.2) which is inside the IDevID.  That serialNumber needs to be the same as
the EUI-64.  No size is specified in 802.1AR, but we would like to get it
into the EUI/OUI space of the EARO of  draft-thubert-6lowpan-backbone-router.

Posting a -02 now...

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-