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

[Michael Richardson <[e-mail]>]

Michael StJohns <[e-mail]> wrote:
    > 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

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

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

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.

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

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.

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

Yes, thanks for catching this.

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

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

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

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.

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

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.

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

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

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

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.

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

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-