Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić <[e-mail]>]

Hi Thomas,

See inline.

Mališa

On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne <[e-mail]>
wrote:

> There are two seperated discussions going on in this thread. @Malisa, if
> you agree, let's split the thread.
> I have clarifying questions about both.
>
> *About OBSERVE*
>
> The issue raised is that, during the join request/response exchange
> between the pledge and the JRC, the JRC never learns the IPv6 address of
> the pledge (thanks to the Stateless-Proxy CoAP option). This means that, if
> the join request is carried by a CoAP FETCH message with Observe, the JRC
> has no means of addressing the joined node when the Observe triggers.
> Doing a second GET with Observe once the pledge has joined defeats the
> purpose of going for FETCH.
> Any other option?
>

This discussion is now under the thread: *Observe for rekeing (was: Updates
to minimal-security-06).*

I agree with your summary. Right now we are discussing whether the joined
node can expose a resource (e.g. /j), that the JRC can POST to and update
the key as it knows implicitly joined node's IPv6 address.


> *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.
> A strong requirement is for a node NOT have a node rejoin for each rekey.
> Must we use the COSE_Key structure?
> Is the the message sent by the JRC containing the new key end-to-end
> ACK'ed, i.e. does the JRC know it got received?
>

Moving the discussion about the rekeying mechanism to the thread: *Rekeying
for minimal-security (was: Updates to minimal-security-06).*


>
> Thomas
>
> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson <
> [e-mail]> wrote:
>
>>
>> Mališa Vučinić <[e-mail]> wrote:
>>     mcr> I think that the mechanism that was explained at:
>>     mcr>
>> https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#
>>     mcr> section-4
>>
>>     mcr> is a better workable solution.  Deploy all the new keys (it may
>> take some
>>     mcr> days on sleep networks), and then have nodes switch when they
>> see traffic
>>     mcr> with the new key.
>>
>>     > Thanks, Michael, for the reminder on this document, I have to say
>> that I forgot
>>     > about it.. IIUC, the issue you have with the mechanism I proposed
>> is that the
>>     > JRC in some cases may not know how long it could take to deploy the
>> keys so
>>     > that it cannot properly set the ASN. I think that's a valid concern
>> and that it
>>     > would indeed be better if we could decouple the JRC from the inner
>> network
>>     > specifics as much as possible.
>>
>> Exactly.
>> It does not have to change significantly what you have, it just has to
>> include the (new) keyIndex.
>>
>>     > To do this and support rekeying with your proposal, we need to
>> differentiate
>>     > between "start using this key" and "install the key but don't start
>> using it
>>     > until you see it being used in the network", for 6LBR and joined
>> nodes to
>>     > follow, respectively. We can likely do this by extending the
>> COSE_Key map with
>>     > an additional parameter for this purpose, which I prefer to pulling
>> in the
>>     > whole COMI machinery, as is suggested in the minimal-rekey draft.
>>
>> I agree, we don't need COMI, just the text about when to start using the
>> new key.
>> Shall I suggest some text it github?
>>
>>     > Essentially, the process would be:
>>     > - the JRC deploys the new key(s) to all the nodes except to the
>> 6LBR.
>>     > - nodes will install them, but keep using the old keys because the
>> new COSE_Key
>>     > parameter is set to "install the key but don't start using it until
>> you see it
>>     > being used in the network".
>>
>> 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.
>>
>> In fact, even for the "0th key", you would start using it as soon as you
>> see
>> something that passes with that key, such as authenticating the Beacon
>> that
>> you used to find the Proxy in the first place....
>>
>>     > - deploy the key to the 6LBR, with the COSE_Key parameter set to
>> "start using
>>     > now".
>>     > - once a node sees the new key being used and the replay protection
>> and the
>>     > authenticity check at L2 passes, it removes the old keys and starts
>> using the
>>     > new key for all outgoing traffic
>>
>> Yes.
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh
>> networks [
>> ]   Michael Richardson, Sandelman Software Works        | network
>> architect  [
>> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
>> rails    [
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> ________________________________________
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Analog Devices
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> ________________________________________
>