Re: [6tsch] draft-ohba-6tsch-security-00

<yoshihiro.ohba@toshiba.co.jp> Fri, 28 June 2013 00:54 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB921F9048 for <6tsch@ietfa.amsl.com>; Thu, 27 Jun 2013 17:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.088
X-Spam-Level:
X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI5ozQ7NXvPy for <6tsch@ietfa.amsl.com>; Thu, 27 Jun 2013 17:54:08 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17E21F9C7C for <6tsch@ietf.org>; Thu, 27 Jun 2013 17:54:03 -0700 (PDT)
Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r5S0rubo011494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 09:53:56 +0900 (JST)
Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5S0runx006681; Fri, 28 Jun 2013 09:53:56 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 10; Fri, 28 Jun 2013 09:53:56 +0900 (JST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5S0ruAh006671; Fri, 28 Jun 2013 09:53:56 +0900
Received: (from root@localhost) by arc11.toshiba.co.jp id r5S0ruqg014273; Fri, 28 Jun 2013 09:53:56 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA14270; Fri, 28 Jun 2013 09:53:56 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r5S0rtfY018424; Fri, 28 Jun 2013 09:53:55 +0900 (JST)
Received: from tgxml345.toshiba.local by toshiba.co.jp id r5S0rsmU003737; Fri, 28 Jun 2013 09:53:54 +0900 (JST)
Received: from TGXML338.toshiba.local ([169.254.4.194]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 09:53:53 +0900
From: yoshihiro.ohba@toshiba.co.jp
To: jsimon@linear.com
Thread-Topic: [6tsch] draft-ohba-6tsch-security-00
Thread-Index: Ac5wf87yAAXeU4p+RJ2LFEqPqxPt0wCr1L6AABd+8uA=
Date: Fri, 28 Jun 2013 00:53:53 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D27557@tgxml338.toshiba.local>
References: <674F70E5F2BE564CB06B6901FD3DD78B12D258EB@tgxml338.toshiba.local> <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com>
In-Reply-To: <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.79]
msscp.transfermailtomossagent: 103
Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D27557tgxml338toshiba_"
MIME-Version: 1.0
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] draft-ohba-6tsch-security-00
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2013 00:54:14 -0000

Hi Jonathan,

Thank you for your feedback.

Let me answer on the General part.

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Jonathan Simon
Sent: Friday, June 28, 2013 6:09 AM
To: ohba yoshihiro
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] draft-ohba-6tsch-security-00

Section 1

"6TSCH builds on a series of semi-proprietary wireless protocols..."
Is it really relevant that TSCH was built on concepts in WirelessHART?  TSCH is not proprietary, and saying it builds on proprietary protocols is a red flag.

"Following Metcalf's law..."
Not only is it not clear what point is being made, Metcalf’s law measures “utility” in connections.  For a networked sensor device, there are likely a finite number of consumers of its data, and the total number of nodes is an irrelevant utility metric. Additionally, in terms of mesh connectivity, in general there is little additional utility to having 1000 neighbors (which may be more than the node can store) over 100, and perhaps 100 over 10 provided there is sufficient connectivity for the network to function.

General

So the problem this draft is trying to solve is shared link-layer keys in the network.  It does this by proposing an 3-phase authentication scheme with unstated overhead to provide unique per-peer link-layer keys, among other things.

a) Each node would need to be preconfigured with every node's certificate material (bad), or
communicate with the coordinator to validate PK certs for every device attempting to join (nearly as bad if this takes a lot of packets).
[YO] Actually neither one is correct.  What each node has to have as P2 credentials are a CA certificate as the trust anchor and its own certificate signed by the CA public key. Once P2 credentials are obtained, Node A and Node B can locally exchange their certificates to perform mutual authentication to securely exchange MAC keys without communicating with the coordinator.  Node A does not need to retain Node B’s  certificate and vice versa once the MAC keys are established.

Without seeing the overhead, its hard to tell if this would even work - if a device has to stay synchronized for a long time using unsecured frames, how is that any better than a shared secret? There's still a DoS vector in the unsecured bandwidth.
[YO] We know that we cannot eliminate all DoS attacks. There has to be engineering decisions as to which DoS attacks are acceptable and which are not.  In any case, it seems that beacon security in TSCH is a problem that requires deeper investigations.

b) I agree that in protocols with a well-known key for authenticating join requests, an attacker can perform a DoS attack by simulating many devices joining.  These messages are passed up to the coordinator (and rejected).  However this requires distributed injection of messages to be maximally effective, and this is little worse than flooding the network with packets authenticated with the wrong key, so I don't see how per-peer keys is an effective DoS mitigator.
[YO] Per-peer keys are mainly for avoiding difficulty with updating a common network key.

Best Regards,
Yoshihiro Ohba
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com<mailto:jsimon@linear.com>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

On Jun 23, 2013, at 7:10 PM, <yoshihiro.ohba@toshiba.co.jp<mailto:yoshihiro.ohba@toshiba.co.jp>> <yoshihiro.ohba@toshiba.co.jp<mailto:yoshihiro.ohba@toshiba.co.jp>> wrote:


6tsch-security draft has been submitted to IETF:

http://tools.ietf.org/html/draft-ohba-6tsch-security-00

Regards,
Yoshihiro Ohba

_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch