Subject: Re: [6tisch-security] slides you presented

From: Göran Selander <[email-masked]>
Date: Mon, 6 Mar 2017 17:13:38 +0000

Hi Michael,

You asked how to define key identifiers for the multiple keys derived with
EDHOC.

First of all, it is not clear that it is needed in this case. If you
derive OSCOAP keys for use when protecting communication between one
device and its management device, then those keys could be used for
accessing multiple resources and reversing roles of client and server.

In the current version of EDHOC each party can define its own identifier
for one derived key, enabling local uniqueness without wasting bytes with
large identifiers.

If you want to guarantee global uniqueness for multiple identifiers, one
way is to derive large pseudorandom numbers using the same key derivation
and special labels.  How to generate locally unique small key identifiers
for multiple keys is currently not in scope of EDHOC, and in general
depends on the application and how the locally generated identifiers are
kept unique.
One application could e.g. order and keep track of key identifiers and
allocate derived keys sequentially.

Hope that helps.

Göran

On 2017-02-26 03:13, "Michael Richardson" <[email-masked]> wrote:

>
>Göran Selander <[email-masked]> wrote:
>    > Section 3.2 describes the key derivation and allows the definition
>of an
>    > application specific label (byte string) which is used to derive an
>    > application specific key from the key established through the run
>of EDHOC.
>
>    > How this is used to derive the OSCOAP master secret/salt you find in
>    > appendix B.2.
>
>https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/15
>387091977d408103cd72f12f7008a50483fc40
>
>--
>Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Mar 2017 12:45:30 -0500

> accessing multiple resources and reversing roles of client and server.

We do not have to derive new keys, it is true.

My thought is that doing this is cleaner cryptographically, and also isolates
one set of keys in one application to another.

I suggest this as a way to most clearly seperate the 6tisch-minimal-security
bootstrap process from the 6tisch-minimal-rekey process.  I don't think it's
essential.

    > for one derived key, enabling local uniqueness without wasting bytes with

Agreed.