[secdir] Comments on draft-richardson-6tisch--security-6top-04.txt

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 08 December 2014 18:34 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A10681AC3DC; Mon, 8 Dec 2014 10:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.999
X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FROM_12LTRDOM=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5XEY2wDHwSnz; Mon, 8 Dec 2014 10:34:20 -0800 (PST)
Received: from out03.mta.xmission.com (out03.mta.xmission.com []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9336A1A87D9; Mon, 8 Dec 2014 10:34:20 -0800 (PST)
Received: from in01.mta.xmission.com ([]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1Xy38V-0004Bj-07; Mon, 08 Dec 2014 11:34:19 -0700
Received: from [] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1Xy38U-00050K-5Z; Mon, 08 Dec 2014 11:34:18 -0700
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id sB8IXeEk004510; Mon, 8 Dec 2014 11:33:40 -0700
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id sB8IXd8Q004508; Mon, 8 Dec 2014 11:33:39 -0700
Date: Mon, 8 Dec 2014 11:33:39 -0700
Message-Id: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org, draft-richardson-6tisch--security-6top.all@tools.ietf.org
X-XM-AID: U2FsdGVkX19Bod5suqhkvG5hMIQPFYUq
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ******;iesg@ietf.org, secdir@ietf.org, draft-richardson-6tisch--security-6top.all@tools.ietf.org
X-Spam-Timing: total 478 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.9 (0.6%), b_tie_ro: 2.1 (0.4%), parse: 0.93 (0.2%), extract_message_metadata: 9 (1.9%), get_uri_detail_list: 3.6 (0.7%), tests_pri_-1000: 3.9 (0.8%), tests_pri_-950: 1.69 (0.4%), tests_pri_-900: 1.36 (0.3%), tests_pri_-400: 28 (5.8%), check_bayes: 26 (5.4%), b_tokenize: 8 (1.7%), b_tok_get_all: 9 (1.9%), b_comp_prob: 3.1 (0.7%), b_tok_touch_all: 2.2 (0.5%), b_finish: 0.82 (0.2%), tests_pri_0: 420 (87.9%), tests_pri_500: 6 (1.2%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8
Subject: [secdir] Comments on draft-richardson-6tisch--security-6top-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2014 18:34:21 -0000

Informal security comments on

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

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

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.