Subject: [6tisch-security] draft-richardson-6tisch-security-6top-01

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 17:51:20 -0400

This update is available at your nearby ID draft directory.
ASCII art from Jonathan's slides with a few additions.
(Use a non-proportional font)
I think that the join request could be the NS+ARO/EARO.

I have a shitload more text, and so please don't be surprised if
there is a -02 when you look, assuming I can get it in ontime.
I made up "JCE" to the join management parts of the Authorization Server/PCE.
We might also have the ACE...

 +-----+   +------+            +----------+                +-----------+
 |     |   |      |            |  JOIN    |                |  Joining  |
 | JCE |   | 6LBR |            | Assistant|                |   Node    |
 +-----+   +------+            |  (proxy) |                |           |
    |         |                +----------+                +-----------+
    |         |                     |                            |
    |         |                     |-------BEACON (1)---------->|
    |         |                     |                            |
    |         |                     |<----Router Solicitation----|
    |         |                     |---Router Advertisement---->|
    |         |                     |                            |
    |         |                     |<------CERTIFICATE----------|
    |         |                     |         REQUEST (2)        |
    |         |                     |                            |
    |         |                     |                            |
    |         |                     |-------CERTIFICATE--------->|
    |         |                     |        RESPONSE (multiple) |
    |         |                     |                 (packets)  |
    |         |                     |                            |
    |         |                     |<-----JOIN REQUEST (4) -----|
    |         |                     |      (NS w/ARO )           |
    |         |                     |                            |
    |         |<---NS (DAR) (5)-----|                            |
    |<--??(6)-|                     |                            |
    |         |                     |                            |
    |--??(7)->|                     |                            |
    |         |                     |                            |
    |         |----NS (DAC)-(8)---->|                            |
    |         |     +------+        |                            |
    |         |<DAO-| mesh |<--DAO--|                            |
    |         |-DAO-| node |--DACK->|                            |
    |         | ACK +------+        |                            |
    |         |                     |-------JOIN ACK (9)-------->|
    |         |                     |                            |
    |         |                     |                            |
    |================(10)==========>|----------6top----(11)----->|
    |         |                     |          DTLS              |
    |<===============(13)===========|<---------CoAP----(12)------|
    |         |                     |        (many packets)      |

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 3 Jul 2014 20:02:40 -0700

Michael,

A quick clarification: although your e-mail is
entitled draft-richardson-6tisch-security-6top-01, the draft is
http://tools.ietf.org/html/draft-richardson-6tisch-table-of-contents-01,
right? Maybe rename the draft at the following iteration?

Thomas

On Thu, Jul 3, 2014 at 2:51 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Jul 2014 10:50:59 -0400

Thomas Watteyne <[email-masked]> wrote:
    > entitled draft-richardson-6tisch-security-6top-01, the draft is http://
    > tools.ietf.org/html/draft-richardson-6tisch-table-of-contents-01,

what? huh. tables-of-contents should be different...
Oh. I'll post the right draft name, and repost -02 of table of contents.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Jul 2014 11:09:40 -0400

okay, I've unconfused the drafts.
Sorry for that screw up.

http://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 4 Jul 2014 08:11:08 -0700

Excellent, thanks!

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Jul 2014 16:41:33 -0400

http://goo.gl/7bMYjc gives you a diff of -00 to -01.
The document should grow a number of additional authors, and an acknowledment
section of the people who participated in the weekly calls.
(And we will have no calls until after IETF90)

section 4.1.3: maybe too alarmist.
Have I missed any threats?

I'm posting the threat text here for discussion:

4.1.1.  threats to the joining node

   A node may be taken out of it's box by a malicious entity and powered
   on.  This could happen during shipping, while being stored in a
   warehouse.  The device may be subject to physical theft, or the goal
   of the attacker may be to turn the device into a trojan horse of some
   kind.  Physical protection of the device is out of scope for this
   document; this document will henceforth assume that the device is
   sealed in some tamper-evident way and this document deals with
   attacks over the network.

   An attacker may attempt to convince the joining node that it is the
   legitimate Production Network; this is done by putting up a
   legitimate looking Join Network, and following the protocol as
   described in this document.  The Joining Node can not know if it has
   the corrrect Production Network until steps 11-13, when it attempts
   to validate the ClientCertificate provided by the JCE.

   When the joining node determines that this is the incorrect network,
   it must remember the PANID of the network that it has attempted to
   join, and then look for another network to try.  It SHOULD have some
   limit as the number of times it will try before going back to sleep,
   or shutting down, and it SHOULD take care not to consume more than
   some specified percentage of any battery it might have.

   Should a malicious production network be present at the same time/
   place as the legitimate production network, a the malicious agent
   could intercept and replay various packets from the proper join
   network, but ultimately this either results in a jamming-like denial
   of service, and/or the the ClientCertificate will not validate.

   It is a legitimate situation for there to be multiple possible join
   networks, and the joining node may have to try each one before it
   finds the network that it the right one for it.  The incorrect, but
   non-malicious networks will not attempt the 6top provisioning step,
   and SHOULD return a negative result in steps 8/9, refusing the node's
   NS.  Those incorrect networks will be recognize that the node does
   not belong to them, because they will be able to see the Joining
   Node's IDevID in the ARO of step 4.

4.1.2.  threats to the resources of the network

   The production network has two important resources that may be
   attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory
   for routing entries.

   A malicious joining node could send many NS messages to the Join
   Assistant (from many made up addresses), which would send many NS/DAR
   messages to the 6LBR, and this would consume bandwidth, and therefore
   energy from the members of the mesh along the path to the 6LBR.  This
   can be mitigated by limited the total bandwidth available for
   joining.

   A malicious joining node could send many NS messages, and if the 6LBR
   agreed to accept the new node (by IDevID), then the Join Assistant
   would MAY inject routing information into mesh for the Joining node.
   Non-storing DODAGs store are routing information in the DODAG Root
   (probably the 6LBR), which is generally not a constrained node.
   Storing DODAGs store routing entries at all nodes up to the DODAG,
   and those are constrained nodes.  Using a separate Join DODAG, and
   having that DODAG be non-storing will reduce any impact on
   intermediate nodes, but it does cause resources to be used for the
   second DODAG, and it may have a code impact if the nodes otherwise
   would not implement non-storing RPL.

4.1.3.  threats to other joining nodes

   A joining node (or the nodes of a malicious network, co-located near
   the legitimate production network) may mount attacks on legitimate
   nodes which have not yet joined.

   The malicious nodes may attempt to perform 6top operations against
   the joining node to keep it from being able to respond to the
   legitimate 6top session from the legitimate JCE.  During the Join
   phase, the Joining node MUST have all other resources and protocols
   turned off, even if they would normally be accessible as read-only
   unauthenticated CoAP resources.

   Malicious nodes could use the Join Network to mount various DTLS
   based attacks against the joining node, such as sending very long
   certificate chains to validate.  One might think to limit the length
   of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert]
   the chain may as a long as the supplier chain, plus may include
   additional certificates due to resales of plants/equipment/etc.
   Validating from a trusted certificate down to the specific
   certificate which proves ownership would eliminate random certificate
   chains, but the attacker could just feed the joining node legitimate
   chains that it observed (and replayed) from the legitimate JCE.  This
   does no good; the Joining node finds that the DTLS connection is
   invalid, but it may significantly run batteries down.