Subject: Re: [Ace] Call for presentations for IETF98

From: Göran Selander <[email-masked]>
Date: Fri, 17 Mar 2017 05:42:38 +0000

Hi ACE chairs and all,

Here are some proposed agenda items for ACE:

* ACE profiles.

A number of drafts have been submitted as profiles of the ACE framework. The drafts vary somewhat in scope and in degree of detail what they specify. Some functionality is overlapping between the drafts. Some functionality described in one ACE profile is applicable to all profiles and may either be copied over or included in the framework.

Time: 20 minutes
Objective: Ask for the WG's view on coordinating content in the ACE profiles. Are the requirements on profiles described in the ACE framework sufficient? (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-06#appendix-C)

* EDHOC

https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05

Following the last round of reviews we have updated this application layer key exchange protocol which is used e.g. in the OSCOAP profile of ACE and in the 6TiSCH minimal security framework. We think this is now ready to move forward.

Time: 15 min
Objective: Call for adoption

* EALS

https://www.ietf.org/internet-drafts/draft-selander-ace-eals-00.txt

This is a strawman on certificate enrolment using the new IoT application layer security protocols. If certificate enrolment for IoT devices is on the agenda then we would like to present this.

Time: 10 min
Objective: Ask for review

Göran

From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Kepeng Li <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 15 March 2017 at 05:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] Call for presentations for IETF98

Hi everyone,

So far, the chairs have had two requests for presentations at the ACE meeting of IETF98, which we will be accommodating along with discussion on the current draft progress.

We’re putting the agenda together now, and we would like to know if anyone else has a topic that they’d like to present and discuss at the upcoming face to face.

Please send feedback to Hannes and me before the end of 17th Mar, including draft name, presenter, how much time, objectives.

Thanks.

Kepeng & Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Mar 2017 17:57:46 -0400

{I left Göran's links at the bottom. Please excuse the length: I didn't have
time to make it shorter}

The documents https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/
and https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-secure-join/
are in the process of being hybridized.

Some background:

There are two of them because there is some concern that a full zero-touch
bootstrap will require too many round trips. In the smallest networks a
completely manual bootstrap is acceptable to some.

In the biggest industrial networks, nothing less than a full asymmetric key
bootstrap is acceptable.  This is often due to human factors as well well
(installers not trusted with symmetric keys!).  In between are some networks
where managing a large number of (hopefully unique!) symmetric join keys
that have to be provisioned at the factory is acceptable.  This is how
pre-6tisch 802.15.4 networks are being deployed today.

We are doing this work in 6tisch because we can pin down a number of
variables that would otherwise cause significant scope creep:
  1) we assume a clueful network operator (or contractor) who can sanely
     operate our Join Registrar/Coordinator [which is in the zero-touch case,
     is a CA].
      ---> this means our solution does not scale to residential or small
           office situations, and that is acceptable to us.

  2) we have some pretty low constraints on network bandwidth available, but
     we also have ways to partition available bandwidth so that we can limit
     the impact of DoS attacks.

  3) we are very much starved for broadcast slots (one opportunity every few
     minutes is not unusual).  So we do want to pack all our discovery into
     a single broadcast packet.  Said discovery packet can be authenticated, but needs
     to be unencrypted for a number reasons.

  4) we use RPL as the routing protocol across a mesh, which forms one (or
     more) tree-like DAGs.  Close to the root there are significant bandwidth
     constraints, and the convergence of traffic there can cause congestion.
     If properly provisioned, upper-mesh nodes may not suffer as much from
     energy, it can really hurt nodes further down the tree if they transmit
     packets upwards, only to have them dropped due to congestion, and then
     are forced to carry useless retransmits.
     As such, we are looking for solutions that where can coordinate the
     join process centrally, and we can accomodate innovation at the edges
     in the form of DoS defenses.

  5) because the is radios, there is no inherent "this is the right network,
     because the operator plugged you", which comes with most wired networks.
     There also isn't a user to pick the right ESSID.

