Subject: Re: [6tisch] questions about draft-richardson-security-6top

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 13:43:54 +0200

Michael,

In the situation where the DAO from the JA carries the information about the
> JN, then the LBR/DODAG root would receive that information.  The LBR needs
> to
> be told where the JCE is by out-of-scope means. I.e. you have to configure
> it: But of the common case where it's co-located. it's a no-op.
> As the JCE then reaches out *to* the JN, neither the JN nor the JA need to
> know who/where the JCE is.

You seem to assume the JN does not talk end-to-end with the JCE, but the
LBR serves as an application-layer proxy? Man-in-the-middle? I must be
missing something.

Related question: does the JN at some point learn the address of JCE and/or
PCE? More generally, how is the "handover" done between the JCE and PCE?

The JCE and/or PCE would have to enable the JA to actually function as a JA:
> I think that there may be topological knowledge required to make sure that
> there are enough JA enabled, and not too many.

+1

Thomas

On Thu, Apr 30, 2015 at 6:51 PM, Michael Richardson <[email-masked]>
wrote:

>
> Kris Pister <[email-masked]> wrote:
>     > * In section 3.2 you refer to
> kelsey-intrarea-mesh-link-establishment a
>     > couple of
>     > times as a way to do key exchange.  Reading that document it seems
> to me like
>     > it gives me a way to exchange parameters, but doesn't define
> anything with
>     > regard to key exchange, yes?
>
> That's a good point: MLE was supposed to grow ways to do key exchange, but
> as
> the document seems to have gotten lost in the IETF independent submission
> track it has perhaps failed to get anywhere, and I'm just going on what I
> was
> told MLE would do for the world.
> 802.15.9 is/has defined a way to use (diet)HIP, or IKEv2 over the link;
> I think that in the name of code space/protocol reuse, one would like to
> have
> a DTLS-based mechanism, but to date I'm told no TLS person has specified
> something.
>
> Yes, there is a major gaping hole here.
>
>     > * 3.4 Was there a final decision on End to End?  Do you have a strong
>     > opinion?
>     > It seems to me that DAO is the right answer.
>
> Yes, the JA "announces" the attachment of the JN via DAO. In a non-storing
> DODAG, that DAO is unicast to the route, so intermediate parts of the mesh
> neither see anything nor know anything of the new node.
>
> JN traffic flows upwards without any special considerations (other than
> bandwidth limits, and potentially being programmed into specific tracks),
> and
> that it flows downwards using source routes, i.e. using RH3.
>
> We still have some conflict as to whether the address of the JN can be a
> link-local address, whether this address is permitted in an RH3, and if the
> JA happens to have more than one interface (such as two kinds of radios),
> if
> the JA can make sense of that link local address without some interface
> context.
> I think that this specific topic should be addressed in the just
> re-chartered
> ROLL WG work on RH3.
>
> Pascal has taken the approach that we need to provision each JA with a
> fresh
> set of /64 ULA for joining nodes (one per interface), and while that felt
> really messy to me at first, I've warmed to the idea recently.
>
>     > * 6.1.8 I feel like I'm missing how the JN or JA or LBR figures out
> who the
>     > JCE is.
>
> In the situation where the DAO from the JA carries the information about
> the
> JN, then the LBR/DODAG root would receive that information.  The LBR needs
> to
> be told where the JCE is by out-of-scope means. I.e. you have to configure
> it: But of the common case where it's co-located. it's a no-op.
> As the JCE then reaches out *to* the JN, neither the JN nor the JA need to
> know who/where the JCE is.
>
> There is perhaps some concern that the JN/JA could be experience some kind
> of
> DoS by other nodes pretending to be the JCE; those nodes would have to be
> already-joined nodes that went rogue though, and the traffic would always
> be
> internal.
> The question then becomes should the JA allow anything through, and if the
> answer is no, then I think that the JCE needs to, when it provisioned the
> JA
> (as the JA was at some point, a JN itself), tell the JA there JCE traffic
> comes from.
>
> The JCE and/or PCE would have to enable the JA to actually function as a
> JA:
> I think that there may be topological knowledge required to make sure that
> there are enough JA enabled, and not too many.
>
> We could go a step further and define/allocate some kind of anycast or well
> known address for the JCE (to use as a source IP), but I think that this
> would get in the way of potentially having more than one JCE, and is
> probably
> unnecessary.
>
>     > * 12.2 jamming: "what prevents a node from transmitting when it is
> not their
>     > turn"
>     > nothing, unfortunately.
>
> Some of these questions from things asked on design team calls.
> I actually think both questions in 12.2 are actually out of scope.
>
>     > * 12.2 "can a node successfully communicate with a peer at a time
> when not
>     > supposed to"
>     > this is up to us to some extent.  The MAC is certainly capable of
> strictly
>     > enforcing
>     > the schedule, so in an RX slot from A it can (and will, in the
> products that
>     > Dust ships)
>     > reject a packet from B even if it has the right MIC.  Doesn't help
> in aloha
>     > slots of course.
>
> The detail is, I think, that the MAC does this without waking up
> higher-level functions, and that the packet doesn't get forwarded so the
> the
> "cheating" node does not benefit.
> The MAC still has to be awake, and the transmission still might interfere
> with a legitimate sender.
>
>     > At a high level, it seems like you are leaving open the possibility
> that the
>     > joining network
>     > and the production network might be physically the same devices but
> with
>     > different
>     > DODAG, L2 resources, etc?  I'm trying to figure out why I need the
> new
>     > LDevID.  Won't I need to go through essentially the same process
> again
>     > with the production network?
>     > I feel like I'm missing something.
>
> Part of the reason to reject building a seperate join network is that it
> will
> require significant resources (larger memory in particular) which will
> mostly
> never be used.   So if we can minimize the unique L2 resources to be at the
> edge, and avoid a second DODAG that is good.
>
> If your network is designed to do per-node-pair keying, then the LDevID is
> what
> you'd be using to authentication for that key exchange.  You could also use
> it to provide L3 security at the RPL level, and it might also be used by
> applications.
> If your network will just provision a MasterKey for network-wide L2 keying
> (via JCE), then no LDevID need be provided, but it might still be useful
> for the applications.  There is a place right here to bootstrap a secure
> relationship between an ACE (Client) Authorization Server and Client/RS.
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 May 2015 15:52:34 -0400

