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

[Thomas Watteyne <[e-mail]>]

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?

*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?

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
________________________________________