Re: [6tisch] 6tisch join requirements for 6top

Tero Kivinen <kivinen@iki.fi> Mon, 01 December 2014 13:31 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2887C1A1BB8 for <6tisch@ietfa.amsl.com>; Mon, 1 Dec 2014 05:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DXOu_K97RQY for <6tisch@ietfa.amsl.com>; Mon, 1 Dec 2014 05:31:27 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAC61A1BB7 for <6tisch@ietf.org>; Mon, 1 Dec 2014 05:31:26 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB1DQ63h007893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Dec 2014 15:26:06 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB1DQ6Nv000251; Mon, 1 Dec 2014 15:26:06 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21628.27758.767111.663703@fireball.kivinen.iki.fi>
Date: Mon, 01 Dec 2014 15:26:06 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <6905.1417383707@sandelman.ca>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com> <10653.1415740821@sandelman.ca> <CADJ9OA_LFkGDuyG_0bf=07d7cvC9FNRr5cMGTmYw2PR=g9XQHA@mail.gmail.com> <8193.1416253349@sandelman.ca> <21619.12717.53454.214321@fireball.kivinen.iki.fi> <6905.1417383707@sandelman.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 23 min
X-Total-Time: 14 min
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/ygrYKyz6E9E9qnJQytvLMuef32E
Cc: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>, 6tisch@ietf.org, Robert Moskowitz <rgm@htt-consult.com>
Subject: Re: [6tisch] 6tisch join requirements for 6top
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 13:31:28 -0000

Michael Richardson writes:
> 
> Tero Kivinen <kivinen@iki.fi> wrote:
>     >> d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
>     >> (Shared key message integrity code. ditto about broadcast)
> 
>     > How the broadcast/multicast keys are keyed is not really defined in
>     > the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are
>     > identified with the two attributes, Key Source and Key Index. The
>     > format of the Key Source depends on the Key Identifier Mode value.
>     > There are 4 different values for the Key Identifier Mode:
> 
> So, it's not enough to say "use 15.9" for key derivation, having provided
> locally significant certificates.  

Not really, as it would about the same as say use IPsec for protecting
the IP packets. It does not yet specify how the policy is set up and
which kind of configuration should be used in either ends. In 802.15.4
the problems are just bit lower than in IPsec, i.e. you need to define
what kind of keys you want to create, and how to identify those keys. 

> We also need a way to define a key for multicast operations, and I don't see
> a way to do this other than having the join process provision one.  

Who will own that multicast key, i.e. who decides when it is going to
be rekeyed? Who will give that key out to others? Do everybody have
direct connection to the owner of the key? Are there going to be
multiple senders for that key or just one?

What Key Identifier Mode you are planning to identify the key, what
KeySource and KeyIndex values etc?

You could for example specify that the pan coordinator "owns" the
multicast key, so he will take care of rekying etc, and the Key Source
field of the auxiliary security header specifies him.

For example using Key Identifier Mode 1 (everybody set their
macDefaultKeySource to match the extended address of the pan
coordinator) and specifying that Key Index 0x10-0x1f is used for this
multicast group (this would allow 16 groups so pan coordinator can
create new key, and every time he sees someone using old key, he can
send them new key, and ask them to delete old one).

Then on the actual frames the senders most likely would use full
extended address when sending packet to multicast group as source
address (so even those who do not know the senders short address can
get the packet), and use Key Identifier Mode 1 and the Key Source and
Key Index matching the pan coordinator to indicate they are using
multicast group key owned by pan coordinator.

Or something like that. There are other options available too, and you
need to think which one of those is best suited for your needs.
-- 
kivinen@iki.fi