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

<> Fri, 05 July 2013 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C19AE21F9F45 for <>; Fri, 5 Jul 2013 11:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.088
X-Spam-Status: No, score=-8.088 tagged_above=-999 required=5 tests=[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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5to16qmdDXV for <>; Fri, 5 Jul 2013 11:06:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A48B21F9F38 for <>; Fri, 5 Jul 2013 11:06:35 -0700 (PDT)
Received: from ([]) by with ESMTP id r65I5tNo026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jul 2013 03:05:55 +0900 (JST)
Received: from tsbmgw-mgw01 (localhost []) by (8.13.8/8.14.5) with ESMTP id r65I5shj028547; Sat, 6 Jul 2013 03:05:54 +0900
Received: from localhost ([]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 197; Sat, 6 Jul 2013 03:05:54 +0900 (JST)
Received: from ([]) by (8.13.8/8.14.5) with ESMTP id r65I5sXO028544; Sat, 6 Jul 2013 03:05:54 +0900
Received: (from root@localhost) by id r65I5sn6022643; Sat, 6 Jul 2013 03:05:54 +0900 (JST)
Received: from [] by with ESMTP id DAA22642; Sat, 6 Jul 2013 03:05:54 +0900
Received: from (localhost []) by with ESMTP id r65I5scR003672; Sat, 6 Jul 2013 03:05:54 +0900 (JST)
Received: from by id r65I5rp8025230; Sat, 6 Jul 2013 03:05:53 +0900 (JST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Sat, 6 Jul 2013 03:05:53 +0900
From: <>
To: <>
Thread-Topic: [6tsch] Feedback on draft-ohba-6tsch-security-00
Thread-Index: AQHOeY/mzZmPbqV/kE22Df2ksTClzplWVv+A
Date: Fri, 5 Jul 2013 18:05:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: []
msscp.transfermailtomossagent: 103
Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D2ACF0tgxml338toshiba_"
MIME-Version: 1.0
Subject: Re: [6tsch] Feedback on draft-ohba-6tsch-security-00
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jul 2013 18:06:41 -0000

Hi Rene,

Thank you very much for your feedback.  Please see my comments below.

From: [] On Behalf Of Rene Struik
Sent: Friday, July 05, 2013 11:57 PM
To: ohba yoshihiro
Subject: [6tsch] Feedback on draft-ohba-6tsch-security-00

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.
[YO] We have identified issue with Enhanced Beacon frame security in Security Considerations section.  Once we agree on a solution framework to address the EB security issue we will describe it.

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?
[YO] We will describe two functionalities in Phase-2 description.  Key updates will use key distribution.

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.
[YO] I am not sure if I understand your comment above, but Fig.2 shows how a mesh network is formed after devices are placed where they are expected to operate.

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.
[YO] Yes, that is why R2-2 says “Phase-2 KMP authentication credentials MAY be pre-provisioned or MAY be obtained via Phase-1 KMP.”

KMP Requirements (Section 4):
R1-1: The requirement for mutual authentication seems to rule out "resurrecting duckling" policy models. Is this correct?
[YO] Not necessarily, because we plan to add Phase-0 where implanting bootstrap credential is expected to happen.

Moreover, this rules out one/two pass protocols.
[YO] I am not sure what you meant by “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").
[YO] We meant “stateless” in R1-2 is about state maintained above MAC layer.  If 802.15.4e requires to maintain state for unauthenticated nodes at MAC layer to communicate with them, then we should not try to change it in IETF.
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?

[YO] I don’t understand how piggy-backing (i.e., use of P2 KMP to provide P2 KMP credentials) can work.

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.
[YO] Please see my comment above.

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.
[YO] Please see Rafa’s comment on this.

Yoshihiro Ohba

On 7/5/2013 1:20 AM, Thomas Watteyne wrote:


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
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
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<>



6tsch mailing list<>


email:<> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363