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

Rene Struik <rstruik.ext@gmail.com> Fri, 05 July 2013 16:51 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 B37EF21F9FD4 for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 09:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, 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 fs6kr+Op5Dk5 for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 09:51:21 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 58F1A11E80A2 for <6tsch@ietf.org>; Fri, 5 Jul 2013 09:51:18 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k13so5849852iea.32 for <6tsch@ietf.org>; Fri, 05 Jul 2013 09:51:17 -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=YwP6MDg0SH+gwkmLv4a0MAG7C7zGnPCY8ZqYm+q0cd4=; b=TYsBOErYIr5HvQcNiE6WEvxMzzYUHVtKWVK0u5cq5mShrdpfZA5uTRxG4aN4davYfh yaGgEWTttrLW88XdrUTmTYtwbEY+MNRX9wCpM7qSZlr64qsGgVKdqUh3Vhx2WbKtogum CYf1LQf6t+/8uiLfnRDH78D1cP5EfI/HZzwpRFNh724SPWE371qNfgbzxcv9c04c1EzO xabNXn9OYoj2MoxU8GU0dfrwOa48gV8Ns4ufzwaF9B+dbORhl+zz9axlFHgY2LghaqzF 5R8NGKapeANp3Fpu79BeTe7cmGBN7sKOZSqqICM98zFYigMIH0fngFFWF33aVpqsyyc2 LjzA==
X-Received: by 10.50.12.5 with SMTP id u5mr28482425igb.58.1373043077434; Fri, 05 Jul 2013 09:51:17 -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 q10sm4196485ige.4.2013.07.05.09.51.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 09:51:16 -0700 (PDT)
Message-ID: <51D6F979.9000606@gmail.com>
Date: Fri, 05 Jul 2013 12:51:05 -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: Rafa Marin Lopez <rafa@um.es>
References: <CADJ9OA995PHw4X5URQ7xWbDH5N7TTxpfRywpwF2y05s5Yg_TVA@mail.gmail.com> <51D6DEA6.9040600@gmail.com> <D6980B22-B9B4-47B8-B9FF-2C51E720E320@um.es>
In-Reply-To: <D6980B22-B9B4-47B8-B9FF-2C51E720E320@um.es>
Content-Type: multipart/alternative; boundary="------------080809060702020307090708"
Cc: 6TSCH <6tsch@ietf.org>, Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
Subject: Re: [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 16:51:34 -0000

Hi Rafa:

Thanks for your note. Some brief feedback below.

Buen fin de semana.

Rene

On 7/5/2013 12:15 PM, Rafa Marin Lopez wrote:
> Hi Rene:
>
> Thanks for your review. Let me provide some comments about your review 
> in Section 5.
>
> a) Regarding PANA, it is worth noting that the usage PANA here is for 
> phase 2 KMP, which is different from phase 1.

RS>>
True, Section 5.2 refers to use of PANA with Phase-II key establishment; 
however, Section 5.1 refers to use with Phase-I as well. The more 
important question to explain would be how it can act in stateless manner.
<<RS
> Here a node tries to establish a one hop link connection with another 
> node. Then one acts as the PaC and the other PAA. That is why the text 
> says:
>
> "It is worth noting that, though this candidate solution leverages the 
> PaC implementation from Phase-1, each node needs to deploy a PAA 
> implementation, an EAP server and a specific EAP method, which may be 
> different from the one used for Phase-1."
>
> So here, you run PANA between both nodes and establish a key that you 
> pass to IEEE 802.15.4e to protect the link. I assume you want more 
> details about this particular point, don't you?
> b) Regarding HIP-DEX, the text says that HIP-DEX would require to 
> carry certificates and for that you need CERT parameter. So, in the 
> end, my understanding is that HIP-DEX is not deficient to carry 
> certificates since you would have the CERT parameter for that.
>
RS>>
My understanding of the text was that HIP DEX does not include CERTs, 
but admittedly I did not check the internet draft. (As an aside, I 
thought HIP IETF group was winding down and the draft has been expired 
for a while).

The text says this:
However, by just using
the value of the public key and the private key is not enough to
carry out the authentication between nodes. In particular, a node
A and node B should not be able to successfully finish HIP DEX
execution if they both have not been authenticated in Phase-1.
Thus, HIP DEX will require the inclusion of the certificate of
each node to achieve full mutual authentication. The information
in the certificate must ensure that the node was authenticated in
Phase-1. In consequence, HIP DEX must include a CERT parameter
for carrying this certificate.
<<RS

RS>>
On a general note, when reviewing the text, I mostly look at security 
properties and try and see how protocols would fit the bill. To me, it 
was not clear what makes using HIP-{DEX, BEX, other acronym} desirable 
to use (and I am not aware of too many people who seriously looked into 
this). I think it would be useful to articulate why one *should* use a 
particular protocol, rather than simply listing protocols one apparently 
*could* use, and to articulate metrics (security properties, protocol 
flows, communication/computational latency, etc.).
<<RS


>
> Best Regards.
>
>
> El 05/07/2013, a las 16:56, Rene Struik escribió:
>
>> 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
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org <mailto:6tsch@ietf.org>
>> https://www.ietf.org/mailman/listinfo/6tsch
>
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es 
> <mailto:rafa@um.es>
> -------------------------------------------------------
>
>
>
>


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