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

From: Göran Selander <[email-masked]>
Date: Wed, 22 Feb 2017 06:53:36 +0000

Before someone slaps my fingers I should disclaim that the message
exchange was just a sketch to be able to discuss the number of messages,
which party initiates, who encrypts first etc. As we all know security
protocols always require a lot of considerations, in this case there is
e.g. missing a MAC of the identity of the signing party.

Göran 

On 2017-02-21 17:50, "6tisch-security on behalf of Göran Selander"
<[email-masked] on behalf of
[email-masked]> wrote:

>Hi Michael,
>
>I edited the presentation during and after the meeting to summarise some
>points made. The protocols are as presented, the annotation I’ve added.
>
>Göran
>
>On 2017-02-21 15:48, "Michael Richardson" <[email-masked]> wrote:
>
>>
>>Can I get a copy posted to the list for the records?
>>Thanks.
>>
>>--
>>]               Never tell me the odds!                 | ipv6 mesh
>>networks [
>>]   Michael Richardson, Sandelman Software Works        | network
>>architect  [
>>]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails
>>   [
>>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 23 Feb 2017 09:41:23 +0100

Hi Goran and Michael,

Let me ask very high-level questions about the presented slides.
Is the diffie-hellman part a replay of the EDHOC draft? or an optimized 
extension, or completely new?
Is the SK part an OSCOAP scenario?

Will the use of CoMI be described in the minimal security draft?

thanks for answering,

Peter

Göran Selander schreef op 2017-02-22 07:53:
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Göran Selander <[email-masked]>
Date: Thu, 23 Feb 2017 22:48:31 +0000

Hi Peter,

This was the first meeting I participated in this year and I just wanted
to understand the current discussion. The slides were intended for a high
level discussion of functionality without binding to specific protocol,
but, yes, EDHOC and OSCOAP does the job and as far as I understand is in
scope of the minimal security draft.

As for CoMI, it could either take advantage of the established security
for protecting CoMI operations, or in some way be part of the security
solution, which I think Michael was referring to. In the latter case it
needs to be specified how CoMI operations are secured.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Feb 2017 08:31:15 -0500

peter van der Stok <[email-masked]> wrote:
    > Let me ask very high-level questions about the presented slides.  Is
    > the diffie-hellman part a replay of the EDHOC draft? or an optimized
    > extension, or completely new?  Is the SK part an OSCOAP scenario?

It's EDHOC.  This is all OSCOAP.

    > Will the use of CoMI be described in the minimal security draft?

Ugh. There seems to be much resistance to doing that.
I am preparing text to say two things, and I need help with the second
part.

Part 1) saying that rekey is out of scope.

Part 2) explaining how to use the exchange to key additional OSCOAP
     channels.

Originally, I was going to point to rfc5295, until I realized that HKDF was
embedded in things already, no point in going further.

Goran, is there some way to specify that one runs section 6 (Derive Traffic
Secret) with different inputs to get additional traffic secrets for
additional applications?

Could COSE_KDF_Context include one final, optional element, which might be
called "subapplication_name"?  I'm not sure if that belongs after
SuppPubInfo, or within it.

We *could* just continue to use the traffic secret derived for
6tisch-minimal, but that seems too intricately linked from a specification
point of view.  (I notice that OSCOAP totally supports using the same keys
with a CoAP client/server role reversal)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Göran Selander <[email-masked]>
Date: Fri, 24 Feb 2017 14:31:26 +0000

Hi Michael,

>Secret) with different inputs to get additional traffic secrets for

Yes, this is straightforward in the latest version on the Github:
https://ericssonresearch.github.io/EDHOC/

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. 

>SuppPubInfo, or within it.

I guess the label above would be sufficient, right?

>point of view. 

Different applications should use different keys, so you should define
different labels and then be able to derive the keys as indicated above.

> (I notice that OSCOAP totally supports using the same keys

Yes, but there are different keys in different directions. So one node
will use the same key for sending, independently of it is client and
sending a request or server sending a response (different IVs are used
each time), and, analogously, one key for receiving.

Hope that helps.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Feb 2017 21:13:55 -0500

> How this is used to derive the OSCOAP master secret/salt you find in

https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/15387091977d408103cd72f12f7008a50483fc40

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-