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

From: Mališa Vučinić <[email-masked]>
Date: Thu, 10 May 2018 17:18:34 +0000

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 goal of
homogenizing the join for 6LBR and regular nodes. For now, I added an
optional "network prefix" parameter in the Join Response, carrying the IPv6
prefix of the network for the 6LBR. If there are some pitfalls with this
that I forgot, we can remove it. Similarly, I also added the "network
identifier" parameter in the Join Response, carrying PAN ID for the 6LBR.

Regarding CBOR, the top-level types in Join Request and Join Response are
now all maps, but I removed the use of COSE_Key and COSE_Keyset and defined
our own structures in order to save bytes when transporting keys.
Essentially, this means that we are flexible to add new parameters in the
future in top-level Join Request and Join Response objects, but the inner
objects are fully optimized and poorly extensible due to the use of arrays
and uints.

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 that it allows us to
transport a key that is both K1 and K2, separate K1 and K2, different
security levels for each, and we can also define new combinations of
security levels/frame types in future. The solution only supports KeyIndex
mode of IEEE 802.15.4. Supporting other modes required mimicking 15.4
security structures to configure the security module and would have
required maps everywhere and extensive overhead. If you have any better
idea how to add support for other keying modes of 802.15.4, let me know.

Feedback is welcome, I am continuing with the work on the rekeying
mechanism that we discussed.

Mališa

On Tue, Apr 24, 2018 at 11:06 PM Michael Richardson <[email-masked]>
wrote:

>
> Mališa Vučinić <[email-masked]> 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> something that passes with that key, such as
>     mcr> authenticating the Beacon that
>     mcr> you used to find the Proxy in the first place....
>
>     > Authenticating a beacon that was received long time ago would require
>     > the pledge to store the beacon(s) for potentially an extensive
>     > period... I don't think we need to do that.
>
> No, I'm not suggesting one keeps it for along time.
>
> What I'm saying is that, just after getting the Join Response, a pledge
> now has
> some set of keys.  It will have an authentication key.  It could
> immediately
> authenticate the Beacon that it used to find the Proxy.  That does a few
> things:
>
> 1) validate the Beacon!
> 2) since the key successfully validates the Beacon, it proves that the key
> the
>    pledge got is a current key, and so the key would be marked as
> activated.
>
> Of course, if the pledge doesn't have enough ram to keep the beacon
> around, then
> it shouldn't do that.  It can validate the next beacon instead.
>
>     > Essentially:
>     > - 6LBR: installs the new key, starts using it for outgoing traffic
>     > immediately, removing old keys, if any.
>
>     > - joined node and pledge: installs the new key, keeps using the old
>     > keys for outgoing traffic until it receives incoming traffic secured
>     > with the new key, with all L2 security checks passed. In the special
>     > case of a pledge, there shouldn't be any outgoing traffic before it
>     > decrypts DIO(s) and selects a preferred parent.
>
> Exactly.
>
> --
> ]               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: Michael Richardson <[email-masked]>
Date: Thu, 10 May 2018 13:38:49 -0400

> and defined new parameters and IANA registries with the goal of

I see! Thank you.

    > identifier" parameter in the Join Response, carrying PAN ID for the

I don't quite understand the problem you are trying to fix here, let me come
back to this after I've read the diff again.

    > objects are fully optimized and poorly extensible due to the use of arrays

This is really good work.

    > idea how to add support for other keying modes of 802.15.4, let me

I don't think we need to support modes other than keyIndex, so I think that
this is fine.

-- 
]               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: Michael Richardson <[email-masked]>
Date: Thu, 10 May 2018 14:05:12 -0400

> identifier" parameter in the Join Response, carrying PAN ID for the

https://goo.gl/GL4Pc5 has a diff against -05... I love rfcdiff :-)

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 the tables, and then to populate them with the table
From section 9.

May I also suggest:
1) instead of "unsigned integer", that we just say integer.
2a) that the 1-byte positive and negative integers may be allocated by IETF
   Standard.
2b) that the 2-byte, 3-byte and 4-byte positive integers may be allocated by IANA
    First Come First Served (https://tools.ietf.org/html/rfc8126#section-4.4)
2c) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as
    an experimental range.

   > 9.2.1.1.  Link-Layer Key
   This probably needs an IANA Registry, even if it is closed to just IETF
   Standard Action.
   
