+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 protected]> wrote: > > > {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 <[email protected]> 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
