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

Rene Struik <rstruik.ext@gmail.com> Fri, 05 July 2013 19:28 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 C5DCF21F9F11 for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 12:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level:
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 lyVBOkhixPCp for <6tsch@ietfa.amsl.com>; Fri, 5 Jul 2013 12:28:05 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12021F9F0C for <6tsch@ietf.org>; Fri, 5 Jul 2013 12:28:05 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id 9so6005813iec.19 for <6tsch@ietf.org>; Fri, 05 Jul 2013 12:28:04 -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=fIlJmQ3pnVbmkZhyobiNIFiCjuO+HTZxk28EF6RxbCk=; b=y6Kuvi/+hoComCXX9MPb0KJPscc3lWEc+F3/uR+BwcLgU0MVAK50TysqYTdyr87e6S JPZV0wGCLneswrV6GGxvQa+Gxl1R0JAJRXk5d8YPgvHGTSaNZ9q93/vNONQV6GYANclL fxw0jtUjwh4nQdp52JDagquKYc7tu5cp4FppjzN906H5ee4UhMEe8iHfnpHHK10gmyt5 mhLOYJtRNF/SvDzH4cRKdcOlj8DJ4y/DPv+/60Qah7XYWnrcKu5hVEveaeUDBj0xfIvy WqCIJWNnQLxWk5xfjmCsb476IG0Sv/ldjaNdQkXGiJ2kpzGAAqWUZcP5FHgbcYmsOtlK tw8A==
X-Received: by 10.42.228.196 with SMTP id jf4mr4292866icb.85.1373052484874; Fri, 05 Jul 2013 12:28:04 -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 p10sm30329586igx.4.2013.07.05.12.28.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 12:28:03 -0700 (PDT)
Message-ID: <51D71E38.6000005@gmail.com>
Date: Fri, 05 Jul 2013 15:27:52 -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@toshiba.co.jp
References: <CADJ9OA995PHw4X5URQ7xWbDH5N7TTxpfRywpwF2y05s5Yg_TVA@mail.gmail.com> <51D6DEA6.9040600@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2ACF0@tgxml338.toshiba.local>
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D2ACF0@tgxml338.toshiba.local>
Content-Type: multipart/alternative; boundary="------------060305050703090406090304"
Cc: 6tsch@ietf.org
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 19:28:07 -0000

Hi Yoshi:

Please see feedback below.

Best regards, Rene

On 7/5/2013 2:05 PM, yoshihiro.ohba@toshiba.co.jp wrote:
>
> Hi Rene,
>
> Thank you very much for your feedback. Please see my comments below.
>
> *From:*6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
> Behalf Of *Rene Struik
> *Sent:* Friday, July 05, 2013 11:57 PM
> *To:* ohba yoshihiro
> *Cc:* 6TSCH
> *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. /*
>
/**/RS>>
It seems very well possible that secure channels can be established
between devices in a less hierarchical fashion than suggested in Fig. 2.
As an example, B and D may set-up a secure channel locally ("Phase II"),
without B first having to perform a protocol with A ("Phase I"). This
ties into my question re the security model, where (in my mind, at
least) Phase-I may very well be superfluous, e.g., when devices already
have certs on board. In the model 3-phase model described in the draft,
however, every device first has to talk with the Mothership node A
(authentication server), thus forcing a hierarchical model. In short:
your picture seems to reflect a hierarchical trust model, which seems to
be a choice, rather than a necessity. If devices already have some
credentials on board, one seems to be able to collapse (1) and (2) and
remove (3); moreover, one could swap the order of the (1)-(2) tandem and
(4) then (at least from a secure channel set-up perspective).
<<RS
>
> *//*
>
>
> 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.”/*
>
RS>>
If a device already has a cert on board, Phase-I seems superfluous. If
you agree, I would suggest adding some language to that effect (right
now, the Phase-I, II, III sequence comes up all over the place in the
draft).
<<RS
>
>
> 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./*
>
RS>>
My comment was on the current draft, so perhaps a future planned Phase-0
step would allow resurrecting duckling type configuration. That would be
good from a trust policy lifecycle management perspective.
<<RS
>
> *//*
>
> Moreover, this rules out one/two pass protocols.
>
> */[YO] I am not sure what you meant by “one/two pass protocols”./*.
>
RS>>
Mutual authentication (I presumed entity authentication) assumes each
party to provide cryptographic evidence based on an input received from
the other party, so requires more than two passes. If you meant mutual
authentication without aliveness guarantees, one may end up with replay
attacks.
<<RS
>
>
> 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./*
>
RS>>
The requirement for stateless behavior has much diminish meaning, if one
needs to maintain state at the MAC anyway (thus, should perhaps be
dropped). On a more general note, I would suggest checking the incoming
and outgoing frame processing sections of the 802.15.4 specification, to
see what state needs to be maintained for processing to work.
<<RS
>
> *//*
>
> 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./*
>
RS>>
Something along these lines has been suggested in the context of 802.11
join protocols (between STA and AP). We can discuss offline.
<<RS
>
> *//*
>
>
>
> 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. /*
>
RS>>
As suggested before, Phase-I as described in the draft is not the only
way of doing things (and arguably an expensive way). One additonal note
on PANA: RFC 6786 uses a different nonce format when encrypting
attributes than 802.15.4 uses. Depending on hardware/software boundaries
of CCM impementations, this
could cause a problem.
<<RS
>
> *//*
>
>
> 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.
>
RS>>
See my separate email note on HIP-DEX to Rafa.
<<RS
>
> Regards,
>
> Yoshihiro Ohba
>
>
>
> 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 <mailto:6tsch@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> -- 
> email: rstruik.ext@gmail.com <mailto:rstruik.ext@gmail.com> | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


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