{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. Göran Selander <goran.selan...@ericsson.com> wrote: > * 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 -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
