[6tsch] Feedback on draft-ohba-6tsch-security-00

Rene Struik <rstruik.ext@gmail.com> Fri, 05 July 2013 14:56 UTC

Return-Path: <rstruik.ext@gmail.com>
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 4D25921F9C98 for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 igxNVp045K+4 for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 07:56:50 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6821F9E34 for <6tsch@ietf.org>; Fri, 5 Jul 2013 07:56:50 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id 10so5522534ied.14 for <6tsch@ietf.org>; Fri, 05 Jul 2013 07:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=GvXPREFGTk8EQJT+NIpaqrCMo/OWjreT3tZx2s/zsIQ=; b=zB9R6y/8AR/lI5VGGUJB0jGJae9qcRJ0b6du2IT65/exHLlnO7j13CsFfZTRs2Rtk3 OjNQPrI+sIITmoOAnhf4H1zK7K/d97Vq7G20HyDKeHxRNjfieV+FhBYmA8fQLdAjkyhE JgEPJRs6m2fckGYaHNEIWQCzTGWUAIF11NgKz3JDg+aV1LNR8qTKgWeSdbtKppEhs6kV JBhFzFfKarUFBun6EN4ywdVp8d8O1W7rGw3U6vrTEAEFH1RqPIca3g5ysjgs5A1VB4ze oeWoDesvz4JQj6zbmFqkVP06US1pf0VS9sz+B4qowpQwk2RVbODytCNxSLhi68tFtW4Q 3Mew==
X-Received: by 10.42.79.142 with SMTP id r14mr4107291ick.51.1373036210305; Fri, 05 Jul 2013 07:56:50 -0700 (PDT)
Received: from [192.168.1.102] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id ri10sm29559205igc.1.2013.07.05.07.56.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 07:56:49 -0700 (PDT)
Message-ID: <51D6DEA6.9040600@gmail.com>
Date: Fri, 05 Jul 2013 10:56:38 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
References: <CADJ9OA995PHw4X5URQ7xWbDH5N7TTxpfRywpwF2y05s5Yg_TVA@mail.gmail.com>
In-Reply-To: <CADJ9OA995PHw4X5URQ7xWbDH5N7TTxpfRywpwF2y05s5Yg_TVA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030609090908060707090907"
Cc: 6TSCH <6tsch@ietf.org>
Subject: [6tsch] Feedback on 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, 05 Jul 2013 14:56:52 -0000

Hi Yoshi:

I had a look at your draft and reflected somewhat on the requirements 
mentioned.

Initial feedback:

General remark:
1) The draft text seems almost independent of 802.15.4e behavior. While 
the security considerations make reference to the need to authenticate 
time synch and channel hopping info in beacon frames and refer to 
potential nonce "overflow" issues, it is not that easy to see how the 
mechanisms described in the draft address these 802.15.4e-specific 
considerations.
2) The draft seems to aim at providing both (a) key establishment 
functionality (setting up a secure peer-to-peer channel); (c) key 
distribution (handing out link keys, muulticast keys, network keys). It 
would be useful to organize the draft so as to separate these 
functionalities more clearly (e.g., Phase-II KMP vs. Phase-II Key 
Distribution). What about key updates?

Security Framework (Section 3):
a) The security framework (Phase-III) seems to require incremental 
roll-out/planning of the network, witness Fig. 2. If so, it would be 
good to indicate how devices transgress through the different "phases" 
defined and to what degree this requires planning/intervention by an 
operator.
b) The bootstrapping phase (Phase-I) suggests inline interaction of a 
device with an authentication server (which is assumed to mostly be the 
coordinator of the mesh network). Since bootstrapping only results in 
issuance of credentials to be used by devices for Link Establishment 
(Phase-II), I can imagine this step to be often organized differently 
than described, e.g., by embedding a device certificate with a device at 
device manufacturing. In that case, no inline interaction with an 
authentication server seems required, at least not for *authentication* 
purposes.

KMP Requirements (Section 4):
R1-1: The requirement for mutual authentication seems to rule out 
"resurrecting duckling" policy models. Is this correct? Moreover, this 
rules out one/two pass protocols.
R1-2: The requirement for stateless relay may not work within the 
802.15.4e context: if a device A talks with an authentication server T 
via its neighbor R, where R and T operate in a secured network (i.e., 
one where all communications are cryptographically secured), R needs to 
"remember" that it should initially communicate back to A without 
security (since A and R do not have a shared key yet). Thus, R needs to 
maintain state that communications to A have to be treated differently 
(in 802.15.4e speak: A has "exempt status"). Or, is the idea that R 
somehow encodes this exempt status into its relay messages, so that it 
can pass this "hot potato" along and receive this back via T?
R2-2: I can imagine other scenarios than pre-provisioning of credentials 
or passing these along via Phase-I KMP: wouldn't piggy-backing this info 
along communication flows of Phase-II KMP also be an option?

Candidate KMPs (Section 5):
a) PANA. With bootstrapping during manufacturing, Phase-I may be 
organized differently. It would be good to show how PANA can fit 
802.15.4e needs in a stateless fashion.
b) HIP-DEX. The draft suggests this protocol (an expired draft), but at 
the same time points out that it is deficient, since does not support 
carrying certificates. This is somewhat puzzling.




On 7/5/2013 1:20 AM, Thomas Watteyne wrote:
>
> All,
>
> Below is the proposed agenda for the 6TSCH call tomorrow:
>
>   * Approval minutes last call [1min]
>   * draft-ohba-6tsch-security-00 [10min]
>   * Simulator [10min]
>   * Description of PCE [10min]
>   * Preparing for the BOF [25min]
>   * Re-organization Bitbucket [2min]
>   * AOB [1min]
>
> As usual, feel free to propose any changes to the agenda, also at the 
> beginning of the call.
>
> Remember that this call will be recorded.
>
> Pascal & Thomas
>
>
> Topic: 6TSCH Weekly
> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
> Meeting Number: 206 802 913
> Meeting Password: sixtus
>
> -------------------------------------------------------
> To start the online meeting
> -------------------------------------------------------
> 1. Go to 
> https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D
> 2. Log in to your account.
> 3. Click "Start Now".
> 4. Follow the instructions that appear on your screen.
>
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>
> The affected toll free numbers are: (866) 432-9903 
> <tel:%28866%29%20432-9903> for the San Jose/Milpitas area and (866) 
> 349-3520 <tel:%28866%29%20349-3520> for the RTP area.
>
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or 
> Access Code followed by the # sign.
>
> San Jose, CA: +1.408.525.6800 <tel:%2B1.408.525.6800> RTP: 
> +1.919.392.3330 <tel:%2B1.919.392.3330>
>
> US/Canada: +1.866.432.9903 <tel:%2B1.866.432.9903> United Kingdom: 
> +44.20.8824.0117 <tel:%2B44.20.8824.0117>
>
> India: +91.80.4350.1111 <tel:%2B91.80.4350.1111> Germany: 
> +49.619.6773.9002 <tel:%2B49.619.6773.9002>
>
> Japan: +81.3.5763.9394 <tel:%2B81.3.5763.9394> China: +86.10.8515.5666 
> <tel:%2B86.10.8515.5666>
>
> To check whether you have the appropriate players installed for UCF 
> (Universal Communications Format) rich media files, go to 
> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>
> http://www.webex.com <http://www.webex.com/>
>
> CCM:+14085256800x206802913
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363