Many of these requirements do not apply to many in-home devices that can
expect to operate over high-bandwidth wifi, with mains power or easily
recharged batteries.

REUSE
=====

One of the major goals of the 6tisch-security design team is invent as little
as possible!   In particular, code and libraries that would be present for
bootstrap and be unused during the application usage are to avoided! Code
space is precious, but more precious is developers paying attention to
quality of implementation issues in the core.

So we are trying to reuse as much of the ACE "platform" as we can:

a) CoAP is the base.

b) CoAP block transfer where we need bigger blocks.

c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt
   interfaces.

d) EDHOC can provide for our initial keying process.  With symmetric
   per-pledge one-touch keys, this is very frugle for number of bytes
   transfered.
   Asymmetric keys use zero-touch IDevID certificates, and ownership
   vouchers which are in common with the work in ANIMA and NETCONF.

e) we think that our enrollment protocol is ideally suited to
   make the introductions between RS<->RO, and C<->RqP that ACE
   needs for bootstraping it's trust model.
   It might be that the OSCOAP connection created *is* the trust
   session keys, or could be that another connection is leveraged from
   that trust relationship.

   In particular, we want rekeying the 6tisch L2 network keys to be just
   "yet another" mgmt process that occurs between our network management
   elements and groups of nodes.

ADOPTING DOCUMENTS
==================

We (6tisch) need EDHOC, and either EALS or something like it as our
equivalent to EST.   We need them adopted and progressed.
Working on them ourselves is not in our charter.

I'm personally not sure that EDHOC and EALS belong in ACE.
It could be that they really belonged in COSE, but that WG has been
concluded.

Given that, I don't see another place for them other than ACE, but I am
concerned that it may be too distracting to other work in ACE.

    > Following the last round of reviews we have updated this application
    > layer key exchange protocol which is used e.g. in the OSCOAP profile of
    > ACE and in the 6TiSCH minimal security framework. We think this is now
    > ready to move forward.

    > Time: 15 min Objective: Call for adoption

    > This is a strawman on certificate enrolment using the new IoT
    > application layer security protocols. If certificate enrolment for IoT
    > devices is on the agenda then we would like to present this.

    > Time: 10 min Objective: Ask for review

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

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 21 Mar 2017 13:45:38 +0100

+1 on adopting the EDHOC work in ACE. 

To add to Michael’s summary, I would also like to stress that in draft-ietf-6tisch-minimal-security the one-hop neighbor of a pledge (joining node) plays the role of an untrusted CoAP proxy in order to facilitate pledge’s communication with the Registrar. Facilitating key agreement in such a setting, i.e. through the proxy, is necessary and is another reason why we use EDHOC.

Mališa

> On 20 Mar 2017, at 22:57, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: peter van der Stok <[email-masked]>
Date: Wed, 22 Mar 2017 11:28:47 +0100

Hi Michael,

thanks for this extended explanation. This really helps to understand 
the final goals and motivation.
A few questions below to remove my remaining confusion.

> completely manual bootstrap is acceptable to some.

I need some more explanation here.
It will help if there are some numbers comparing the two approaches.
And is "completely manual" identical to "one touch"?
Or do you see gradations from completely manual to fully automatic?

> pre-6tisch 802.15.4 networks are being deployed today.

The above applies to 6tisch networks only?

>            office situations, and that is acceptable to us.

That is a very large logical step for me; small offices and residential 
are small networks in my view.
And small networks do not accept zero touch? Probably, I misunderstand 
the reasoning.

>      in the form of DoS defenses.

Coordinate meaning a central control algorithm?
The RPL bandwidth constraints at the root is a general problem. Can this 
not be separated out?

> So we are trying to reuse as much of the ACE "platform" as we can:

I completely approve, this should also apply to other than 6tisch 
networks
> c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt

interesting thought; Make re-keying a management issue.

>    needs for bootstraping it's trust model.

RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and Registrar?

Looking forward to the presentations,

Peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Mar 2017 09:31:43 -0400

peter van der Stok <[email-masked]> wrote:
    >> There are two of them because there is some concern that a full
    >> zero-touch bootstrap will require too many round trips. In the
    >> smallest networks a completely manual bootstrap is acceptable to some.

    > I need some more explanation here.  It will help if there are some
    > numbers comparing the two approaches.  And is "completely manual"
    > identical to "one touch"?  Or do you see gradations from completely
    > manual to fully automatic?

"completely manual" means: attach JTAG to device, write K1 key in.
Or, "burn keys into source code", deploy.  If one was using one of the
testbeds, that might be rather easy.

    >> In the biggest industrial networks, nothing less than a full
    >> asymmetric key bootstrap is acceptable.  This is often due to human
    >> factors as well well (installers not trusted with symmetric keys!).
    >> In between are some networks where managing a large number of
    >> (hopefully unique!) symmetric join keys that have to be provisioned at
    >> the factory is acceptable.  This is how pre-6tisch 802.15.4 networks
    >> are being deployed today.

    > The above applies to 6tisch networks only?

I'm not claiming that the constraints and opportunities that are specific to
6tisch networks are unique to 802.15.4 TSCH in Industrial settings.  I'm
rather saying that these are the constraints that allow us to make progress
without unweidly scope creep.

    >> variables that would otherwise cause significant scope creep: 1) we
    >> assume a clueful network operator (or contractor) who can sanely
    >> operate our Join Registrar/Coordinator [which is in the zero-touch
    >> case, is a CA].

    > are small networks in my view.  And small networks do not accept zero
    > touch? Probably, I misunderstand the reasoning.

Such networks do not at present, by default, have clueful operators to run
the JRC.  If a JRC can be assumed (homenet...), if it can be packaged up to
be trivial, or if an upstream ISP or service provider can provide it, then
progress could be made. That's a lot of IFs however, and it can hide a lot of
ratholes.

    >> 4) we use RPL as the routing protocol across a mesh, which forms one
    >> (or more) tree-like DAGs.  Close to the root there are significant
    >> bandwidth constraints, and the convergence of traffic there can cause
    >> congestion.  If properly provisioned, upper-mesh nodes may not suffer
    >> as much from energy, it can really hurt nodes further down the tree if
    >> they transmit packets upwards, only to have them dropped due to
    >> congestion, and then are forced to carry useless retransmits.  As
    >> such, we are looking for solutions that where can coordinate the join
    >> process centrally, and we can accomodate innovation at the edges in
    >> the form of DoS defenses.

    > Coordinate meaning a central control algorithm?  The RPL bandwidth
    > constraints at the root is a general problem. Can this not be separated
    > out?

Once the network is constructed there are a number of observations.
1) if the network is for control (such lighting), P2PRPL might provide for
   completely different paths which are not so contrained.
2) RPL DAO projection could remove traffic away from the root.

3) a data collector (in the P2MP metering scenarios) can also do management
   of bandwidth

4) 6tisch includes mechanisms to allocate bandwidth for different
   applications via the 6p mechanisms, so bandwidth can be reserved
   and latency can be made deterministic.

5) 6tisch envisions (but is not yet chartered) to deal with a PCE,
   [such as is used in ISA100, I'm told] that could plan tracks
   across the mesh in a centralized way.

The point is that we can't spend very much of the available bandwidth for
join traffic, it would be wasteful and would make the impact of DoS attacks
higher.

    >> e) we think that our enrollment protocol is ideally suited to make the
    >> introductions between RS<->RO, and C<->RqP that ACE needs for
    >> bootstraping it's trust model.

    > Looking forward to the presentations,

I haven't asked for time at ACE about the join process.
I think this is a simple application of OSCOAP to generate a new set of keys.
This is a partly open OSCOAP issue.  I'd also like to generate keys for the
CoMI (rekey) interface.