[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [166.70.13.233]) (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 ([166.70.13.51]) 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 [72.250.219.84] (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 [127.0.0.1]) 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, 08 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-Connect-IP: 72.250.219.84
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-Relay-Country:
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 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.
- [secdir] Comments on draft-richardson-6tisch--sec… Hilarie Orman
- Re: [secdir] Comments on draft-richardson-6tisch-… Michael Richardson