Thomas Watteyne <[email-masked]> wrote:
    mcr> In the situation where the DAO from the JA carries the information
    mcr> about the JN, then the LBR/DODAG root would receive that
    mcr> information. The LBR needs to be told where the JCE is by
    mcr> out-of-scope means. I.e. you have to configure it: But of the common
    mcr> case where it's co-located. it's a no-op.
    mcr> As the JCE then reaches out *to* the JN, neither the JN nor the JA
    mcr> need to know who/where the JCE is.

    > You seem to assume the JN does not talk end-to-end with the JCE, but
    > the LBR serves as an application-layer proxy? Man-in-the-middle? I
    > must be missing something.

no, that's not what I'm saying at all.  I'm not sure how you get to that
conclusion from the above text....

    > Related question: does the JN at some point learn the address of JCE
    > and/or PCE? More generally, how is the "handover" done between the JCE
    > and PCE?

In the case where the PCE and JCE are co-located... i.e. really different
aspects of the same process, I think the handover is easy.  Where they are
not the same process, then there are really two problems:
    1) how does the JCE/LBR tell the PCE about the new node?
    2) how does the PCE <-> JN relationship work?

I think that the LBR/JCE/PCE protocol could eventually be subject to
standardization, but for the moment I'm happy to let this be vendor
proprietary.

The JCE will have programmed the JN with appropriate credentials and trust
anchors such that it can talk to the PCE.  That happens during the join
process.  The JN then restarts (probably, it should reboot) and joins the
"production" network, and sends DAOs, which means the LBR/DODAG root will
learn of the (new) node.  Note that at this point there is really no
difference between the node being "new", and the node having just returned to
service/connectivity after some event.  (Maybe nodes on the forklift power
down at night, or maybe they lose connectivity when the forklift leaves the
building... or a metal door opens/closes...)

The LBR will need to inform the PCE that it knows of a now connected node,
and the PCE will need to reach out using 6top.  The PCE can authenticate the
new node using the locally significant credential, and the JN can
authenticate the PCE using the trust anchor that the JCE provisioned.

A power and compute-saving thing for the JCE to do would be to have the
JN provide the JCE with a session-resumption ticket... and for the JCE
to pass that onto the PCE.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 13 May 2015 00:41:20 -0700

> On 12 May 2015, at 12:52, Michael Richardson <[email-masked]> wrote:
> 

This seems like a great idea for nodes that may often loose connectivity and would need to re-run the join process. For instance, we work with energy-harvesting nodes with very small batteries (20 mAh) and repeating the whole thing once some energy becomes available is simply out of the question.