(I can write text next week on this)

Did you see my "new-key-start" branch from last week, btw?

On to 6LBR stuff:
    As a special case, when the pledge is configured to play the role of
    the 6LBR, and 6LBR is not co-located with the JRC, the pledge
    additionally needs to be provisioned with:

okay, so I understand the situation.  I think that such a 6LBR probably have
two interfaces, one of them Ethernet, and that it does a join over ethernet.
(It would probably also do a join request over 15.4 as well, since it might
have no idea what's where)

I'm fine with that, but in that case, we need to tell such a pledge how to
find a Join Proxy and/or the actual JRC.   At present, we use the 15.4
specific Enhanced Beacon.  There a bunch of options:
  1) DHCPv6
  2) GRASP
  3) mDNS (DNS-SD)
  4) RA option

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 15 May 2018 19:39:28 +0200

Michael,

See inline.

Mališa

>     First Come First Served (
> https://tools.ietf.org/html/rfc8126#section-4.4)

Yes, this is all fine with me. If you could provide a PR on the latest
minimal-security-06 branch, that would be great!

> Did you see my "new-key-start" branch from last week, btw?

Yes, just worked on this today. I cherry-picked two of your commits but
reorganized the text heavily. CBOR objects are now a separate subsection,
two new CoAP messages for "parameter update exchange" are defined.  The
Parameter Update message (CoAP POST from JRC to the joined node) carries
the same CBOR object as the Join Response. This is the conclusion of the
discussions I had with Christian.

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 distinction between the 6LBR and
non-6LBR nodes. I don't see how the JRC that is not colocated with the 6LBR
can trigger the sending of a link-layer frame secured with the new keys...

Here is the relevant commit, check it out:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/968a9450dde7c93849d6bec278fe28522e9c4c76

> have no idea what's where)

Yes, another interface for the 6LBR to join is an assumption that we need
to state clearly.

> specific Enhanced Beacon.  There a bunch of options:

In the current text somewhere in the one-touch section, there is simply a
requirement that 6LBR needs to be provisioned with the IPv6 address of the
JRC. Then, it can contact it over CoAP/IPv6 directly using global
addressing. I still need to do some changes to CoAP message mapping to
cover this case clearly, but I don't think another protocol is necessary.
Of course, the current text does not preclude the use of another protocol
for that purpose.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 May 2018 14:54:16 -0400

> minimal-security-06 branch, that would be great!
    
I will work on that on Wednesday, when I've 8hr on a train.

    > can trigger the sending of a link-layer frame secured with the new

In such a situation, there will need to be an additional control protocol,
which might be proprietary or future work, but in any case, I think it's okay
if we clearly mark it as out-of-scope.

    > Of course, the current text does not preclude the use of another protocol

Good, so we can just mark it as out-of-scope.
I think that this is okay.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 May 2018 00:47:21 +0300

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 that it allows us to transport a key that
> is both K1 and K2, separate K1 and K2, different security levels for each, and
> we can also define new combinations of security levels/frame types in future.
> The solution only supports KeyIndex mode of IEEE 802.15.4. Supporting other
> modes required mimicking 15..4 security structures to configure the security
> module and would have required maps everywhere and extensive overhead. If you
> have any better idea how to add support for other keying modes of 802.15.4,
> let me know.

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 be good idea to include algorithm
parameter to the Link-Layer Key structure with only one value of
AES-CCM-128 now. Also restructuring the text about the key_value to
say "key length of the algorithm" instead of fixed 16, i.e., say that
ignore this key if the length of the key_value does not match the
length of the key specified by the algorithm.

This TG15.4y SECN work is just starting and will most likely be
finished in few years time. The main reason for that work, is to add
AES-CCM-256 option for the IEEE 802.15.4. This will make it possible
for 802.15.4 to conform with requirements that some organizations
have, i.e., allow using 256 bit keys to provide some protection
against quantum computers.

Makeing this minimal-security draft to only allow AES-CCM-128 and not
even allow easy extensibility for other algorithms would be bad idea
now. 
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 16 May 2018 09:53:04 +0200

> if we clearly mark it as out-of-scope.

There shouldn't be any need for an additional control protocol with the
current text. In the processing rules, we differentiate between 6LBR
receiving a key parameter and non-6LBR nodes. Essentially, 6LBR upon
reception of the key parameter immediately removes the old keys and starts
using the new keys for all outgoing traffic. Non-6LBR nodes wait until they
receive one frame secured with the new keys and upon that event remove the
old keys.

The pledge joining for the first time follows the same behavior, albeit
with a note that it is possible to speed up the process by storing an EB
that was used to discover the JP.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 16 May 2018 10:56:51 +0200

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 from the key length,
I also added the nonce length in the description of the algorithm in the
registry.

Mališa

On Tue, May 15, 2018 at 11:47 PM Tero Kivinen <[email-masked]> wrote:

> parameter,

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 May 2018 01:35:58 +0300

Mališa Vučinić writes:
> The algorithm identifier is added, it is optional and if it is not present the
> IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the key length, I also
> added the nonce length in the description of the algorithm in the registry.

Looks good. Formatting the algorithm ids as negative numbers is bit
wierd, but I assume it allows making the field optional as you can
detect from the the nint that it is algorithm identifier not key
usage...

Other option could be to combine the key_usage and algorithm to same
field, i.e., add algorithm to key_usage tables, and when AES-CCM-256
is added then double the key_usage entries to contain both possible
algorithms. This might have the same problems TLS have with cipher
suites, that we end up with quite large table with all possible
combinations.

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 key_usage_and_algorithm as one octect for first few algorithms.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 18:55:07 -0400

Tero Kivinen <[email-masked]> wrote:
    > than AES-CCM with 128-bit keys. To make it so that this structure would
    > also allow that it would be good idea to include algorithm parameter to
    > the Link-Layer Key structure with only one value of AES-CCM-128
    > now.

Can you suggest a name for this field that will be synergize with the the
future 15.4 work?

    > Also restructuring the text about the key_value to say "key length
    > of the algorithm" instead of fixed 16, i.e., say that ignore this key
    > if the length of the key_value does not match the length of the key
    > specified by the algorithm.

Being CBOR, the key itself is self-describing in it's length, but I take your
point.

    > even allow easy extensibility for other algorithms would be bad idea

Agreed.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 21:06:13 -0400

Mališa Vučinić <[email-masked]> wrote:
    > Thanks Tero for this feedback! Could you check if this commit takes
    > care of it:

    > The algorithm identifier is added, it is optional and if it is not
    > present the IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the

is there a reason you used negative numbers for algorithms?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 21:07:25 -0400

Tero Kivinen <[email-masked]> 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

Or, if the value is a CBOR array, then it's [key_usage, algorithm] rather
than key_usage.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2018 21:46:10 -0400

> is there a reason you used negative numbers for algorithms?

I figured it out, you are making the algorithm optional.

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 24 May 2018 10:40:52 +0200

@Tero,

Getting back to this, see inline.

On Thu, May 17, 2018 at 12:36 AM Tero Kivinen <[email-masked]> wrote:

> present the

Yes, that was the intent but see below.

> suites, that we end up with quite large table with all possible

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
for our purposes and simplifies the CBOR decoder that needs to be
implemented. We are back to integers now, and I allow both unsigned and
negative in order to have larger 1-byte ranges in the registry.

The changes are at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/15133e113e2efaa3c42d5f844f12c28100e5f17b

Could you also take a look at the "Key Usage values" table and see if you
can recommend any other setting for the initial inclusion in the registry?

Mališa

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 24 May 2018 17:09:53 +0200

All,

I resolved the issues we had open on minimal-security and reworked
editorially the document quite heavily. Since the protocol we define is
quite generic, I renamed it to "Constrained Join Protocol (CoJP)",
suggested pronunciation as "cojeep". Let me know if you dislike the new
name, or if you have a better suggestion.

I plan to publish -06 before EOB tomorrow, if you have any comments that
you would like to see in for -06, please send them to the list before.

The source of the document in Markdown is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/src/master/draft-ietf-6tisch-minimal-security.mkd

Mališa

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 May 2018 14:11:35 -0400

> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/15133e113e2efaa3c42d5f844f12c28100e5f17b

Good.

Tero, I am thinking that when 802.15.4 puts out the AES256 support, that
there will have to be an IETF document that adds things here.  Are there
other things (in other WGs) that will also need updating?  It would be good
to start an internet-draft to collect things.