Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: > I've just adopted this "TLS" approach: key_usage and algorithm are merged, > and a new column "Algorithm" was added in the registry to explicitly state > the link-layer techno / algorithm in use. I believe this is quite enough >

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

@Tero, Getting back to this, see inline. On Thu, May 17, 2018 at 12:36 AM Tero Kivinen wrote: > Mališa Vučinić writes: > > Thanks Tero for this feedback! Could you check if this commit takes care > of > > it: > > > > >

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael Richardson wrote: > Mališa Vučinić wrote: >> Thanks Tero for this feedback! Could you check if this commit takes >> care of it: >> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/ >>

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Tero Kivinen wrote: > Or we could rename key_usage to key_usage_and_algorithm and split it so > that (key_usage_and_algorithm & 0x1f) is the actual key_usage, and > (key_usage_and_algorithm >> 5) is the algorithm id, which would still > encode

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: > Thanks Tero for this feedback! Could you check if this commit takes > care of it: > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/ > dee6cf8074f2 > The algorithm identifier is added, it is optional

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Tero Kivinen wrote: > Note, that there is work ongoing in the IEEE to add algorithm agility > to the IEEE 802.15.4, i.e., make it possible to use other algorithms > than AES-CCM with 128-bit keys. To make it so that this structure would > also allow that it would

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić writes: > Thanks Tero for this feedback! Could you check if this commit takes care of > it: > > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2 > > The algorithm identifier is added, it is optional and if it is not present the >

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Thanks Tero for this feedback! Could you check if this commit takes care of it: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2 The algorithm identifier is added, it is optional and if it is not present the IEEE802154-AES-CCM-128 algorithm is assumed. Apart

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

On Tue, May 15, 2018 at 8:54 PM Michael Richardson wrote: > > > > I generalized the rekeying text so that it falls under the > processing rules > > of the CBOR Link-Layer Key parameter. The first join of a pledge just > > becomes a special case but there is a

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić writes: > I also worked out a new key signaling mechanism using a "key usage" parameter, > where a single uint value from the registry specifies the IEEE 802.15.4 > security level to be used and the appropriate frame types the key can be used > with. The mechanism is flexible in

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: >> (I can write text next week on this) >> > Yes, this is all fine with me. If you could provide a PR on the latest > minimal-security-06 branch, that would be great! I will work on that on Wednesday, when I've 8hr on a train.

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, See inline. Mališa On Thu, May 10, 2018 at 8:05 PM Michael Richardson wrote: > > I see that you have an IANA registry for the Join Request and Join Response > key values. These tables need to have names and the IANA instruction needs > to ask them to create

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: > I did quite a bit of work in the document, including some CBOR wizardry, > and defined new parameters and IANA registries with the goal of > homogenizing the join for 6LBR and regular nodes. For now, I added an > optional "network

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: > I did quite a bit of work in the document, including some CBOR wizardry, > and defined new parameters and IANA registries with the goal of I see! Thank you. > homogenizing the join for 6LBR and regular nodes. For now, I added an

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, all, tl;dr: The relevant WIP commit is at https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/21ad042639b4617bf7a6993e9140a65d702680ef .. I did quite a bit of work in the document, including some CBOR wizardry, and defined new parameters and IANA registries with the

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: mcr> I'd say that you always do this with any new key if you mcr> have no keys. mcr> I don't think we need a flag. mcr> In fact, even for the "0th key", you would start using it mcr> as soon as you see mcr>

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Mališa Vučinić wrote: > The JRC would need to guess how long it may take for it to reach every > node in the network. I think that it makes sense that the JRC does not > need to be aware of network specifics. Instead, it can update the key > of the 6LBR last,

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, Reviving the discussion on the rekeying mechanism. See below. Mališa >> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson < >> mcr+i...@sandelman.ca> wrote: >> >>> >>> >>> I'd say that you always do this with any new key if you have no keys. >>> I don't think we need a flag. >>>

[6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

See inline. On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne wrote: > > *About COSE_Key* > > The issue raised is that, during a rekey of key K2 by the JRC, the JRC > cannot specify an ASN from which the new key is to be used. > The JRC would need to guess how long it