Since the format of a stateless session ticket from RFC 5077 does not affect interoperability, in the context of 6TiSCH we would need to mandate the session resumption support on the JCE side. However, could it be possible to use a 6TiSCH-specific format of this ticket for the initial join as well, where the session state would be encrypted with a PSK shared between JN and JCE? Obviously, in this case JCE would need to generate the session resumption state before a session has been even established but I believe this would greatly speed up the join process.

Regards,
Mališa Vučinić

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 May 2015 12:43:24 -0400

Mališa Vučinić <[email-masked]> wrote:
    mcr> A power and compute-saving thing for the JCE to do would be to
    mcr> have the
    mcr> JN provide the JCE with a session-resumption ticket... and for the
    mcr> JCE
    mcr> to pass that onto the PCE.

    > This seems like a great idea for nodes that may often loose
    > connectivity and would need to re-run the join process. For instance,
    > we work with energy-harvesting nodes with very small batteries (20
    > mAh) and repeating the whole thing once some energy becomes available
    > is simply out of the question.

I think that you mis-understand the purpose of the join process.
It's not about joining the DODAG or the network, it's about joining the
local security domain.  The energy harvesting node would run the join
process once, and would then get provisioned with a number of things.
Specifically:
     1) a locally relevant certificate and/or MSK (from the JCE)
     2) a set of paths and timeslots (from the PCE)
     3) some application specific set of things (e.g. a light switch
        is told which light bulbs to control, or perhaps which multicast
        groups to use to announce the switch changes if bulbs listen to
        switches ...)

Certainly, if you need security for 3, one could use a a TLS
session-resumption ticket for that state.

But, there is no reason for this node to rerun the join process.
As Tero has pointed out, the node might need to stay awake long enough to
hear the ASN from the EB if it hasn't got a good clock.

I wonder how we can make this seperation of responsibility clearer.
If you understand what I'm saying, perhaps you can tell me how to avoid
this misunderstanding in the future?

    > Since the format of a stateless session ticket from RFC 5077 does not
    > affect interoperability, in the context of 6TiSCH we would need to
    > mandate the session resumption support on the JCE side. However, could
    > it be possible to use a 6TiSCH-specific format of this ticket for the
    > initial join as well, where the session state would be encrypted with
    > a PSK shared between JN and JCE? Obviously, in this case JCE would
    > need to generate the session resumption state before a session has
    > been even established but I believe this would greatly speed up the
    > join process.

So, here, I think you are imagining using some kind of pre-provisioned
session-resumption ticket to replace the initial TLS handshake.
I think that this is something that one could imagine: the initial TLS
handshake is done at the factory, and then, based upon a bearer token,
the factories' MASAS (see draft-pritikin-anima-bootstrapping-keyinfra-01)
might return that.
Is this what you are thinking about?

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 15 May 2015 18:19:24 -0700

Was: [6tisch] questions about draft-richardson-security-6top

> On 13 May 2015, at 09:43, Michael Richardson <[email-masked]> wrote:
> 
>      S1) a locally relevant certificate and/or MSK (from the JCE)
>      S2) a set of paths and timeslots (from the PCE)
>      S3) some application specific set of things (e.g. a light switch
>        switches …)

Yes, I was definitely considering ‘joining the network’ as part of the join process. But how is provisioning S2 and S3 different from joining the network? One can consider that the local security domain has been joined by a node once S1 has been provisioned, no? And provisioning S2 and S3 is then something which we should not consider part of the join process?

> session-resumption ticket for that state.

My remark on the applicability of session-resumption for energy-harvested nodes was related to the problem that the end-to-end session state with JCE is not preserved if the energy-harvested node runs out of energy during for instance 12 hours of dark, as RAM may not be retained. Do you think writing TLS state to flash would be a good solution? I have doubts on this as: a) if node is off during those 12 hours, JCE’s heartbeat will recognize this and may terminate the session locally; b) I may not want to write to flash every time keys change, as flash operations are very expensive.

> hear the ASN from the EB if it hasn't got a good clock.

If everything is written in flash, I agree. The problem then remains if a node was off long enough that schedule/keys change. What mechanism does it use to recognize it has outdated information?

> this misunderstanding in the future?

I am not yet clear if you consider L2 keys to be the output of the join process? To me, ‘joining local security domain' ends once S1 has been provisioned as it is a permanent credential from which various temporary keys can be derived. However, one can also simply use JCE to provision L2 keys, without local key derivation from MSK or certificate.

In that sense, I see two phases here:

Phase 1 whose output is a JN <-> JCE session and optionally MSK/locally significant certificate. Strictly, I think this is where one can consider that the JN has joined the local security domain. 

Phase 2 whose output are L2 keys, from JCE or locally derived.

Does that make sense?