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

From: Mališa Vučinić <[email-masked]>
Date: Thu, 22 Mar 2018 16:56:32 +0000

All,

We had a couple of side discussions during IETF 101 on the updates to the
minimal security draft. We need to (1) support extensibility to allow
future specs to add additional parameters to the join response structure,
and it seems that (2) we can cover link-layer rekeying easily through the
use of the FETCH CoAP method and Observe option in the Join Request.

To tackle (1) the proposal is to change the top-level CBOR array with a
map, using an IANA registry of unsigned int for labels, typically adding
one byte of overhead with each map element. This will allow easy extension
by future specs.

To tackle rekeying, the proposal is to use the FETCH CoAP method and add
the Observe CoAP option in the request. FETCH is essentially a parametrized
GET, allowing us to do Observe on the resource. The mechanism allows the
JRC to asynchronously send a response to the nodes in the network. Other
than adding the Observe option, together with the new link-layer key we
also need to carry the ASN at which this key is scheduled to be rolled out.
What COSE parameter the ASN will be transported is TBD. This mechanism will
allow the JRC to change the network keys, and also exclude nodes from the
network, since the responses are unicast. All of this goes over the OSCORE
encrypted channel.

One doubt I have is how does the JRC send the Observe response to the
joined node, when the request came over a Join Proxy. Essentially, the JRC
needs to send the response to the global IPv6 address of the joined node,
that it never used before, but it is able to construct it, as it knows the
network prefix and the node identifiers (EUI-64, short address).
@Christian, is there any problem of doing this in terms of CoAP?

@all, Please speak up if you have any objections or proposals.

Mališas

-- 
Mališa

---

From: peter van der Stok <[email-masked]>
Date: Thu, 22 Mar 2018 18:02:59 +0100

> joined node, when the request came over a Join Proxy. Essentially, the
> JRC needs to send the response to the global IPv6 address of the
> joined node, that it never used before, but it is able to construct
> it, as it knows the network prefix and the node identifiers (EUI-64,
> short address). @Christian, is there any problem of doing this in
> terms of CoAP?

Why not have the joined node, after joining, send a GET with observe to 
the JRC to receive rekeys?

Peter
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 22 Mar 2018 17:15:50 +0000

> the JRC to receive rekeys?

Hi Peter,

Would there be any semantical difference to doing that in respect to doing
it in the Join Request? If we can do it in 2 messages, why use 4? I  see it
more as the implementation problem, since JRC+CoAP implementation will need
to override the IP address of the observing client. In terms of compliance
with the security specs, I would say that it's OK, as we use OSCORE, not
DTLS where there is a binding of the session with IP addresses.

Mališa
-- 
Mališa

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Mar 2018 17:39:17 +0000

Mališa Vučinić <[email-masked]> wrote:
    > in the network. Other than adding the Observe option, together with the
    > new link-layer key we also need to carry the ASN at which this key is
    > scheduled to be rolled out. What COSE parameter the ASN will be

I disagree with this method.

I think that the mechanism that was explained at:
  https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#section-4

is a better workable solution.  Deploy all the new keys (it may take some
days on sleep networks), and then have nodes switch when they see traffic
with the new key.

-- 
]               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, 22 Mar 2018 18:42:05 +0100

Mališa Vučinić schreef op 2018-03-22 18:15:
> On Thu, Mar 22, 2018 at 5:03 PM peter van der Stok
> <[email-masked]> wrote:
> 
> Would there be any semantical difference to doing that in respect to
> doing it in the Join Request? If we can do it in 2 messages, why use
> 4? I  see it more as the implementation problem, since JRC+CoAP
> implementation will need to override the IP address of the observing
> client. In terms of compliance with the security specs, I would say
> that it's OK, as we use OSCORE, not DTLS where there is a binding of
> the session with IP addresses.

No semantic difference that I know. You expressed a worry about 
addressing the joining node from JRC.
Not sure any more, but do you use the IP-in-IP proxy? If yes, 
maintaining the encapsulation in all following traffic seems necessary.

> Mališa--

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 23 Mar 2018 10:12:16 +0000

> maintaining the encapsulation in all following traffic seems necessary.

No, I do not consider IP-in-IP proxy here. The pledge sends the Join
Request to the Join Proxy (CoAP), so the JRC effectively does not know the
IPv6 address of the pledge at this time, when the Observe option is
included. The Join Response is similarly sent over the Join Proxy (using
the Stateless-Proxy mechanism), but my doubt was related to the fact that
subsequent Observe responses for rekeying, for example, should not go over
the Join Proxy (the pledge joined the network, became a joined node,
selected a potentially different parent, etc).

In RFC7641, I see the following text as relevant:

" The entry in the list of observers is keyed by the client endpoint and
the token specified by the client in the request. If an entry with a
matching endpoint/token pair is already present in the list (which, for
example happens when the client wishes to reinforce its interest in a
resource), the server MUST NOT add a new entry but MUST replace or update
the existing one."

I am tempted to say that this does not prevent us from updating the client
endpoint (but not the token) based on implicit knowledge at JRC. Do you
agree?
-- 
Mališa

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 23 Mar 2018 10:52:54 +0000

> days on sleep networks), and then have nodes switch when they see traffic

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.

One of my goals with this extension to minimal-security is to remove any
need for an additional protocol between the 6LBR and the JRC.
6LBR can act as any other pledge before triggering the network formation
process by sending a Join Request itself. The only additional parameter
that the 6LBR needs in respect to the pledges is the IPv6 address of the
JRC and this can be done during one-touch provisioning. Once it receives
the Join Response, 6LBR can start advertising the network by using the
link-layer keys it received.

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.

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".
- 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

What do you think?

Mališa
-- 
Mališa

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Mar 2018 22:30:47 +0000

> Would there be any semantical difference to doing that in respect to doing it
    > in the Join Request? If we can do it in 2 messages, why use 4? I  see it more
    > as the implementation problem, since JRC+CoAP implementation will need to
    > override the IP address of the observing client. In terms of compliance with
    > the security specs, I would say that it's OK, as we use OSCORE, not DTLS where
    > there is a binding of the session with IP addresses.

While I can conceive of updating the OBSERVE registration in the JRC so that
subsequent messages go out to the assigned address, it would seem to be
possibly violate the some amount of laying between applications and coap (and
OSCORE) libraries.

I think we should use FETCH and suggest the OBSERVE option be added, but that
the client MUST be willing to repeat with a GET if the JRC does not return
the OBSERVE option.   Given that, I think that we have to document the second
situation.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Mar 2018 22:31:53 +0000

peter van der Stok <[email-masked]> wrote:
    > No semantic difference that I know. You expressed a worry about addressing
    > the joining node from JRC.
    > Not sure any more, but do you use the IP-in-IP proxy? If yes, maintaining the
    > encapsulation in all following traffic seems necessary.

The additional OBSERVE replies have to go directly to the new (2-byte, short
address) of the new node (when it's no longer a pledge).

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Mar 2018 22:36:00 +0000

Mališa Vučinić <[email-masked]> 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?

    > - 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".
    > authenticity check at L2 passes, it removes the old keys and starts using the
    > new key for all outgoing traffic

Yes.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 26 Mar 2018 09:00:19 +0200

which I prefer to pulling in the
> Shall I suggest some text it github?
Fine with me.

Peter

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 26 Mar 2018 09:00:18 +0200

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 <[email-masked]>
wrote:

> differentiate

-- 
________________________________________

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
________________________________________

---

From: peter van der Stok <[email-masked]>
Date: Mon, 26 Mar 2018 09:05:53 +0200

Michael Richardson schreef op 2018-03-24 23:31:
> maintaining the

Now, I am confused.
I thought Observe uses level 3 IP addresses?
Where do you propose that the routing (filling in the short address) to 
the new node takes place? in the JRC?
Does that involve the JRC application filling in the routing table when 
the reply from the EST server returns?

---

From: Christian M. Amsüss <[email-masked]>
Date: Mon, 26 Mar 2018 10:41:55 +0200

Hello Mališa,

> endpoint (but not the token) based on implicit knowledge at JRC. Do you

observation is fundamentally a hop-to-hop thing (terminated at proxies);
both the token and the observation counter are scoped to those hops, and
while a minimal proxy may get away with passing them on unmodified, I
doubt that that can be used to form a stable mechanism.

The topic of a delegated observe has been brought up before[1] (with a
focus on nomadic devices), and was not followed up to after initial
comments. If minimal-security were to do observations that hops off a
proxy observation to a direct one, it'd need a specification similar to
that (with its holes filled) to let that observation hop off smoothly.

(Whether the observation is FETCH or GET is immaterial here, and in this
setting it's a good approximation to say that the difference is that the
FETCH allows binary data with a mime type to be part of the request,
which would in a GET need to be squished into a query string).

As I understand, even richardson-6tisch-minimal-rekey needs to transport
that modelled data, so at any rate I can suggest two alternatives to a
hopping observation:

* Don't observe through the proxy, but establish an observation after
  the address has been assigned.

  This incurs cost of two additional packages, but is conceptually
  simple and straightforward.

* Establish a dynlink (formerly bindings) to make the JRC PUT (or PATCH)
  the node.

  This would take two additional messages as well (the former pledge
  requesting a dynlink once it knows its final address, plus its
  response). This is the less common but more versatile approach to
  observation.

  An advantage over plain observation is that it might be possible to
  establish this link in another way than explicitly requesting it (eg.
  piggy-backing an "and when you've managed, please keep me posted on /X
  relative to whatever address I might have then", or by the JRC knowing
  from somewhere else that such a binding is to be established)

6tisch-minimal-rekey sounds like it is a valid expectation that the
nodes will use CoMI; if that is the case and this approach is followed,
the PUT/PATCHing that would be the result of a dynlink cold probably be
set up implicitly.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/-emsRTJmyyFHlrNwbJkqGfXQaYw

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom