Reviewer: Toerless Eckert Document: draft-nichols-iotops-defined-trust-transport-01 This is a partial review of the document. I was officially asked to do IoTdir review but could not guarantee i would have the time, so i did not respond and i was ultimately not assigned to do it. I did find a bit of time to go through parts of the document today because i was very interested in it. I very much like the overall technology and think it is useful far beyond the scoped goals of OT, such as an infrastructure for ASA in ANIMA. Likewise it may have issues in some OT areas i can think ot - so it is overall a great technology to experiment with. I have actually no good experience with the requirements against an individual submission RFC, just trying to likely submit the first work of my own to that track. So it is not clear to me what reasonable expectations against the text are. I did stumble across a lot of nits i'd suggest to be resolved in IETF track documents, but not clear about the right level of expectation here. Overall, this document is very dense, and if i may be cynical - a lot of research papers are often so dense, primarily also because of page limits in research publications, and i think it leads to little educational value of many research papers. To document the work done so far for DefT in this to-be-RFC to few experts who will understand how these components of quite a complex system do work together i think this text is on the right path. Also i think in a lot of the discussions of future options (which i didn't review in detail). If on the other hand, the content is meant to be put into RFC format to further proliferate the ideas to a broader, less-expert audience of desired adopters, then more examples/explanatoins could be helpfull. In general, there is a bit of the operational perspective missing. E.g.: description of an example DevOps process of how to build out an application and deploy/secure it in the network with DefT vs. without it (best case, not assuming worst case manual configured ACLs ;-)). Given how research papers have all type of more or less useful author-hazing with all their formatting requirements i would like to mention that i would see benefit in ASCII pictures for the graphics. None of them seem to be too difficult to build, and its still the RFC reference format. There are by now also nice tools to automatically create nicer graphics automatically from ASCII-art which many newer RFCs already use. Overall: Thanks a lot for this work, and hope we can see this in time as an RFC. And if you're interested to present at ANIMA and maybe discuss there as well, feel free to ask for a slot. Cheers Toerless I felt the text overall is in many parts more of a research paper, expecting knowledge/references to a large number of research papers. Which could be fine. I don't 2 Network Working Group K. Nichols 3 Internet-Draft Pollere LLC 4 Intended status: Informational V. Jacobson 5 Expires: 4 October 2023 UCLA 6 R. King 7 Operant Networks Inc. 8 2 April 2023 10 Defined-Trust Transport (DeftT) Protocol for Limited Domains 11 draft-nichols-iotops-defined-trust-transport-01 13 Abstract 15 This document describes a broadcast-friendly, many-to-many Defined- 16 trust Transport (DeftT) that makes it simple to express and enforce Nit: Use of DefT term before defining it. 17 application and deployment specific integrity, authentication, access 18 control and behavior constraints directly in the protocol stack. 19 DeftT is part of a Defined-trust Communications framework with an 20 example codebase, not a protocol specification. Combined with IPv6 21 multicast and modern hardware-based methods for securing keys and 22 code, it provides an easy to use foundation for secure and efficient 23 communications in Limited Domains (RFC8799), in particular for 24 Operational Technology (OT) networks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 4 October 2023. 43 Copyright Notice 45 Copyright (c) 2023 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Environment and use . . . . . . . . . . . . . . . . . . . 4 61 1.2. Transporting information . . . . . . . . . . . . . . . . 5 62 1.3. Securing information . . . . . . . . . . . . . . . . . . 7 63 1.4. Defined-trust Communications Domains . . . . . . . . . . 8 64 1.5. Current status . . . . . . . . . . . . . . . . . . . . . 9 65 2. DeftT and Defined-trust Communications . . . . . . . . . . . 10 66 2.1. Inside DeftT . . . . . . . . . . . . . . . . . . . . . . 11 67 2.2. syncps: a set reconciliation protocol . . . . . . . . . . 12 68 2.3. Formats of DeftT Communications . . . . . . . . . . . . . 13 69 2.3.1. Publications . . . . . . . . . . . . . . . . . . . . 13 70 2.3.2. Certificates . . . . . . . . . . . . . . . . . . . . 15 71 2.3.3. cState . . . . . . . . . . . . . . . . . . . . . . . 15 72 2.3.4. cAdd . . . . . . . . . . . . . . . . . . . . . . . . 16 73 2.4. Interface between application and network interface . . . 17 74 2.5. Schema-based information movement . . . . . . . . . . . . 19 75 2.6. Congestion control . . . . . . . . . . . . . . . . . . . 21 76 3. Defined-trust management engine . . . . . . . . . . . . . . . 22 77 3.1. Communications schemas . . . . . . . . . . . . . . . . . 22 78 3.2. A schema language . . . . . . . . . . . . . . . . . . . . 23 79 4. Certificates and identity bundles . . . . . . . . . . . . . . 26 80 4.1. Obviate CA usage . . . . . . . . . . . . . . . . . . . . 27 81 4.2. Identity bundles . . . . . . . . . . . . . . . . . . . . 28 82 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 30 83 5.1. Secure Industrial IoT . . . . . . . . . . . . . . . . . . 30 84 5.2. Secure access to Distributed Energy Resources (DER) . . . 31 85 6. Using Defined-trust Communications without DeftT . . . . . . 33 86 7. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 38 90 11. Informative References . . . . . . . . . . . . . . . . . . . 38 91 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 94 1. Introduction 96 Decades of success in providing IP connectivity over any physical 97 media ("IP over everything") has commoditized IP-based 98 communications. This makes IP an attractive option for Internet of 99 Things (IoT), Industrial Control Systems (ICS) and Operational 100 Technologies (OT) applications like building automation, embedded 101 systems and transportation control, that previously required 102 proprietary or analog connectivity. For the energy sector in Nit: One or more references for OT networking technologies would be useful here. 103 particular, the growing use of Distributed Energy Resources (DER) 104 like residential solar has created interest in low cost commodity 105 networked devices but with added features for security, robustness 106 and low-power operation [MODOT][OPR][CIDS]. Other emerging uses 107 include connecting controls and sensors in nuclear power plants and 108 carbon capture monitoring [DIGN][IIOT]. Nit: Move [DIGN] after nuclear plant to keep references local to what they refer to. 110 While moving to an IP network layer is a major advance for OT, 111 current Internet transport options are a poor match to its needs. 112 TCP generalized the Arpanet transport notion of a packet "phone call" 113 between two endpoints into a generic, reliable, bi-directional 114 bytestream working over IP's stateless unidirectional best-effort 115 delivery model. Just as the voice phone call model spawned a global 116 voice communications infrastructure in the 1900s, TCP/IP's two-party 117 packet sessions are the foundation of today's global data 118 communication infrastructure. But "good for global communication" 119 isn't the same as "good for everything". OT applications tend to be 120 localized and communication-intensive with a primary function of 121 coordination and control and communication patterns that are many-to- 122 many. Implementing many-to-many applications over two-party 123 transport sessions changes the configuration burden and traffic 124 scaling from the native media's O(_n_) to O(_n_^2) (see Section 1.2). 125 Further, as OT devices have specific, highly prescribed roles with 126 strict constraints on "who can say what to which", the opacity of 127 modern encrypted two-party sessions can make it impossible to enforce 128 or audit these constraints. Nit: paragraph too long. Split. Major: 125-128: An end-to-end security pundit would say that you can not trust the network for role-based access control, but that you need to embody that in appropriate keying/credentials on the communicating systems. Aka: I think you need to make a stronger explanatory argument for the network being some form of trusted party to be responsible for at least part of communications policies. But its not even clear to me from the following text whether you really want that. So i wonder if this text is a redundant complaint. 130 This memo describes a new transport protocol, Defined-trust Transport 131 (DeftT) for Limited Domains [RFC8799] in which multipoint 132 communications are enabled through use of a named collection 133 abstraction and secured by an integrated trust management engine. 134 DeftT employs multicast (e.g., IPv6 link-local [RFC4291]), a 135 distributed set reconciliation PDU transport, a flexible pub/sub API, 136 chain-of-trust membership identities, and secured rules that define 137 the local context and communication constraints of a deployment in a 138 declarative language. These rules are used by DeftT's runtime trust 139 management engine to enforce adherence to the constraints. The 140 resulting system is efficient, secure and scalable: communication, 141 signing and validation costs are constant per-publication, 142 independent of the richness and complexity of the deployment's 143 constraints or the number of entites deployed. Like QUIC, DeftT is a 144 user-space transport protocol that sits between an application and a 145 system-provided transport like UDP or UDP multicast (see Figure 1). 147 (Artwork only available as svg: figs/defttlayer-rfc.svg) 149 Figure 1: DeftT's place in an IP stack 151 Device enrollment consists of configuring a device with _identity 152 bundles_ that contains the trust anchor certificate, a compact and 153 secured copy of the communication rules, and a membership identity 154 (for domain communications) which comprises all the certs in its 155 signing chain (which can be used to confer attributes) terminated at 156 the trust anchor. The secret key corresponding to the leaf nit: If this secret key is meant to be the private key of a public key pair, then please write private key. Else it may be useful to elaborate what your other form of secret key tied to a certificate you are thinking of. 157 certificate of the identity should be securely configured while the 158 security of the identity bundle can be deployment-specific. The nit: also not clear to me what security you are referring to. Maybe include a short example. 159 identity chains of all communicating members share a common trust 160 anchor and the rules that define legal signing chains, so the bundle minor: Not sure if the constraint to a single trust anchor does not limit the solution in case of mergers, aquisitions, legal oversight entities and other cases. I went through some rework in rfc8994 to use "common set of trust anchor(s)" or the like to be flexible enough. nit: legal as in "permitted by DefT", or by some other (legal) entity (deployment environment/country/.. rules ?). Prefer not to use the term legal unless it's the latter. 161 suffices for a member to authenticate and authorize communication 162 from peers and vice-versa. New members can join and communicate 163 without labor intensive and error-prone device-to-device association 164 configuration. minor: Are you addressing revocation procedures ? 166 1.1. Environment and use 168 Due to physical deployment constraints and the high cost of wiring, 169 OT networks preferentially use radio as their communication medium. 170 Use of wires is impossible in many installations (untethered Things, 171 adding connected devices to home and infrastructure networks, 172 vehicular uses, etc.). Wiring costs far exceed the cost of current 173 System-on-Chip Wi-Fi IoT devices and the cost differential is 174 increasing [WSEN][COST]. For example, the popular ESP32 is a 175 32bit/320KB SRAM RISC with 60 analog and digital I/O channels plus 176 complete 802.11b/g/n and bluetooth radios on a 5mm die that consumes 177 70uW in normal operation. It currently costs $0.13 in small 178 quantities while the estimated cost of pulling cable to retrofit 179 nuclear power plants is presently $2000/ft [NPPI]. major: I think this whole paragraph is way too broadly one-sides in favor of radio technologies. Radio connectivity has a lot of downsides, especially in the face of machinery that introduces frequency disturbances ("motors", "microwaves",...) such as in industrial environments, transportation. And your example does not include the OPEX for powering the device, such as swapping of battery, or worse yet, swapping the device because of non-replaceable batteries. What you describe is just one side of a larger coin. The other side of the coin is that if you are using wires to power devices, then those wires can and will also provide networking. There is a whole area of work evolving for 2-wire ethernet for example to do exactly that. Not to speak of all the places where PoE already is successful, including in OT. 181 OT applications are frequently Limited Domain with communications nit: i am actually not a fan of "limited domain", but would have preferred if we would have sticked to the prior established "controlled domains", "controlled networks" or the like. For example, a country wide trackside OT network could (and does) span tenths of thousands of miles. What again is "limited" here ? Aka: I would prefer to not see a proliferation of "limited" because it does introduce incorrect associations. 182 that are local, have a many-to-many pattern, and use application- 183 specific identifiers ("topics") for rendezvous. This fits the nit: arguably, DNS and even more so DNS-SD are also application specific identifiers, so i have a hard time considering that to be a significant distinguisher for controlled networks vs. the Internet. The maybe more fitting broader classification of controlled network is that the application owner has a larger say about the functionalities in the network than this is the case for the public Internet, aka: stronger vertical integration. 184 generic Publish/Subscribe communications model ("pub/sub") and, as 185 table 1 in [PRAG] shows, nine of the eleven most widely used IoT 186 protocols use a topic-based pub/sub transport. For example MQTT, an 187 open standard developed in 1999 to monitor oil pipelines over 188 satellite [MQTT][MHST], is now likely the most widely used IoT 189 protocol (https://mqtt.org/use-cases/ (https://mqtt.org/use-cases/)). nit: What is an "IoT protocol" ? maybe "protocol primary developed for IoT" ? (is IP an IoT protocol ? 191 Microsoft Azure, Amazon AWS, Google Cloud, and Cloudflare all offer 192 hosted MQTT brokers for collecting and connecting sensor and control 193 data in addition to providing local pub/sub in buildings, factories 194 and homes. Pub/sub protocols communicate by using the same topic but 195 need no knowledge of one another. These protocols are typically nit: reshuffle. Move Pub/sub explanation here into 186, follow with MQTTT example, finish with big cloud player list ? 196 _implemented_ as an application layer protocol over a two-party 197 Internet transports like TCP or TLS which require in-advance 198 configuration of peer addresses and credentials at each endpoint and 199 incur unnecessary communications overhead Section 1.2. nit: maybe "are today typically". One may remember that the most successful bus protocols in IP land such as TIBCO bus where originally using IP Multicast ASM, and only evolved away from that because (censured #$%%$^$^ complaints about router vendors). But likewise there is ICN/CCN, which i think would be worth to mention at least. 201 1.2. Transporting information 203 The smart lighting example of Figure 2 illustrates a topic-based pub/ 204 sub application layer protocol in a wireless broadcast subnet. Each 205 switch is set up to do triple-duty: one click of its on/off paddle 206 controls some particular light(s), two clicks control all the lights 207 in the room, and three clicks control all available lights (five 208 kitchen plus the four den ceiling). Thus a switch button push may 209 require a message to as many as nine light devices. On a broadcast 210 physical network each packet sent by the switch is heard by all nine 211 devices. IPv6 link-level multicast provides a network layer that can nit: "broadcast physical network" - probably better to say "broadcast transmission medium". But there also seems to be some lead-in missing, such that those replicated unicast messages are highly undesiragle for e.g.: energy consumption purposes. Which then goes back to why not use a broker, which is what most IoT systems do these days (and most don't understand its downside), aka: you're skipping over steps that people new to the matter may not easily be able to follow 212 take advantage of this but current IP transport protocols cannot. nit: RFC3208, RFC5740 ? We had a whole IETF WG on reliable multicast transport protocols, so there should be some explanation of what new work is needed here. 213 Instead, each switch needs to establish nine bi-lateral transport nit: light-switch 214 associations in order to send the published message for all lights to 215 turn on. Communicating devices must be configured with each other's 216 IP address and enrolled identity so, for _n_ devices, both the 217 configuration burden and traffic scale as O(_n^2_). For example, nit: s/as/is/ 218 when an "_all_" event is triggered, every light's radio will receive 219 nine messages but discard the eight determined to be "not mine." If 220 a device sleeps, is out-of-range, or has partial connectivity, 221 additional application-level mechanisms have to be implemented to 222 accommodate it. major: The additional complexity for reliability would not be lower with multicast/broadcast. Most people involved in the RMT process would rather claim that it is quite complex and likely one of the reasons for little adoption of RMT protocols. Aka: as much as i dislike the argument, most people would say unicasting makes reliability (retransmissions) easier! As proof i could try to find all the docs we had to mention how the industry transmits multicast over WiFi: by converting it to unicast. nit: given how you're only starting to explain broker next, maybe reshuffle the lager text to unicast -> broker -> multicast. Otherwise it seems you're sprinkling multicast without explaining it well.. 224 (Artwork only available as svg: figs/iotDeftt-rfc.svg) 226 Figure 2: Smart lighting use of Pub/Sub 228 MQTT and other broker-based pub/sub approaches mitigate this by 229 adding a _broker_ where all transport connections terminate 230 (Figure 3). Each entity makes a single TCP transport connection with 231 the broker and tells the broker the topics to which it subscribes. 232 Thus the kitchen switch uses its single transport session to publish 233 commands to topic kitchen/counter, topic kitchen or all. The kitchen 234 counter light uses its broker session to subscribe to those same 235 three topics. The kitchen ceiling lights subscribe to topics kitchen 236 ceiling, kitchen and all while den ceiling lights subscribe to topics 237 den ceiling, den and all. Use of a broker reduces the configuration 238 burden from O(_n_^2) to O(_n_): 18 transport sessions to 11 for this 239 simple example but for realistic deployments the reduction is often 240 greater. There are other advantages: besides their own IP addresses nit: paragraph too long, split here ? 241 and identities, devices only need to be configured with those of the 242 broker. Further, the broker can store messages for temporarily 243 unavailable devices and use the transport session to confirm the 244 reception of messages. This approach is popular because the pub/sub 245 application layer protocol provides an easy-to-use API and the broker 246 reduces configuration burden while maintaining secure, reliable 247 delivery and providing short-term in-network storage of messages. 248 Still the broker implementation doubles the per-device configuration 249 burden by adding an entity that exists only to implement transport 250 and traffic still scales as O(_n^2_), e.g., any switch publishing to 251 all lights results in ten (unicast) message transfers over the wifi 252 network. Further, the broker introduces a single point of failure 253 into a network that is richly connected physically. nit: I'd put single point of failure as he top reason. Auto-selection/discovery/redundancy as secondary reasons (complexity). 255 (Artwork only available as svg: figs/iotMQTT-rfc.svg) 257 Figure 3: Brokers enable Pub/Sub over connection/session protocols 259 Clearly, a transport protocol able to exploit a physical network's 260 broadcast capabilities would better suit this problem. (Since minor: as much as i am a fan of multicast, one may want to understand, that this again only captures the realities of on specific type of transmission media or network setups. For example the further down we go on the MIMO trail, the more WiFi experts will tell you that multicasting is extremely energy intensive because you don't know whether a receiver is (direction) and you need to reach all of them (power level). Likewise, in mesh networks, mesh nodes also need to forward broadcast packets unnecessary, etc. pp. Unless you want to discuss any such pro/cons maybe just present the muticast approach as a valid option without judgement. 261 unicast is just multicast restricted to peer sets of size 2, a 262 multicast transport handles all unicast use cases but the converse is 263 not true.) In the distributed systems literature, communication minor: "If the transmission media or network is based on broadcsast and no further ooptimizations are possible for unicast transmission, then... (unicast is just a restriction of...)." 264 associated with coordinating shared objectives has long been modeled 265 as _distributed set reconciliation_ [WegmanC81][Demers87]. In this nit: that sounds like opening a new book here. Paragraph break on line 263 ? 266 approach, each domain of discourse is a named set, e.g., 267 _myhouse.iot_. Each event or action, e.g., a switch button press, is 268 added as a new element to the instance of _myhouse.iot_ at its point 269 of origin then the reconciliation process ensures that every instance 270 of _myhouse.iot_ has this element. In 2000, [MINSKY03] developed a 271 broadcast-capable set reconciliation algorithm whose communication 272 cost equaled the set instance _differences_ (which is optimal) but 273 its polynomial computational cost impeded adoption. In 2011, [DIFF] 274 used Invertible Bloom Lookup Tables (IBLTs) [IBLT][MPSR] to create a 275 simple distributed set reconciliation algorithm providing optimal in 276 both communication and computational cost. DeftT uses this algorithm nit: another paragraph here minor: Might be helpful to spend one or more sentences to explain the concept. Such as "more general solutions for the best communication paradigms are possible by abstracting the problem away from message exchange/propagation and distribution over to the concept of shared state and then determining the optimum communications method from those sharing targets. this is called "distributed set reconciliation". 277 (see Section 2.2) and takes advantage of IPv6's self-configuring link 278 local multicast to avoid all manual configuration and external 279 dependencies. This restores the system design to Figure 2 where each 280 device has a single, auto-configured transport that makes use of the 281 broadcast radio medium without need for a broker or multiple 282 transport associations. Each button push is broadcast exactly once 283 to be added to the distributed set. minor: some pointer / explanation to how the algorithm deals with sender or receiver loss of such a message would be be nice. 285 1.3. Securing information 287 Conventional session-based transports combine multiple publications 288 with independent topics and purposes under a single session key, 289 providing privacy by encrypting the sessions between endpoints. The nit: If pub/sub communication is carried across conventional ... Otherwise it sounds as if pub/sub is mandatory for session based transport. 290 credentials of endpoints (e.g., a website) are usually attested by a 291 third party certificate authority (CA) and bound to a DNS name; each nit: enpoints communicating across the Internet nit: add reference to WebPKI. minor: aka: binding to DNS is not common for private PKI, such as what we predominantly use in controlled networks (limited domains). Such as BRSKI, ACP or other ANIMA RFCs.. (and most non-IETF use of PKI either). 292 secure transport association requires the exchange of these 293 credentials which allows for secure exchange of a nonce symmetric 294 key. In Figure 3 each transport session is a separate security 295 association where each device needs to validate the broker's 296 credential and the broker has to validate each device's. This 297 ensures that transport associations are between two enrolled devices 298 (protecting against outsider and some MITM attacks) but, once the 299 transport session has been established there are no constraints 300 whatsoever on what devices can say. Clearly, this does not protect 301 against the insider attacks that currently plague OT, e.g., [CHPT] 302 description of a lightbulb taking over a network. For example, the 303 basic function of a light switch requires that it be allowed to tell 304 a light to turn on or off but it almost certainly shouldn't be 305 allowed to tell the light to overwrite its firmware (fwupd), even 306 though "on/off" and "fwupd" are both standard capabilities of most 307 smart light APIs. Once a TLS session is established, the transport major: I thought all better pub/sub have according policy options on the brokers. minor: You do not mention that you need to trust the broker and that the broker is also a single point of attack. 308 handles "fwupd" publications _the same way_ as "on/off" publications. 309 Such attacks can be prevented using trust management that operates 310 per-publication, using rules that enable the "fwupd" from the light 311 switch to be rejected. Combining per-publication trust decisions 312 with many-to-many communications over broadcast infrastructure 313 requires per-publication signing rather than session-based signing. major: YOU're also eliminating the trusted third-party (broker). So arguably, end-to-end signing is benficial independent of the communication method. 315 Securing each publication rather than the path it arrives on deals nit: /path/session/ 316 with a wider spectrum of threats while avoiding the quadratic session 317 state and traffic burden. In OT, valid messages conform to rigid 318 standards on syntax and semantics 319 [IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL] that can be 320 combined with site-specific requirements on identities and 321 capabilities to create a system's communication rules. These rules 322 can be employed to secure publications in a trust management system 323 such as [DLOG] where each publisher is responsible for supplying all 324 of the "who/what/where/when" information needed for each subscriber 325 to _prove_ the publication complies with system policies. minor: a simple example would help. I guess the whole point is that subscribers are pre-fed with rulea bout what exact type of messages each specific publisher is allowed to send that is relevant to be received by this subscriber and because of the end-to-end authentication of publications the subscriber can hence verify the permissibility of the publication ? If true, then this is also the type of language i would recommend. nit: not sure if "prove" is the best word re. "verify"... 327 Instead of vulnerable third-party CAs [W509], sites employ a local 328 root of trust and locally created certificates. When the minor: The reference is not specific to third party PKI downside, so the sentence is somewhat of a fake argument. You are also not making a specific point about what properties in a PKI you think you want to motivate your ask for a local CA. What would you miss if you simply deleted this sentence ? 329 communication rules are expressed in a _declarative_ language [DLOG], 330 they can be validated for consistency and completeness then converted 331 to a compact runtime form which can be authorized and secured via 332 signing with the system trust anchor. This _communication schema_ 333 can be distributed as a certificate, then validated using on-device minor: what does that mean ? Stuff the whole runtime form as new attributes into a certificate ? How large would that be ? Sounds excessive. Why not simply a signed document ? 334 trusted enclaves [TPM][HSE][ATZ] as part of the device enrollment 335 process. In DeftT's publication-based transport, the schema is used minor: any examples of trusted enclaves on ESP32 ? I have only seen those in largrer devices, hopefully not a tall order for downscaling. major: Not clear why this has to be tied to device enrolment. I am guilty of stuffing additional information into certifictes (RFC8994) to "abuse" automated enrollment, because we just do not have any other form of communications than that automated enrollment protocol (RFC8995) at the time we need it, but we had to fight long and hard for that and only got away with it, because its very little information and its directly tied to the identity of the device and will not change during the lifetime of the device. I can not see this to be true for communication policies within e.g.: a manufacturing plant, at least not when i use industry 4.0 agile manufacutring, where the policies for communications could change in the order of weeks. YOu don't want to do cert renewal just for that (IMHO). Of course, you're not targeting IETF standard, but still... 336 to both construct and validate publications, guaranteeing that _all_ 337 parts of the system _always_ conform to and enforce the same rules, 338 even as those rules evolve to meet new threats (more in Section 3.1). 339 DeftT embeds the trust management mechanism described above directly 340 in the publish and subscribe data paths as shown below: 342 (Artwork only available as svg: figs/trustElements-rfc.svg) 344 Figure 4: Trust management elements of DeftT. 346 This approach extends LangSec's [LANG] "be definite in what you 347 accept" principle by using the authenticated common ruleset for belt- 348 and-suspenders enforcement at both publication and subscription 349 functions of the transport. If an application asks the Publication nit: explain or provide reference for "belt-and-suspenders" term if you want to keep it. Both LangSec and this term seem to be unsolicited in this context. Aka: they only help to confuse readers that don't know them. Easier to explicitly explain the technical value propositions in a document like this (this is not a research paper!). 350 Builder to publish something and the schema shows it lacks 351 credentials, an error is thrown and nothing is published. mayor: The scheme does seem to trust the local application though, because does not validate on publication. I think untrusted applications are a common problem, so i would recommend to have in the publication builder also the optional validation component. If thats already implied, that should be explained. Most common reason for untrusted is unexpectedly broken. 352 Independently, the Publication Validator ignores publications that: 354 * don't have a locally validated, complete signing chain for the 355 credential that signed it 356 * the schema shows its signing chain isn't appropriate for this 357 publication 358 * have a publication signature that doesn't validate mayor: it would be good if the picture would show where the identity credentials are accessed from. I would guess that the device specific application code does NOT have the ability to sign, but that the publication builder does that. Aka: paint a cert beside the pub builder block, and the trust-anchors beside the validator for example to clarify this. 360 Note that since an application's subscriptions determine which 361 publications it wants, only certificates from chains that can sign 362 publications matching the subscriptions need to be validated or 363 retained. Thus a device's communication state burden and computation 364 costs are a function of how many different things are allowed to talk 365 to it but _not_ how many things it talks to or the total number of 366 devices in the system. In particular, event driven, publish-only 367 devices like sensors spend no time or space on validation. Unlike 368 most 'secure' systems, adding additional constraints to schemas to 369 reduce attack surface results in devices doing _less_ work. 371 1.4. Defined-trust Communications Domains 373 A Defined-trust Communications Limited Domain (or simply, _trust 374 domain_) is a Limited Domain where all the members communicate via a 375 DeftT Figure 5 and are configured with the same trust anchor, schema, 376 a schema-conformant DeftT identity cert chain that terminates at the 377 trust anchor and the secret key corresponding to the identity chain's 378 leaf cert. The particular rules for any deployment are application- nit: this is a german sentence (too long). It somehow reads as if there is a single secret key / leaf cert. "where each member" ... "and each member is configured", and a unique per member public key pair... Something like that to be precise. 379 specific (e.g., Is it home IoT or a nuclear power plant?) and site- 380 specific (specific form of credential and idiosyncrasies in rules) 381 which DeftT accommodates by being invoked with a ruleset (schema) 382 particular to a deployment. We anticipate that the efforts to create 383 common data models (e.g., [ONE]) for specific sectors will lead to 384 easier and more forms-based configuration of DeftT deployments. 386 A trust domain is perimeterless and may operate over one or more 387 subnets, sharing physical media with non-member entities. Member 388 entities throughout the domain publish and subscribe to its topics 389 using Publication Builders and Validators as shown in Figure 4. 390 These Publications become the elements of a set, or named collection, 391 that is confined to each subnet. DeftT uses a distributed set 392 reconciliation protocol on _each_ collection and _each_ subnet 393 independently. Every DeftT maintains at least two collections: 394 *pubs* for application Publications and *cert* where identity bundle 395 certs are published. Figure 5 397 (Artwork only available as svg: figs/trustdomain-rfc.svg) 399 Figure 5: Trust domain 401 Trust domains are extended across physically separated subnets, 402 subnets using different media and/or subdomains on the same subnet 403 (see Section 2.5) by using *Relays* that have a DeftT in each subnet 404 and pass Publications between subnets as long as they are valid at 405 the receiving DeftT Figure 6. Since set reconciliation does not 406 accept duplicates, Relays are powerful elements in creating efficient 407 configuration-free meshes. The subnets of the figure could be 408 different colocated media (e.g. bluetooth, wifi, ethernet) or may be 409 physically distant. The triangle Relay-only subnet can be carried 410 over a unicast link. The set reconciliation protocol ensures that 411 items only transit a subnet once: an item must be specifically 412 requested in order to be transmitted. More Relay discussion is in 413 Section 2.5 and Section 5. 415 (Artwork only available as svg: figs/relayedtrustdomain-rfc.svg) 417 Figure 6: Relayed trust domain minor: i really don't like that figure because it doesn't give any idea that publications are forwarded by relays. I would suggest to paint a picture that starts off as if it was a wired network with relays like routers connecting to multiple LANs, and then if you really insist replace the LAN symbol (line) with something dotted or cloudy or the like to express a radio subnet. 419 1.5. Current status 421 An open-source Defined-trust Communications Toolkit [DCT] with an 422 example implementation of DeftT is maintained by the corresponding 423 author's company. [DCT] has examples of using DeftT to implement 424 secure brokerless message-based pub/sub using UDP/IPv6 multicast and 425 unicast UDP/TCP and include extending a Trust Domain via a unicast nit: UDP/TCP work without IPv6 ? (just for consistency, incude IPv6 here as well IMHO, unless its IPv6 and IPv4, which would be worth to explain too). 426 connection or between two broadcast network segments. Working 427 implementations and performance improvements are occasionally added 428 to the repository. nit: use subsections here to better structure ? Above is common code, next is one specific application ? 430 Massive build out of the renewable energy sector is driving 431 connectivity needs for both monitoring and control. Author King's 432 company, Operant, is currently developing extensions of DeftT in a 433 mix of open-source and proprietary software tailored for commercial 434 deployment in support of distributed energy resources (DER). Current 435 small scale use cases have performed well and expanded usage is 436 planned. Pollere is also working on home IoT uses. Our development 437 philosophy is to start from solving useful problems with a well- 438 defined scope and extend from there. As the needs of our use cases 439 expand, the Defined-trust communications framework will evolve with 440 increased efficiencies. DeftT's code is open source, as befits any 441 communications protocol, but even more critical for one attempting to 442 offer security. DCT itself makes use of the open source 443 cryptographic library libsodium [SOD] and the project is open to 444 feedback on potential security issues as well as hearing from 445 potential collaborators. 447 The well-known issues with 802.11 multicast [RFC9119] can make DeftT 448 less efficient than it should be. Target OT deployments primarily minor: still not clear up to this point if DefT does have reliable multicasting itself in the face of packet loss (which cheap or even indstrial 802.11 APs may have) or expects 100% reliable link-local multicast... No description of retransmissions made so far. 449 use smaller packet sizes and DeftT's set reconciliation provides 450 robust delivery that currently mitigates these concerns. DeftT use 451 may become another force for improved multicast on 802.11, joining 452 the critical network infrastructure applications of neighbor 453 discovery, address resolution, DHCP, etc. minor: Uhmmm... my impression is rather that everybody workin on those multicast bits in subnet multicast rather wants to run away from using link-local multicast or reduce it's use. Not that i like that, but it makes your optimism a bit out of left field. Maybe rathre make sure your solutiopn does have the elemednts (did i mention retransmission) to work over crappy radio subnets. 455 Cryptographic signing takes most of the application-to-network time 456 in DeftT. Though not prohibitively costly, increased use of signing 457 in transports may incentivize creation of more efficient signing 458 algorithms. major: Well, this seems to be al asymmetric signing. I did start to look into thre costs of that as well. TU Hamburg did have a nice comparison of performance of various constrained node types (mostly ARM based if i remember). YOu certainly should explicitly acknowledge the cost of asymmetric signing more explicitly. Its a cost of doing future business and the faster the industry accepts that the faster it will get optimized. 460 2. DeftT and Defined-trust Communications 462 DeftT synchronizes and secures communications between enrolled 463 members of a Limited Domain [RFC8799]. DeftT's multi-party 464 synchronized collections of named, schema-conformant Publications 465 contrast with the bilateral session of TCP or QUIC where a source and 466 a destination coordinate with one another to transport 467 undifferentiated streams of information. DeftTs in a trust domain 468 may hold different subsets of the collection at any time (e.g., 469 immediately after entities add elements to the collection) but the 470 synchronization protocol ensures all converge to holding the complete 471 set of elements within a few round-trip-times following the changes. 473 Applications use DeftT to add to and access from a collection of 474 Publications. DeftT enforces "who can say what to which" as well as 475 providing required integrity, authenticity and confidentiality. 476 Transparently to applications, a DeftT both constructs and validates 477 all Publications against its schema's formal, validated rules. The 478 compiled binary communications schema is distributed as a trust-root- 479 signed certificate and that certificate's thumbprint (see 480 Section 2.3.2 and Section 7) _uniquely_ identifies each trust domain. nit: Seems like a lot of informal repetition of text from the introduction section. Would suggest to go through all the section 2 and delete duplications/repetitions, unless there is a good reason not to. 481 Each DeftT is configured with the trust anchor used in the domain, 482 the schema cert, and its own credentials for membership in the 483 domain. To communicate, DeftTs must be in the same domain. Identity nit: you didn't really define what you mean with "domain". Should also be DefT domain, and be defined as the collection of nodes with transitive connectivity that share the same (set of) trust anchors and certificates signed by them. We've done this all quite formally for RFC8994 (ACP domain etc..). 484 credentials comprise a unique private identity key along with a 485 public certificate chain rooted at the domain's trust anchor. 486 Certificates in identity chains are specified in the schema and nit: not clear what line 486 says. Rephrase or give example 487 contain the attributes granted to the identity. Thus, attributes are 488 stored in the identity *not* on an external server. nit: add (forward ?) reference to attributes. 490 Each member publishes its credentials to the certificate collection 491 in order to join the domain. DeftT validates credentials as a nit: point to definition of "(certificate) collection" in your spec. minor: Sounds interesting to illustrate the flow of messages when a particular member1 first receives a publication to a topic it is interested in that is published from a member2 that member1 does not have the certificate for. Seems as if member1 would then first need to subdscribe to the member2 certificate publication and could only afterwards continue to validate the other publication from member2. But then following on there likely is some form of caching of the publication ? Is there spec as to how a memory limited subscriber does that ? 492 certificate chain against the schema and does not accept Publications 493 without a fully validated signer. This unique approach enables fully 494 distributed policy enforcement without a secured-perimeter physical 495 network and/or extensive per-device configuration. DeftT can share 496 an IP network with non-DeftT traffic as well as DeftT traffic of a 497 different omain. Privacy via AEAD encryption is automatically nit: more benefit explanations, partially repeated from intro. Not spec text. nit: AEAD expand on first use, maybe terminology section and/or reference. 498 handled within DeftT if selected in the schema. 500 (Artwork only available as svg: figs/transportBD0v2-rfc.svg) 502 Figure 7: DeftT's interaction in a network stack 504 Figure 7 shows the data flow in and out of a DeftT. DeftT uses its 505 schema to package application information into Publications that are 506 added to its local view of the collection. Application information 507 is packaged in Publications which are carried in cAdd PDUs that are 508 used along with cState PDUs to communicate about and synchronize 509 Collections. cStates are used to report the state of the local 510 collection; cAdds carry Publications to other members that need them. 511 These PDUs are broadcast on their subnet (e.g., UDP multicast). minor: Seems more like an example than part of a spec. Maybe move into introduction. 513 2.1. Inside DeftT 515 DeftT's reference implementation [DCT] is organized in functional 516 library modules that interact to prepare application-level nit: what is "functional library module" ? Remove functional ? 517 information for transport and to extract application-level 518 information from packets, see Figure 8. Extensions and alternate 519 module implementations are possible but the functionality and 520 interfaces must be preserved. Internals of DeftT are completely 521 transparent to an application and the reference implementation is 522 efficient in both lines of code and performance. The schema nit: any metric/examples to support efficiency claims ? 523 determines which modules are used. A DeftT participates in two 524 required collections and _may_ participate in others if required by 525 the schema-designated signature managers. One of the required nit: introduction of term signature managers without explanation or forward reference. 526 collections, descriptive collection name component *pubs*, contains 527 application Publications (see Table 2). The other required 528 collection, *cert*, manages the certificates of the trust domain. 529 Specific signature managers _may_ require group key distribution in 530 descriptively named collection *keys*. nit: reference to unkown/unexplained term group keys without explanation or forward reference. 532 (Artwork only available as svg: figs/DeftTmodules-rfc.svg) 534 Figure 8: Run-time library modules 536 A _shim_ serves as the translator between application semantics and 537 the named information objects (Publications) whose format is defined 538 by the schema. The *syncps* module is the set reconciliation 539 protocol used by DeftT (see Section 2.2). New signature managers, 540 distributors, and face modules may be added to the library to extend 541 features. More detail on each module can be found at [DCT] in both 542 code files and documents. nit: distributor and face referenced without explanation or forward reference in the document. Simply referring to a big external document [DCT] is not a good style when one wants to understand the core modules of DefT. Can't be that difficult to start out with a list of modules referred to by this cdocument, each with a short paragraph/synopsis of function and forward references as necessary. 544 The signing and validation modules (_signature managers_) are used 545 for both Publications and cAdds. Following good security practice, 546 DeftT's Publications are constructed and signed _early_ in their 547 creation, then are validated (or discarded) early in the reception 548 process.The _schemaLib_ module provides certificate store access 549 throughout DeftT along with access to _distributors_ of group keys, 550 Publication building and structural validation, and other functions 551 of the trust management engine. This organization of interacting 552 modules is not possible in a strictly layered implementation. nit: Not clear what the purpose is of the last sentence. I like good rants about non-working archteictures, but who would want to consider DefT modules to be part of different layers, and if so which modules into which layer ? Unless you want to elaborate to bring that point home, maybe just delete sentence. 554 2.2. syncps: a set reconciliation protocol 556 DeftT requires a method or protocol that keeps collections 557 synchronized, where the collection a set and the Publications are the nit: where collections are set of Publications ? nit: Think of some logic for capitalization. Why are Publications capitalized but collections not ? 558 elements of the set. The *syncps* protocol uses IBLTs 559 [DIFF][IBLT][MPSR] to solve the multi-party set-difference problem 560 efficiently without the use of prior context and with communication 561 proportional to the size of the difference between the sets being 562 compared. Syncps announces its _collection state_ (set of currently 563 known Publications) by sending a cState PDU containing an IBLT. The 564 cState serves as a query for additional data that isn't reflected in 565 its local state. Receipt of a cState performs three simultaneous 566 functions: (1) announces new Publications, (2) notifies of 567 Publications that member(s) are missing and (3) acknowledges 568 Publication receipt. The first may prompt the recipient to share its 569 cState to get the new Publication(s). The second results in sending 570 a cAdd PDU containing all the missing and locally available 571 Publications that fit. The third may result in a progress 572 notification sent to other local modules so anything waiting for 573 delivery confirmation can proceed. bail: Alas i don't have the time to try to understand this protocol in detail right now, even though its vdery interesting. So can not comment on correctness. nit: new subsection for IBLT/syncps explanation ? nit: this is providing reliability which i was asking for upfront, so it would be good to mention that explicitly avbove where i asked with forward pointers to this section. 575 On broadcast media, syncps uses the cStates it hears to suppress 576 sending its own and listens for any cAdds that add to its cState. 577 This means that one-to-many Publications require one cState and one 578 cAdd to be sent, independently of the number of members desiring the 579 Publication (the theoretical minimum possible for reliable delivery). 580 The digest size of a cState can be controlled by Publication 581 lifetime, dynamically constructing the digest to maximize 582 communication progress [Graphene][Graphene19] and, if necessary for a 583 large network, dynamically adapting topic specificity. 585 A cAdd with new Publication(s) responds to a particular cState so a 586 receiving syncps removes that cState as a pending query (it will be 587 replaced with a new cState with the addition of the new items). Any 588 DeftT that is missing a Publication (due to being out-of-range or 589 asleep, etc.) can receive it from any other DeftT. A syncps will 590 continue to send cAdds as long as cStates are received that are 591 missing any of its active Publications. This results in reliability 592 that is subscriber-oriented, not publisher-oriented and is efficient 593 for broadcast media, particularly with protocol features designed to 594 prevent multiple redundant broadcasts. 596 2.3. Formats of DeftT Communications 598 In DeftT, information containers (i.e., Publications, cAdds, Cstate) 599 hold names, content and signatures in TLVs. Tables 1-3 layout the 600 formats of Publications, cStates, cAdds and certificates, which are a 601 special type of Publication (where _keys_ are the information 602 carried). Publications and cAdds use a compatible format which 603 allows them to use the same library signing/validation modules 604 (_sigmgrs_) and the same parser. The cState/cAdd formats and 605 dynamics were originally prototyped using Named Data Networking. 606 Although the NDN code and architecture are not used in DeftT or DCT, 607 a restricted version of the NDNv3 TLV encoding is still used, with 608 TLV types from NDN's TLV Type Registry [NDNS], as is its IANA 609 assigned port number [RFC6335]. 611 In Tables 1-3, the Type in level _i_ is contained within the TLV of 612 the previous level _i-1_ TLV. 614 2.3.1. Publications 616 Publications use a Name TLV to encode the name defined in the schema. 617 A Publication is _valid_ if it starts with the correct TLV, its Name 618 validates against the schema and it contains the five required Level 619 1 TLVs in the right order (top-down in Table 1) and nothing else. 620 MetaInfo contains the ContentType (in DeftT either type Key or Blob). 621 The Content carries the named information and may be empty. 622 SignatureInfo indicates the SignatureType used to select the 623 appropriate signature manager (Figure 8). The SignatureType for a 624 collection's Publications is specified in the schema and each 625 Publication must match it. (A list of current types can be found in 626 [DCT] file include/dct/sigmgrs/sigmgr.hpp.) The KeyLocator holds the 627 thumbprint (see Section 2.3.2) of the certificate that signed this 628 Publication. If the Publication is a certificate, KeyLocator will be 629 followed by the ValidityPeriod. Finally, SignatureValue is 630 determined by the SignatureType and its format is verified by the 631 signature manager. 633 +=======+================+================+==================+ 634 | Level | Level 1 | Level 2 | Comments | 635 | 0 | | | | 636 +=======+================+================+==================+ 637 | Type | | | the value 6 | 638 +-------+----------------+----------------+------------------+ 639 | | Name | | format specified | 640 | | | | by schema | 641 +-------+----------------+----------------+------------------+ 642 | | MetaInfo | | | 643 +-------+----------------+----------------+------------------+ 644 | | | ContentType | either type Key | 645 | | | | or Blob | 646 +-------+----------------+----------------+------------------+ 647 | | Content | | arbitrary byte | 648 | | | | sequence; may | 649 | | | | have length 0 | 650 +-------+----------------+----------------+------------------+ 651 | | SignatureInfo | | | 652 +-------+----------------+----------------+------------------+ 653 | | | SignatureType | Value specified | 654 | | | | by schema | 655 +-------+----------------+----------------+------------------+ 656 | | | KeyLocator | must be a | 657 | | | | thumbprint | 658 +-------+----------------+----------------+------------------+ 659 | | | ValidityPeriod | Only for | 660 | | | | Certificates | 661 +-------+----------------+----------------+------------------+ 662 | | SignatureValue | | format | 663 | | | | determined by | 664 | | | | SignatureType | 665 +-------+----------------+----------------+------------------+ 667 Table 1: Publication format 669 2.3.2. Certificates 671 Certificates (certs) are Publications with the ContentType set to Key 672 and both a KeyLocator and a ValidityPeriod. DCT certs are compatible 673 with the NDN Certificate standard V2 but adhere to a stricter set of nit: reference pls. for that standard 674 conventions to make them resistant to substitution, work factor and 675 DoS attacks. The _only_ KeyLocator type allowed in a DCT cert is a 676 KeyDigest type that must contain the 32 byte SHA256 digest of the 677 _entire_ signing cert (including SignatureValue). A self-signed cert 678 (such as a trust anchor) must set this digest to all zero. This 679 digest, a cert _thumbprint_ [IOTK], is the only locator allowed in 680 _any_ signed Defined-trust object (e.g., Publications, cAdd, schemas, 681 certs) and must be present in every signed object. A signed object 682 using any other type of locator will be considered unverifiable and 683 silently ignored. Certificate Names use a suffix: 685 KEY//dct/ 687 where the cert's thumbprint is the keyID and its creation time is the 688 version. minor: How does this mechanism deal with hash collisions ? useful to explain. (publiction is list of colliding certs with same hash ?) 690 The original publisher of any signed object must ensure that that 691 _all_ certs, schemas, etc., needed to validate the object have been 692 published _before_ the object is published. If a member receives a 693 signed object that is missing any of its signing dependencies, the 694 object should be considered unverifiable and silently ignored. Such 695 objects must not be propagated. 697 2.3.3. cState 699 cState and cAdds are are the PDUs exchanged with the system-level 700 transport in use (e.g., UDP) but are only used by the syncps and face 701 modules Figure 8: syncps creates cState and cAdd PDUs while the face 702 manages the protocol interaction within the trust domain. A cState 703 PDU (see Table 2) is used to report the state of a Collection at its 704 originator. Collections are denoted by structured names which 705 include the identifier of a particular trust domain (thumbprint of 706 its schema cert). in DeftT PDU headers. A cState serves to inform 707 all subscribing entities of a trust domain about Publications 708 currently in the Collection, both so an entity can obtain 709 Publications it is missing and so an entity can add Publications it 710 has that are not reflected in the received cState. 712 +=========+==========+=========+====================================+ 713 | Level 0 | Level 1 | Level 2 | Comments | 714 +=========+==========+=========+====================================+ 715 | Type | | | the value 5 | 716 +---------+----------+---------+------------------------------------+ 717 | | Name | | | 718 +---------+----------+---------+------------------------------------+ 719 | | | Generic | trust domain id | 720 +---------+----------+---------+------------------------------------+ 721 | | | Generic | descriptive collection name | 722 +---------+----------+---------+------------------------------------+ 723 | | | Generic | collection state (sender's view) | 724 +---------+----------+---------+------------------------------------+ 725 | | Nonce | | uniquely distinguishes this | 726 | | | | cState | 727 +---------+----------+---------+------------------------------------+ 728 | | Lifetime | | expiry time (ms after arrival) | 729 +---------+----------+---------+------------------------------------+ 731 Table 2: cState format 733 A cState is _valid_ if it starts with the correct TLV and it contains 734 the three required Level 1 TLVs in the right order (top-down in 735 Table 2) and nothing else. Its Name must start with the trust domain 736 id of the DeftT, then a descriptive Collection name (of at least one 737 component) and finally a representation of the the state of the 738 Collection at the originator. There is no signature for a cState 739 PDU. (The cState format is a restricted subset of an NDNv3 740 Interest.) 742 2.3.4. cAdd nit: would be nice instead of using a flat 2.3.x numbering to make this more structured, e.g.: PDU vs. Certificates 744 A cAdd PDU is used by _syncps_ to add Publications to a collection 745 and carries Publications as Content. _syncps_ creates a cAdd PDU 746 after receiving a cState and only if the recipient has Publications 747 that are not reflected in the received state. A cAdd is _valid_ if 748 it starts with the correct TLV, contains the five required Level 1 749 TLVs in the right order (top-down in Table 3) and nothing else. A 750 cAdd name is identical to the cState to which it responds. 752 +=======+================+================+=======================+ 753 | Level | Level 1 | Level 2 | Comments | 754 | 0 | | | | 755 +=======+================+================+=======================+ 756 | Type | | | the value 6 | 757 +-------+----------------+----------------+-----------------------+ 758 | | Name | | must match Name of | 759 | | | | cState it's adding to | 760 +-------+----------------+----------------+-----------------------+ 761 | | MetaInfo | | | 762 +-------+----------------+----------------+-----------------------+ 763 | | | ContentType | type cAdd | 764 +-------+----------------+----------------+-----------------------+ 765 | | Content | | | 766 +-------+----------------+----------------+-----------------------+ 767 | | | Publication(s) | one or more | 768 | | | | Publications to add | 769 | | | | to the Collection | 770 +-------+----------------+----------------+-----------------------+ 771 | | SignatureInfo | | | 772 +-------+----------------+----------------+-----------------------+ 773 | | | SignatureType | Value indicates which | 774 | | | | signature manager | 775 +-------+----------------+----------------+-----------------------+ 776 | | | KeyLocator | Presence depends on | 777 | | | | SignatureType | 778 +-------+----------------+----------------+-----------------------+ 779 | | SignatureValue | | Value holds the | 780 | | | | signature for this | 781 | | | | PDU | 782 +-------+----------------+----------------+-----------------------+ 784 Table 3: cAdd format 786 The structure of the cState and cAdd Names means that nothing about 787 Publication Names (which are application-oriented) are exposed if 788 encrypted cAdds are specified in a schema. (The schema itself may be 789 distributed in an encrypted cAdd if desired). 791 2.4. Interface between application and network interface 793 Figure 7 and Figure 8 show the blocks and modules application 794 information passes through in DeftT. Its handling of application 795 information can be illustrated using an example of a new Publication 796 at a trust domain member and following its progress into a collection 797 and its reception by other members. For more detail, see the library 798 at [DCT]. DeftT uses [DCT]'s message-based pub/sub (_mbps_) *shim* 799 which kicks off all the necessary DeftT startup when an mbps object 800 is instantiated by the application. After startup, the *pub* syncps nit: whats the difference between your modiles and a shim ? nit: mbps: easy to confuse with Mbps... recommend different abbreviation. 801 of each member will maintain a cState containing the IBLT of its view 802 of the collection. (In the stable, synchronized state, all IBLTs are 803 the same.) 805 Applications use an mbps _subscribe_ method to either subscribe to 806 all messages or to a subset by topic, passing a callback function to 807 handle matching items. These application-level subscriptions are 808 turned into syncps subscriptions via mbps. When the application has 809 new information to communicate, topic items (as parameters) and 810 message are passed to mbps with a _publish_ call. Only these topic 811 components and the message, if any, are passed between the 812 application and mbps. The message may be segmented into multiple 813 Publications by mbps, if the message size exceeds Publication 814 content. For each Publication, mbps-specific components are added to 815 the parameter list and the services of *schemaLib* are invoked in 816 order to build and publish a valid Publication according to the 817 schema (no Publication will be built if the correct attributes are 818 not contained in the member's identity chain). The Publication is 819 signed using the _sign_ method of the appropriate *sigmgr* and passed 820 to *syncps*. 822 syncps adds this Publication to its collection and updates its IBLT 823 to contain the new Publication. Since its application just created 824 it, syncps knows this is a new addition to the collection and it is a 825 response to the current cState. Thus the Publication is packaged 826 into a cAdd and signed using the _sign_ method of the designated 827 *sigmgr* and passed to the face. The updated IBLT is packaged into a 828 new cState that is handed to the face. 830 Members of the trust domain specifically respond only to IPv6 cAdds 831 that share their trust domain identifier (Section 2.3.3 and 832 Section 2.3.4). When a new cAdd is received at a member, the face 833 ensures it matches an outstanding cState and, if so, passes it on to 834 matching syncps(es). Syncps validates (both structurally and 835 cryptographically) the cAdd using the appropriate sigmgr's _validate_ 836 and continues, removing Publications, if valid. Each Publication is 837 structurally validated via a sigmgr and valid Publications are added 838 to the local collection and IBLT. syncps passes this updated cState 839 to the local face. If this Publication matches a subscription it is 840 passed to mbps, invoking the sigmgr's decrypt if the Publication is 841 encrypted (Publication decryption is _not_ available at Relays.) mbps 842 receives the Publication and passes any topic components of interest 843 to the application along with the content (if any) to the application nit: duplicate "to the application" ? 844 via the callback registered when it subscribed. (If the original 845 content was spread across Publications, mbps will wait until all of 846 the content is received. The _sCnt_ component of a mbps Publication 847 Name is used for this.) nit: reference to new sCnt term without reference/explanation. 849 2.5. Schema-based information movement 851 Although the Internet's transport and routing protocols emphasize 852 universal reachability with packet forwarding based on destination, a 853 significant number of applications neither need nor desire to transit 854 the Internet (e.g., see [RFC8799]). This is true for a wide class of 855 OT application. Further, liberal acceptance of packets while 856 depending on the good sending practices of others leaves critical 857 applications open to misconfiguration and attacks. DeftT *only* 858 moves its Publications in accordance with fully specified 859 communication rules. This approach differs from Internet forwarding 860 but offers new opportunities to address the specific security 861 requirements of applications in many Limited Domains. nit: i think this text does not bring home the important point it is trying to make well: The notion of destination based datagram (frame/packet) forwarding is the most widely used mechanism on which communications is built. Ethernet and IP/IPv6 being the most widely used instances. IP/IPv6 specifically are also the enbler of communications across networking as wide varied s the Internet. However this communication paradigm is riddled with the security issue of hacving to transmit and received undesired data which has lead to a whole world of security mechanisms to protect against it, most memorable firewalls whose functionality still escapes any useful standardization As soon as we remove the requirement for a communication paradigm to work across the Internet, we have a much broader and better set of paradigms that do not have this issue. In the IETF for example IP Multicast and in the IRTF ICN/NDN/CCN. Pub/Sub communications a broader set of solutions sharing these benefits. something like this... minor: there is of course however the problem of all these mechanisms of replacing undesired/authenticated traffic with what in DefT case would probably have to be called subscription state. It is unclear to me so far how publications are disributed across varied topologies of relays without flooding of subscription state to all possible parts of the network. We are doing this in better multicast protocols (not flooding that state), but that required pub/sub rendesvous mechanisms which i think i have not seen in the algo description here. And even when this is done ideally, therer is still the attack vector of subscription DoS: in any solution where there can be many topics, you likely expect that only a feasible number is subscribed to, but an attacker is i think not prevented from subscribing from too many, unless there is an explicit protection against that in schemata. But then those schemata would habe to also be enforced in relays because he subscriber in this case is of course impaired and can't be relied upon. 863 DeftTs on the same subnet may be in different trust domains and 864 DeftTs in the same trust domain may not be on the same subnet. In 865 some cases, it is useful to define sub-domains whose DeftTs have a 866 compatible, but more limited, version of the trust domain's 867 communications schema. Compatible means there is at least one 868 publication type and associated signer specification in common or one 869 schema may be a subset of the other. In the case of sub-domains, 870 they be deployed on the same subnet or on different subnets. The 871 rules of a sub-domain compiled to a binary schema distributed as a 872 schema cert will have a different thumbprint from that of the full 873 trust domain. 875 In the case of DeftTs on the same subnet but in different trust 876 domains or different sub-domains, the cState and cAdd PDUs of 877 different domains are differentiated by the _domain id_ (thumbprint 878 of the domain's schema certificate as in Table 2) which can be used 879 at the face module to determine whether or not to process a PDU. A 880 particular sync collection is managed on a single subnet: cState and 881 cAdds are not forwarded off that subnet nor between DeftTs with 882 different domain ids on the same subnet. Instead, schema-compliant 883 Relays connect Publications between separate sync collections of the 884 same trust domain. Collections are differentiated by both subnet 885 (the physical media) and domain id (a required field of the cState 886 and cAdd PDUs). Consequently, cStates and cAdds are subnet-sprecific 887 while Publications belong to a trust domain (or sub-domain). 889 A Relay is implemented [DCT] as an entity running on a device with a 890 DeftT interface on each subnet (two or more) or with multiple DeftT 891 interfaces to the same subnet Figure 9 where each uses a different 892 but compatible version of the others' schema. Each DeftT 893 participates in different sync collections and uses a communication 894 identity valid for the schema used by the DeftT. Only Publications 895 (including certs) are relayed between DeftTs and the Publication must 896 validate against the schema of each DeftT. Consequently cAdd 897 encryption is unique per collection while Publication encryption 898 holds across the domain. 900 As Relays do not originate Publications, their DeftT API module (a 901 "shim", see Section 2.1) performs _pass-through_ of valid 902 Publications. The Relay of Figure 9-left is on three separate 903 wireless subnets. If all three DeftTs are using an identical schema, 904 a new validated cert added to the cert store of an incoming DeftT is 905 then passed to the other two, which each validate the cert before 906 adding to their own cert stores (superfluous in this case, but not a 907 lot of overhead for additional security). When a valid Publication 908 is received at one DeftT, it is passed to the other two DeftTs to 909 validate against their schemas and published if it passes. 911 (Artwork only available as svg: figs/relayextend-rfc.svg) 913 Figure 9: Relays connect subnets 915 A Relay may have different identities and schemas for each DeftT but 916 _must_ have the same trust anchor and schemas must be identical 917 copies, proper subsets or overlapping subsets of the domain schema. 918 Publications that are undefined for a particular DeftT will be 919 silently discarded when they do not validate upon relay, just as they 920 are when received from a face. This means the Relay application of 921 Figure 9-left can remain the same but Publications will only be 922 published to a different subnet if its DeftT has that specification 923 in its schema. Relays may filter Publications at the application 924 level or restrict subscriptions on some of their DeftT interfaces. 925 Figure 9-right shows extending a trust domain geographically by using 926 a unicast connection (e.g., over a cell line or tunnel over the 927 Internet) between two Relays which also interface to local broadcast 928 subnets. Everything on each local subnet shows up on the other. A 929 communications schema subset could be used here to limit the types of 930 Publications sent on the remote link, e.g., logs or alerts. Using 931 this approach in Figure 9-right, local communications for subnet 1 932 can be kept local while subnet 2 might send commands and/or collect 933 log files from subnet 1. minor: this sounds like per-subnet schema defintion based propagation policies instead of automatically driven by subscriptions. That would be a quite big amount of administrative work and potential for misconfiguration. It likely does fit the command&control desire of todays very static OT network management approaches, but i am not sure it would suit more dynamic type of deployment (agile manufacturing for example). But i may be wrong in interpreting this. The explanations are quite dense without examples. 935 More generally, Relays can form a mesh of broadcast subnets with no 936 additional configuration (i.e., Relays on a broadcast network do not 937 need to be configured with others' identities and can join at any 938 time). The mesh is efficient: publications are only added to an 939 individual DeftT's collection once regardless of how it is received. 940 Relays with overlapping broadcast physical media will only add a 941 Publication to any of its DeftTs *once*; syncps ensures there are no 942 duplicates. More on the applicability of DeftT meshes is in 943 Section 5. 945 2.6. Congestion control 947 Each DeftT manages its collection on a single broadcast subnet (since 948 unicast is a proper subset of multicast, a point-to-point connection 949 is viewed as a trivial broadcast subnet) thus only has to deal with 950 that subnet's congestion. As described in the previous section, a 951 device connected to two or more subnets may create DeftTs having the 952 same collection name on each subnet with a *Publication* Relay 953 between them but DeftT never forwards *PDUs* between subnets. It is, 954 of course, possible to run DeftT over an extended broadcast network 955 like a PIM multicast group but the result will generally require more 956 configuration and be less reliable, efficient and secure than DeftT's 957 self-configuring peer-to-peer Relay mesh. 959 DeftT sends _at most one_ copy of any Publication over any subnet, 960 _independent_ of the number of publishers and subscribers on the 961 subnet. Thus the total DeftT traffic on a subnet is strictly upper nit: again ignoring the message loss case - whicha actually is covered ?! 962 bounded by the application-level publication rate. As described in 963 Section 2.2, DeftTs publish a cState specifying the set elements they 964 currently hold. If a DeftT receives a cState specifying the same 965 elements (Publications) it holds, it doesn't send its cState. Thus 966 the upper bound on cState publication rate is the number of members 967 on the subnet divided by the cState lifetime (typically seconds to 968 minutes) but is typically one per cState lifetime due to the 969 duplicate suppression. Each member can send at most one cAdd in 970 response to a cState. This creates a strict request/response flow 971 balance which upper bounds the cAdd traffic rate to (number of 972 members - 1) times the cState publication rate. The flow balance 973 ensures an instance can't send a new cState until it's previous one 974 is either obsoleted by a cAdd or times out. Similarly a cAdd can 975 only be sent in response to the cState which it obsoletes. Thus the 976 number of outstanding PDUs per instance is at most one and DeftT 977 cannot cause subnet congestion collapse. 979 If a Relay is used to extend a trust domain over a path whose 980 bandwidth delay product is many times larger than typical subnet MTUs 981 (1.5-9KB), the one-outstanding-PDU per member constraint can result 982 in poor performance (1500 bytes per 100ms transcontinental RTT is 983 only 120Kbps). DeftT can run over any lower layer transport and 984 stream-oriented transports like TCP or QUIC allow for a 'virtual MTU' 985 that can be set large enough for DeftT to relay at or above the 986 average publication rate (the default is 64KB which can relay up to 987 5Mbps of publications into a 100ms RTT). In this case there can be 988 many lower layer packets in flight for each DeftT cAdd PDU but their 989 congestion control is handled by TCP or QUIC. 991 3. Defined-trust management engine 993 OT applications are distinguished (from general digital 994 communications) by well-defined roles, behaviors and relationships 995 that constrain the information to be communicated (e.g., as noted in 996 [RFC8520]). Structured abstract profiles characterize the 997 capabilities and attributes of Things and can be machine-readable 998 (e.g., [ONE][RFC8520][ZCL]). Energy applications in particular have 999 defined strict role-based access controls [IEC] though proposed 1000 enforcement approaches require interaction of a number of mechanisms 1001 across the communications stack [NERC]. Structured profiles and nit: rephrase sentence, hard to read. 1002 rules strictly define permitted behaviors including what types of 1003 messages can be issued or acted on; undefined behaviors are not 1004 permitted. These rules, along with local configuration, are 1005 incorporated directly into the schemas used by DeftT's integrated 1006 trust management engine to both prohibit undefined behaviors and to 1007 construct compliant Publications. This not only provides a fine- 1008 grained security but a highly _usable_ security, an approach that can 1009 make an application writer's job easier since applications do not 1010 need to contain local configuration and security considerations. 1012 DCT [DCT] includes a language for expressing the rules of 1013 communication, its compiler, and other tools to create the 1014 credentials a DeftT needs at run-time. DCT is example code, not 1015 currently optimized for performance. nit: seems a bit of a contradiction with line 521/522 (not optimzied for performance). 1017 3.1. Communications schemas 1019 Defined-trust's use of communications schemas has been influenced by 1020 [SNC][SDSI] and the field of _trust management_ defined by Blaze et. 1021 al. [DTM] as the study of security policies, security credentials, 1022 and trust relationships. Li et. al. [DLOG] refined some trust 1023 management concepts arguing that the expressive language for the 1024 rules should be _declarative_ (as opposed to the original work). 1025 Communications schemas also have roots in the _trust schemas_ for 1026 Named-Data Networking, described by Yu et al [STNDN] as "an overall 1027 trust model of an application, i.e., what is (are) legitimate key(s) 1028 for each data packet that the application produces or consumes." 1029 [STNDN] gave a general description of how trust schema rules might be 1030 used by an authenticating interpreter finite state machine to 1031 validate packets. A new approach to both a trust schema language and 1032 its integration with communications was introduced in [NDNW] and 1033 extended in [DNMP][IOTK][DCT]. In this approach, a schema is 1034 analogous to the plans for constructing a building. Construction 1035 plans serve multiple purposes: 1037 1. Allow permitting authorities to check that the design meets 1038 applicable codes 1039 2. Show construction workers what to build 1040 3. Let building inspectors validate that as-permitted matches as- 1041 built 1043 Construction plans get this flexibility from being declarative: they 1044 describe "what", not "how". As noted in p4 of [DLOG], a declarative nit: use of non-explained term p4. I guess its the Barefoot programmable mnetwork switch programming language ? ;-)) oh.. page 4 ? No.. 1045 trust management specification based on a formal foundation 1046 guarantees all parties to a communication have the same notion of 1047 what constitutes compliance. This allows a single schema to provide 1048 the same protection as dozens of manually configured, per-node ACL 1049 rules. This approach is a critical part of Defined-trust 1050 Communications which uses the more descriptive term _communication 1051 schema_ as the rules define the communications of a trust domain. minor: If i use my DFeft scheme with a lot of automation, i am going to be better han if you use your ACL only with manual configuration and without tools. A fairer comparison of course is how they would compare if you assumed the samer type of complex, automatated/validated management engine for ACLs as for DefT. And i think there are a couple of those in use in networks. One could consider MUD to be a stepping stone to that, but there has through 30++ years of using ACLs in TCP/IP networks a lot of tools developed. Role Based access control has long since been used in enterprise networks. IMHO give or take tht is usually hasn't been tied to cryptographic identities or pub/sub (might exist, i am just not aware of it), it's fundamentally the same. So maybe fairer to acknowledge the history of starting with management systems for ACLs and then evolving into doing the same for pub/sub and using message based cryptographic end-to-end security - to get the right mix (DefT). But in general, every communication paradigm can be enhanced when you assume a component by which you specify "who can do what"and then create automation from that spe ification to support various goals from that knowlede - security, efficiency, etc... But it does introduce a whole new design paradigm which does not lend itself well to real distributed systems where communicating components are not under a single authority. The controlled networks / limited domains we did talk about in the IETF so far where only expecting this type of coordination up to some point in the stack. This DefT approach takes it a much higher/stronger layer. It perfectly fits a lot of traditional OT. But one should be careful to assume applicability to a wider range of scenarious without reviewing the operational details that would have to emerge. How about when components of an application are independently developed ? Who holds authority of definition of schematas ? 1053 VerSec, an approach to creating schemas, is included with the 1054 Defined-trust Communications Toolkit [DCT]. VerSec includes a 1055 declarative schema specification language with a compiler that checks 1056 the formal soundness of a specification (case 1 above) then converts 1057 it to a signed, compact, binary form. The diagnostic output of the 1058 compiler (including a digraph listing) can be used to inspect that 1059 the intent for the communications schema has indeed been implemented. 1060 The binary form is used by DeftT to build (case 2) or validate (case 1061 3) the Publications (format covered in Section 2.3.1). Certificates 1062 (Section 2.3.2) are a type of Publication, allowing them to be 1063 distributed and validated using DeftT, but they are subject to many 1064 additional constraints that ensure DeftT's security framework is 1065 well-founded. 1067 3.2. A schema language 1069 The VerSec language follows LangSec [LANG] principles to minimize 1070 misconfiguration and attack surface. Its structure is amenable to a 1071 forms-based input or a translator from the structured data profiles 1072 often used by standards [ONE][RFC8520][ZCL]. Declarative languages 1073 are expressive and strongly typed, so they can express the constructs 1074 of these standards in their rules. VerSec continues to evolve and 1075 add new features as its application domain is expanded; the latest 1076 released version is at [DCT]. Other languages and compilers are 1077 possible as long as they supply the features and output needed for 1078 DeftT. 1080 A communication schema expresses the intent for a domain's 1081 communications in fine-grained rules: "who can say what." 1082 Credentials that define "who" are specified along with complete 1083 definitions of "what". Defined-trust communications has been 1084 targeted at OT networking where administrative control is explicit 1085 and it is not unreasonable to assume that identities and 1086 communication rules can be securely configured at every device. The 1087 schema details the meaning and relationship of individual components 1088 of the filename-like names (URI syntax [RFC3986]) of Publications and 1089 certificates. A simple communications schema (Figure 10) defines a 1090 Publication in this domain as *#pub* with a six component name. The 1091 strings between the slashes are the tags used to reference each 1092 component in the structured format and in the run-time schema 1093 library. An example of this usage is the component constraint 1094 following the "&" where _ts_ is a timestamp (64-bit unix timepoints 1095 in microseconds) which will be set with the current time when a 1096 Publication is created. The first component gets its value from the 1097 variable "domain" and #pubPrefix is designated as having this value 1098 so that the schema contains information on what part of the name is 1099 considered common prefix. For the sake of simplicity, the Figure 10 1100 schema puts no constraints on other name components (not the usual 1101 case for OT applications) but requires that Publications of template 1102 #pub are signed by ("<=") a *mbrCert* whose format and signing rule 1103 (signed by a netCert) is also defined. The Validator lines specify 1104 cryptographic signing and validation algorithms from DCT's run-time 1105 library for both the Publication and the cAdd PDU that carries 1106 Publications. Here, both use EdDSA signing. This schema has no 1107 constraints on the inner four name components (additional constraints 1108 could be imposed by the application but they won't be enforced by 1109 DeftT). Member identity comes from a *mbrCert* which allows it to 1110 create legal communications (using the associated private key in 1111 signing). A signing certificate must adhere to the schema; 1112 Publications or cAdds with unknown signers are discarded. The 1113 timestamp component is used to prevent replay attacks. A DeftT adds 1114 its identity certificate chain to the domain certificate collection 1115 (see Section 4.2) at its startup, thus announcing its identity to all 1116 other members. Using the pre-configured trust anchor and schema, any 1117 member can verify the identity of any other member. This approach 1118 means members are not pre-configured with identities of other members 1119 of a trust domain and new entities can join at any time. nit: And the clear winner of longest paragraph is here! ;-) 1121 #pub: /_domain/trgt/topic/loc/arg/_ts & { _ts: timestamp() } <= mbrCert 1122 mbrCert: _domain/_mbrType/_mbrId/_keyinfo <= netCert 1123 netCert: _domain/_keyinfo 1124 #pubPrefix: _domain 1125 #pubValidator: "EdDSA" 1126 #cAddValidator: "EdDSA" 1127 _domain: "example" 1128 _keyinfo: "KEY"/_/"dct"/_ 1130 Figure 10: An example communication schema nit: what (pseudo) language is this ? please write somewhere (In tag ?) 1132 To keep the communications schema both compact and secure, it is 1133 compiled into a binary format that becomes the content of a schema 1134 certificate. The [DCT] _schemaCompile_ converts the text version 1135 (e.g. Figure 10) of the schema into binary as well as reporting 1136 diagnostics (see Figure 11) used to confirm the intent of the rules 1137 (and to flag problems). 1139 Publication #pub: 1140 parameters: trgt topic loc arg 1141 tags: /_domain/trgt/topic/loc/arg/_ts 1142 Publication #pubPrefix: 1143 parameters: 1144 tags: /_domain 1145 Publication #pubValidator: 1146 parameters: 1147 tags: /"EdDSA" 1148 Publication #cAddValidator: 1149 parameters: 1150 tags: /"EdDSA" 1151 Certificate templates: 1152 cert mbrCert: /"example"/_mbrType/_mbrIdId/"KEY"/_/"dct"/_ 1153 cert netCert: /"example"/"KEY"/_/"dct"/_ 1154 binary schema is 301 bytes 1156 Figure 11: schemaCompile diagnostic output for example of Figure 10 1158 Even this simple schema provides useful security, using enrolled 1159 identities both to constrain communications actions (via its #*pub* 1160 format) and to convey membership. To increase security, more detail 1161 can be added to Figure 10. For example, different types of members 1162 can be created, e.g., "admin" and "sensor", and communications 1163 privacy can added by specifying AEAD Validator to encrypt cAdds or 1164 AEADSGN (signed AEAD) to encrypt Publications. To make those member 1165 types meaningful, a role-based security policy could be employed by 1166 defining Publications such that only admins can issue _commands_ and 1167 only sensors can issue _status_. Specifying the AEAD validator for 1168 the cAddValidator means that at least one member of a subnet will 1169 need a key maker attribute in its signing chain. If AEADSGN is 1170 specified for the pubValidator, at least one member of the trust 1171 domain will need key maker capability. In Figure 11 key maker 1172 capability is added to the signing chain of all sensors. WIth AEAD 1173 specified, a key maker is elected during DeftT start up and that key 1174 maker creates, publishes, and periodically updates the shared 1175 encryption key. (Late joining entities are able to discover that a 1176 key maker has already been chosen.) These are the _only_ changes 1177 required in order to increase security and add privacy: neither code 1178 nor binary needs to change and DeftT handles all aspects of 1179 validators. The unique approach to integrating communication rules 1180 into the transport makes it easy to produce secure application code. 1182 adminCert: mbrCert & { _mbrType: "admin" } <= netCert 1183 sensorCert: mbrCert & { _mbrType: "sensor" } <= kmCap 1184 capCert: _network/"CAP"/_capId/_capArg/_keyinfo <= netCert 1185 kmCap: capCert & { _capId: "KM" } 1186 #reportPub: #pub & {topic:"status"} <= sensorCert 1187 #commandPub: #pub & {topic:"command"} <= adminCert 1188 #cAddValidator: "EdDSA" 1190 Figure 12: Enhancing security in the example schema 1192 In DeftT, identities include the member cert and its entire signing 1193 chain. By adding attributes via _capability certificates_ in a 1194 member cert's signing chain, attribute-based security policies can be 1195 implemented without the need for separate servers accessed at run- 1196 time (and the attendant security weaknesses). More on certs will be 1197 covered in Section 4. 1199 Converting desired behavioral structure into a schema is the major 1200 task of applying Defined-trust Communications to an application 1201 domain. Once completed, all the deployment information is contained 1202 in the schema. Although a particular schema cert defines a 1203 particular trust domain, the text version of a schema can be re-used 1204 for related applications. For example, a home IoT schema could be 1205 edited to be specific to a particular home network or a solar rooftop 1206 neighborhood and then signed with a chosen trust anchor. 1208 4. Certificates and identity bundles 1210 Defined-trust's approach is partially based on the seminal SDSI 1211 [SDSI] approach to create user-friendly namespaces that establish 1212 transitive trust through a certificate (cert) chain that validates 1213 locally controlled and managed keys, rather than requiring a global 1214 Public Key Infrastructure (PKI). When certificates are created, they nit: Most PKI are local. As said before, it more proper to refer to WebPKI as the global PKI you are trying to distinguish yourself against. 1215 have a particular context in which they should be utilized and 1216 trusted rather than conferring total authority. This is particularly 1217 useful in OT where communicating entities share an administrative 1218 control and using a third party to certify identity is both 1219 unnecessary and a potential security vulnerability. Well-formed 1220 certificates and identity deployment are critical elements of this 1221 framework. This section describes certificate requirements and the 1222 identity _bundles_ that are securely distributed to trust domain 1223 members. (DCT includes utilities to create certs and bundles.) 1225 4.1. Obviate CA usage 1227 Use of third party certificate authorities (CAs) is often 1228 antithetical to OT security needs. Any use of a CA (remote or local) 1229 results in a single point of failure that greatly reduces system 1230 reliability. An architecture with a single, local, trust root cert 1231 (trust anchor) and no CAs simplifies trust management and avoids the 1232 well-known CA federation and delegation issues and other weaknesses 1233 of the X.509 architecture (summarized at [W509], original references 1234 include [RSK][NVR]). DCT certificates (see Section 2.3.2) can be 1235 generated and signed locally (using supplied utilities) so there is 1236 no reason to aggregate a plethora of unrelated claims into one cert 1237 (avoiding the Aggregation problem [W509]). nit: again, i am not an expert here, and you may want to ask for LAMPs review, but i would refer to WebPKI RFC5280 as opposed to X.509, because X.509 has nothing to do wih the Internet, WebPKI. For example all IDevID in devices are X.509 certificates and typically are based on complete local trust anchors of manufacturers that donot need to be tied into any WebPKI (some may or may not be). 1239 A DCT cert's one and only Subject Name is the Name of the Publication 1240 that contains the public key as its content and neither name nor 1241 content are allowed to contain any optional information or 1242 extensions. Certificates are created with a lifetime; local 1243 production means cert lifetimes can be just as long as necessary (as 1244 recommended in [RFC2693]) so there's no need for the code burden and 1245 increased attack surface associated with certificate revocation lists 1246 (CRLs) or use of on-line certificate status protocol (OSCP). Keys 1247 that require longer lifetimes, like device keys, get new certs before 1248 the current ones expire and may be distributed through DeftT (e.g., 1249 using a variant of the group key distributors in DCT). If there is a 1250 need to exclude previously authorized identities from a domain, there 1251 are a variety of options. The most expedient is via use of an AEAD 1252 cAdd or Publication validator by ensuring that the group key maker(s) 1253 of a domain exclude that entity from subsequent symmetric key 1254 distributions until its identity cert expires (and it is not issued 1255 an update). Another option is to publish an identity that supplants 1256 that of the excluded member. Though more complex, it is also 1257 possible to distribute a new schema and identities (without changing 1258 the trust anchor), e.g., using remote attestation via the TPM. nit: you're reinventing OCSP with your cAdd, aren't you ? Which is fine, given how you can pub that inforrmation - but it would be less confusing if you said so. 1260 From Section 3, a member cert is granted attributes in the schema via 1261 the certs that appear in its member identity chain. Member certs are 1262 _always_ accompanied by their full chain-of-trust, both when 1263 installed and when the member publishes its identity to the cert 1264 collection. Every signing chain in the domain has the same trust 1265 anchor at its root and its legal form specified in the schema. 1266 Without the entire chain, a signer's right to issue Publications 1267 cannot be validated. Cert validation is according to the schema 1268 which may specify attributes and capabilities for Publication signing 1269 from any certificate in the chain. For this model to be well 1270 founded, each cert's *key locator* must _uniquely_ identify the cert 1271 that actually signed it. This property ensures that each locator 1272 resolves to one and only one signing chain. A cert's key locator is 1273 a *thumbprint*, a SHA256 hash of the _entire_ signer's Publication 1274 (name, content, key locator, and signature), ensuring that each 1275 locator resolves to one and only one cert and signing chain. Use of 1276 the thumbprint locator ensures that certs are not open to the 1277 substitution attacks of name-based locators like X.509's "Authority 1278 Key Identifier" and "Issuer" [ConfusedDep][CAvuln][TLSvuln]. 1280 4.2. Identity bundles 1282 Identity bundles comprise the certificates needed to participate in a 1283 trust domain: trust anchor, schema, and the member's identity chain. 1284 The private key corresponding to the leaf certificate of the member's 1285 identity chain should be installed securely when a device is first 1286 commissioned (e.g., out-of-band) for a network. The public certs of 1287 the bundle may be placed in a file in a well-known location or may, 1288 in addition, have their integrity attested or even be encrypted. 1289 Secure device configuration and on-boarding should be carried out 1290 using the best practices most applicable to a particular deployment. 1291 The process of enrolling a device by provisioning an initial secret 1292 and identity in the form of public-private key pair and using this 1293 information to securely onboard a device to a network has a long 1294 history. Current and emergent industry best practices provide a 1295 range of approaches for both secure installation and update of 1296 private keys. For example, the private key of the bundle can be 1297 secured using the Trusted Platform Module, the best current practice 1298 in IoT [TATT][DMR][IAWS][TPM][OTPM][SIOT][QTPM][SKH][RFC8995], or 1299 secure enclave or trusted execution environment (TEE) [ATZ]. In that 1300 case, an authorized configurer adding a new device can use TPM tools 1301 to secure the private signing key and install the rest of the bundle 1302 file in a known location before deploying the device in the network. 1303 Where entities have public-private key pair identities of _any_ 1304 (e.g., non-DCT) type, these can be leveraged for DeftT identity 1305 installation. Figure 13 shows the steps involved in configuring 1306 entities and their correspondence of the steps to the "building 1307 plans" model. (The corresponding tools available in DCT are shown 1308 across the bottom and the relationship to the "building plans" model 1309 is shown across the top.) 1311 (Artwork only available as svg: figs/tools.config-rfc.svg) 1312 Figure 13: Creating and configuring identity bundles 1314 In the examples at [DCT], an identity bundle is given directly to an 1315 application via the command line, useful for development, and the 1316 application passes callbacks to utility functions that supply the 1317 certs and a signing pair separately. For deployment, good key 1318 hygiene using best current practices must be followed e.g., [COMIS]. 1319 In deployment, a small application manager may be programmed for two 1320 specific purposes. First, it is registered with a supervisor [SPRV] 1321 (or similar process control) for its own (re)start to serve as a 1322 bootstrap for the application. Second, it can have access to the TPM 1323 functions and the ability to create "short-lived" (~hours to several 1324 days) public/private key pair(s) that are signed by the installed 1325 (commissioned) private identity key using the TPM. This publication 1326 signing key pair is created at (re)start and at the periodicity of 1327 the signing cert lifetime. Since the signing happens via requests to 1328 the TPM, the identity key cannot be exfiltrated. 1330 The DCT examples and library use member identities to create signing 1331 certs (with associated secret keys) and the example schemas give the 1332 format for these signing cert names. A DeftT will request a new 1333 signing cert shortly before expiration of the one in use. 1335 Upon each signing cert update, only the new cert needs to be 1336 published via DeftT's cert distributor. Figure 14 outlines a 1337 representative procedure. 1339 (Artwork only available as svg: figs/InstallIdbundle-rfc.svg) 1341 Figure 14: Representative commissioning and signing key maintenance 1343 All DCT certs have a validity period. Certs that sign publications 1344 are generated locally so they can easily be refreshed as needed. 1345 Trust anchors, schemas, and the member identity chain are higher 1346 value and often require generation under hermetic conditions by some 1347 authority central to the organization. Their lifetime should be 1348 application- and deployment-specific, but the higher difficulty of 1349 cert production and distribution often necessitates liftetimes of 1350 weeks to years. 1352 Updating schemas and other certificates over the deployed network 1353 (OTA) is application-domain specific and can either make use of 1354 domain best practices or develop custom DeftT-based distribution. 1355 Changing the trust anchor is considered a re-commissioning. The 1356 example here is merely illustrative; with pre-established secure 1357 identities and well-founded approaches to secure on-line 1358 communications, a trust domain could be created OTA using secure 1359 identities established through some other system of identity. 1361 5. Use Cases 1363 5.1. Secure Industrial IoT 1365 IIoT sensors offer significant advantages in industrial process 1366 control including improved accuracy, process optimization, predictive 1367 maintenance and analysis, higher efficiency, low-cost remote 1368 accessibility and monitoring, reduced downtime, power savings, and 1369 reduced costs [IIOT]. The large physical scale of many industrial 1370 processes necessitates that expensive cabling costs be avoided 1371 through wireless transport and battery power. This is a particular 1372 issue in nuclear power plant applications where radioactive shielding 1373 walls are very thick concrete and security regulations make any plant 1374 modifications to add cabling subject to expensive and time-consuming 1375 reviews and permitting. Wireless sensor deployments in an industrial 1376 environment can suffer from signal outages due to shielding walls and 1377 interference caused by rotating machinery and electrical generators. 1378 Multiple _gateway_ devices can receive sensor information and 1379 transmit it to monitor/controllers and servers. These gateway 1380 devices can run DeftT Relay applications and be deployed in a robust 1381 wireless mesh that is resilient against transmission outages, 1382 facilitating reliability. DeftT forms meshes with no additional 1383 configuration (beyond DeftT's usual identity bundle and private key) 1384 as Publications are sent once and heard by all in-range members while 1385 Publications missing from one DeftT's set can be supplied by another 1386 within range. Several gateways may typically be within a single 1387 sensor's wireless range, reducing the number of lost sensor packets. 1388 Other meshed gateways can relay the sensor's Publications either 1389 wirelessly or via a wired ethernet backhaul. 1391 IIoT sensors require tight security. Critical Digital Assets (CDA) 1392 are a class of industrial assets such as power plants or chemical 1393 factories which must be carefully controlled to avoid loss-of-life 1394 accidents. Even when IIoT sensors are not used for direct control of 1395 CDA, spoofed sensor readings can lead to destructive behavior. There 1396 are real-life examples (such as uranium centrifuges) of nation-state 1397 actors changing sensor readings through cyberattacks leading to 1398 equipment damage. These risks result in a requirement for stringent 1399 security reviews and regulation of CDA sensor networks. Despite the 1400 advantages of deploying CDA sensors, adequate security is 1401 prerequisite to deploying the CDA sensors. Information conveyed via 1402 DeftT has an ensured provenance and may be encrypted in an efficient 1403 implementation making it ideal for this use. 1405 IIoT sensors may be mobile (including drone-based) and different 1406 gateways may receive packets from a particular sensor over time. A 1407 DeftT mesh captures Publications _anywhere_ within its combined 1408 network coverage area and ensures it efficiently reaches all members 1409 as long as they are in range of at least one member that has received 1410 the information. An out-of-service or out-of-range member can 1411 receive all active subscribed publications once it is in range and/or 1412 able to communicate. This use of DeftT is illustrated in Figure 15 1413 where bluetooth-using devices (BT Dev) are deployed as sensors, 1414 switches, cameras, lock openers, etc. A WiFi network includes tablet 1415 devices and a monitor/controller computer. Gateway devices each have 1416 a Relay using both a Bluetooth interface and a WiFi interface. 1417 Gateways are placed so that there is always at least one in range of 1418 a BT device and at least one other Gateway (or the Controller) in its 1419 WiFi range. WiFi tablets can move around within range of one or more 1420 Gateways. All the DeftTs may use the same schema, giving devices on 1421 the WiFi network access to all of the BT devices. Applications on 1422 any particular device may subscribe to a subset of the information 1423 available. If privacy of longer-range data is required, the WiFi 1424 DeftTs can use a schema that requires encrypting its cAdds. These 1425 configuration choices are made by changes in the schemas alone, the 1426 application code is exactly the same. No configuration is needed to 1427 make devices recognize one another and syncps will keep 1428 communications efficient, ensuring that all DeftTs in the trust 1429 domain know what information is available. The face ensures that 1430 identical cStates are only sent once (within broadcast range). These 1431 features mean that DeftT forms efficient broadcast meshes with no 1432 additional configuration beyond identity bundles, an important 1433 advantage. 1435 (Artwork only available as svg: figs/meshEx-rfc.svg) 1437 Figure 15: IIOT meshed gateways connect a single trust domain 1439 In addition to specifying encryption and signing types, schema rules 1440 control which users can access specific sensors. For example, an 1441 outside predictive maintenance analysis vendor can be allowed access 1442 to the vibration sensor data from critical motors, relayed through 1443 the Internet, while only plant Security can see images from on-site 1444 cameras. 1446 5.2. Secure access to Distributed Energy Resources (DER) 1448 The electrical power grid is evolving to encompass many smaller 1449 generators with complex interconnections. Renewable energy systems 1450 such as smaller-scale wind and solar generator sites must be 1451 economically accessed by multiple users such as building owners, 1452 renewable asset aggregators, utilities, and maintenance personnel 1453 with varying levels of access rights. North American Electric 1454 Reliability Corporation Critical Infrastructure Protection (NERC CIP) 1455 regulations specify requirements for communications security and 1456 reliability to guard against grid outages [DER]. Legacy NERC CIP 1457 compliant utility communications approaches, using dedicated 1458 physically secured links to a few large generators, are no longer 1459 practical. DeftT offers multiple advantages over bilateral TLS 1460 sessions for this use case: 1462 * Security. Encryption, authentication, and authorization of all 1463 information objects. Secure brokerless pub/sub avoids single- 1464 point broker vulnerabilities. Large generation assets of hundreds 1465 of megawatts to more than 1 gigawatt, particularly nuclear power 1466 plants must be controlled securely or risk large-scale loss of 1467 life accidents. Hence, they are attractive targets for 1468 sophisticated nation-state cyber attackers seeking damage with 1469 national security implications. Even small-scale DER generators 1470 are susceptible to a coordinated attack which could still bring 1471 down the electric grid. 1472 * Scalability. Provisioning, maintaining, and distributing multiple 1473 keys with descriptive, institutionalized, hierarchical names. 1474 DeftT allows keys to be published and securely updated on-line. 1475 Where historically a few hundred large-scale generators could 1476 supply all of the energy needs for a wide geographic area, now 1477 small-scale DER such as residential solar photovoltaic (PV) 1478 systems are located at hundreds of thousands of geographically 1479 dispersed sites. Many new systems are added daily and must be 1480 accommodated economically to spur wider adoption. 1481 * Resiliency. A mesh network of multiple client users, redundant 1482 servers, and end devices adds reliability without sacrificing 1483 security. Generation assets must be kept on-line continuously or 1484 failures risk causing a grid-wide blackout. Climate change is 1485 driving frequent natural disasters including wildfires, 1486 hurricanes, and temperature extremes which can impact the 1487 communications infrastructure. If the network is not resilient 1488 communications breakdowns can disable generators on the grid 1489 leading to blackouts. 1490 * Efficiency. Data can be published once from edge gateways over 1491 expensive cellular links and be accessed through servers by 1492 multiple authorized users, without sacrificing security. For 1493 small residential DER systems, economical but reliable 1494 connectivity is required to spur adoption of PV compared to 1495 purchasing from the grid. However, for analytics, maintenance and 1496 grid control purposes, regular updates from the site by multiple 1497 users are required. Pub/sub via DeftT allows both goals to be met 1498 efficiently. 1499 * Flexible Trust rules: Varying levels of permissions are possible 1500 on a user-by-user and site-by-site basis to tightly control user 1501 security and privacy at the information object level. In an 1502 energy ecosystem with many DER, access requirements are quite 1503 complex. For example, a PV and battery storage system can be 1504 monitored on a regular basis by a homeowner. Separate equipment 1505 vendors for batteries and solar generation assets, including 1506 inverters, need to perform firmware updates or to monitor that the 1507 equipment is operating correctly for maintenance and warranty 1508 purposes. DER aggregators may contract with a utility to supply 1509 and control multiple DER systems, while the utility may want to 1510 access production data and perform some controls themselves such 1511 as during a fire event where the system must be shut down. 1512 Different permissions are required for each user. For example, 1513 hourly usage data which gives detailed insight into customer 1514 behaviors can be seen by the homeowner, but for privacy reasons 1515 might only be shared with the aggregator if permission is given. 1516 These roles and permissions can be expressed in the communication 1517 rules and then secured by DeftT's use of compiled schemas. 1519 The specificity of the requirements of NERC CIP can be used to create 1520 communication schemas that contain site-specifics, allowing 1521 applications to be streamlined and generic for their functionality, 1522 rather than containing security and site-specifics. 1524 6. Using Defined-trust Communications without DeftT 1526 Parts of the defined-trust communications framework could be used 1527 without the DeftT protocol. There are two main elements used in nit: Why ? What benefit would that have ? Incremental deployment ? Pl.s explain. 1528 DeftT: the integrated trust management engine and the multi-party 1529 communications networking layer that makes use of the properties of a 1530 broadcast medium. It's possible to make use of either of these 1531 without DeftT. For example, a message broker could implement the 1532 trust management engine on messages as they arrive at the broker 1533 (e.g., via TLS) to ensure the sender has the proper identity to 1534 publish such a message. If a credential is required in order to 1535 subscribe to certain messages, that could also be checked. Set 1536 reconciliation could be used at the heart of a transport protocol 1537 without using defined-trust security, though signing, encryption, or 1538 integrity hashing could still be employed. 1540 7. Terms nit: Move upfront in the document. Usual place where we have this in IETF RFCs. (AFAIK) 1542 * certificate thumbprint: the 32 byte SHA256 digest of an _entire_ 1543 certificate including its signature ensuring that each thumbprint 1544 resolves to one and only one cert and signing chain 1545 * collection: a set of elements denoted by a structured name that 1546 includes the identifier of a particular communications schema 1547 * communications schema: defined set of rules that cover the 1548 communications for a particular application domain. Where it is 1549 necessary to distinguish between the human readable version and 1550 the compiled binary version, the modifiers "text" or "binary" will 1551 be used. The binary version is placed in a certificate signed by 1552 the domain trust anchor. 1554 * DCT: Defined-trust Communications Toolkit. Running code, examples 1555 and documentation for defined-trust communications tools, a schema 1556 language and compiler, a DeftT implementation, and illustrative 1557 examples 1558 * face: maintains tables of DeftT's cState PDUs to manage efficient 1559 communications with the system transport in use (UDP multicast, 1560 TCP, etc.) 1561 * identity: a certificate signing chain with a particular domain's 1562 trust anchor at its root and a unique member certificate as the 1563 leaf. The public certificates in the chain contain attributes and 1564 capabilities for the leaf member cert. The secret key associated 1565 with the public key of the member cert should be securely 1566 configured for member use. 1567 * identity bundle - entities in a trust domain are commissioned with 1568 an identity bundle of trust anchor, signed communication schema 1569 cert, and the signing chain associated with a particular identity 1570 * Publication: a named information object exchanged used by DeftT 1571 where name structure and the required identity roles and 1572 capabilities for Publications are specified by the schema. 1573 Publications are the elements of the sets that are reconciled by 1574 DeftT's sync protocol. (Capitalization is used to distinguish 1575 this specific use from both the action and more generic use of the 1576 term.) 1577 * protocol data unit (PDU): a single unit of information transmitted 1578 among entities of a network composed of protocol-specific control 1579 information and user data. DeftT uses two types: cState: (from 1580 "collection state") and cAdd: (from "collection additions") 1581 * sync protocol: a synchronization protocol that implements set 1582 reconciliation of Publications on a subnet making use of cState 1583 and cAdd PDUs 1584 * Things: as per [RFC8520], networked digital devices specifically 1585 not intended to be used for general purpose computing 1586 * trust anchor: NIST SP 800-57 Part 1 Rev. 5 definition "An 1587 authoritative entity for which trust is assumed. In a PKI, a 1588 trust anchor is a certification authority, which is represented by 1589 a certificate that is used to verify the signature on a 1590 certificate issued by that trust-anchor. The security of the 1591 validation process depends upon the authenticity and integrity of 1592 the trust anchor's certificate. Trust anchor certificates are 1593 often distributed as self-signed certificates." In defined-trust 1594 communications, a trust anchor is a self-signed certificate which 1595 is the ultimate signer of all certificates in use in a trust 1596 domain, including the communications schema. From RFC4949: trust 1597 anchor definition: An established point of trust (usually based on 1598 the authority of some person, office, or organization) which 1599 allows the validation of a certification chain. 1601 * trust domain: a shorthand form for _Defined-trust Communications 1602 Limited Domain_, a zero trust domain governed by a single trust 1603 anchor and communications schema which is enforced at run-time by 1604 a library (e.g., DCT) using a signed binary copy of the schema at 1605 each member. Nothing is accepted without validation; non- 1606 conforming communications are silently discarded. As the schema 1607 cert is signed by the trust anchor, a trust comain is uniquely 1608 identified by the schema cert's thumbprint. Where context is 1609 clear, just _domain_ may be used. 1610 * trust-based Relay: (or just Relay) a special-purpose entity that 1611 connects a trust domain across different subnets 1613 8. Security Considerations 1615 This document presents a transport protocol that secures the 1616 information it conveys (COMSEC in the language of [RFC3552]). 1617 Security of data in the application space is out-of-scope for this 1618 document, but use of a trusted execution environment (TEE), e.g., 1619 ARM's TrustZone, is recommended where this is of concern. 1621 Unauthorized changes to DeftT code could bypass validation of 1622 received PDUs or modify the content of outgoing PDUs prior to signing 1623 (but only valid PDUs are accepted at receiver; invalid PDUs are 1624 dropped by uncompromised member). Although securing DeftT's code is 1625 out-of-scope for this document, DeftT has been designed to be easily 1626 deployed with a TEE. Revisiting Figure 4, Figure 16 highlights how 1627 all of the DeftT code and data can be placed in the secure zone 1628 (long-dashed line), reachable _only_ via callgates for the Publish 1629 and Subscribe API calls. 1631 (Artwork only available as svg: figs/hwtrust-rfc.svg) 1633 Figure 16: DeftT secured with a Trusted Execution Environment 1635 Providing crypto functions is out-of-scope of this document. The 1636 example implementation uses *libsodium*, an open source library 1637 maintained by experts in the field [SOD]. Crypto functions used in 1638 any alternative implementation should be of similar high quality. 1640 Enrollment of devices is out of scope. A range of solutions are 1641 available and selection of one is dependent on specifics of a 1642 deployment. Example approaches include the Open Connectivity 1643 Foundation (OCF) onboarding and BRSKI [RFC8995]. NIST NCCOE network 1644 layer onboarding might be adapted, treating a communications schema 1645 like a MUD URL. 1647 Protecting private identity and signing keys is out-of-scope for this 1648 document. Good key hygiene should be practiced, securing private 1649 credentials using best practices for a particular application class, 1650 e.g. [COMIS][OWASP]. 1652 DeftT's unit of information transfer is a Publication. It is an 1653 atomic unit sized to fit in a lower layer transport PDU (if needed, 1654 fragmentation and reassembly are done in shim or application). All 1655 Publications must be signed and the signature must be validated. All 1656 Publications start with a Name (Section 2.3.1). Publications are 1657 used both for ephemeral communication, like commands and status 1658 reports, and long-lived information like certs. The set 1659 reconciliation-based syncps protocol identifies Publications using a 1660 hash of the _entire_ Publication, including its signature. A sync 1661 collection can contain at most one instance of any Publication so 1662 replays of Publications in the collection are discarded as duplicates 1663 on arrival. The current DeftT implementation requires weakly 1664 synchronized clocks with a known maximum skew. Publications have a 1665 lifetime enforced by their sync collection; their names include a 1666 timestamp used both to enforce that lifetime and prevent replay 1667 attacks by keeping a Publication in the local collection (but not 1668 advertising its existence) until its lifetime plus the skew has 1669 passed. (Lifetimes in current applications range from days or years 1670 for certs to milliseconds for status and command communications). 1671 Publications arriving a skew time before their timestamp or a skew 1672 time plus lifetime after their timestamp are discarded. 1674 An attacker can modify, drop, spoof, or replay any DeftT PDU or 1675 Publication but DeftT is designed for this to have minimal effect. 1677 1. modification - all DeftT cAdd PDUs must be either signed or AEAD 1678 encrypted with a securely distributed nonce group key. This 1679 choice is specified in the schema and each DeftT checks at 1680 startup that one of these two properties holds for the schema and 1681 throws an error if not. 1683 * for signed PDUs each receiving DeftT must already have the 1684 complete, fully validated signing chain of the signer or the 1685 PDU is dropped. The signing cert must validate the PDU's 1686 signature or the PDU is dropped. 1688 * for encrypted PDUs (and Publications) the symmetric group key 1689 is automatically and securely distributed using signing 1690 identities. Each receiver uses its copy of the current 1691 symmetric key to validate the AEAD MAC and decrypt the PDU 1692 content. Invalid or malformed PDUs and Publications are 1693 dropped. 1695 cState modification to continually send an older, less complete 1696 state in order to generate the sending of cAdds could create a 1697 DoS attack but counter measures could be implemented using 1698 available DeftT information in order to isolate that entity or 1699 remove it from the trust domain. 1701 2. dropped PDUs - DeftT's sync protocol periodically republishes 1702 cState messages which results in (re)sending dropped cAdds. 1703 Unlike unicast transports, DeftT can and will obtain any 1704 Publications missing from its collection from any member that has 1705 a valid copy. 1707 3. spoofing - DeftT uses a trust management engine that validates 1708 the signing. Malformed Publications and PDUs are dropped as 1709 early as possible. 1711 4. replay - A cAdd is sent in response to a specific cState, so a 1712 replayed cAdd that matches a current cState simply serves a 1713 retransmit of the cAdd's Publication which will be filtered for 1714 duplicates and obsolescence as described above. A cAdd that 1715 doesn't match a current cState will be dropped on arrival. 1717 Peer member authentication in DeftT comes through the integrated 1718 trust management engine. Every DeftT instance is started with an 1719 identity bundle that includes the domain trust anchor, the schema in 1720 certificate format signed by this trust anchor, and its own member 1721 identity chain with a private identity key and the chain signed at 1722 the root by trust anchor. Members publish their identity chains 1723 before any Publications are sent. The trust management engine 1724 unconditionally drops any Publication or PDU that does not have a 1725 valid signer or whose signer lacks the role or capabilities required 1726 for that particular Publication or PDU. 1728 DeftT takes a modular approach to signing/validation of its PDUs and 1729 Publications, so a number of approaches to integrity, authenticity, 1730 and confidentiality are possible (and several are available at 1731 [DCT]). Security features that are found to have vulnerabilities 1732 will be removed or updated and new features are easily added. 1734 A compromised member of a trust domain can only build messages that 1735 match the role and attributes in its signing chain. Thus, a 1736 compromised lightbulb can lie about its state or refuse to turn on, 1737 but it can't tell the front door to unlock or send camera footage to 1738 a remote location. Multiple PDUs could be generated, resulting in 1739 flooding the subnet. There are possible counter-measures that could 1740 be taken if some detection code is added to the current DeftT, but 1741 this is deferred for specific applications with specific types of 1742 threats and desired responses. 1744 The example encryption modules provide for encryption on both cAdd 1745 PDUs and Publications. The latter _must_ be signed by the originator 1746 in addition to being encrypted. This is not required for cAdd PDUs, 1747 so the specific entity that sent the cAdd cannot be determined but 1748 the Publications it carries _must_ be signed, even if not encrypted. 1749 In DeftT, any member can resend a Publication from any other member 1750 (without modification) so group encryption (in effect, group signing) 1751 is no different. Some other encryption approaches are provided whose 1752 potential vulnerabilities are described with their implementations 1753 and a signed, encrypted approach is also available [DCT]. 1755 DeftT relies on libsodium and linux random implementations with 1756 respect to entropy issues. In general, these are quite application- 1757 dependent and should be further addressed for particular deployments. 1759 9. IANA Considerations 1761 This document has no IANA actions. 1763 10. Normative References 1765 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1766 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1767 . 1769 [RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. 1770 Zuñiga, "Multicast Considerations over IEEE 802 Wireless 1771 Media", RFC 9119, DOI 10.17487/RFC9119, October 2021, 1772 . 1774 11. Informative References 1776 [ATZ] Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S. 1777 Martin, "TrustZone Explained: Architectural Features and 1778 Use Cases", 2016, . 1780 [CAvuln] Marlinspike, M., "More Tricks for Defeating SSL in 1781 Practice", 2009, . 1785 [CHPT] CheckPoint, "The Dark Side of Smart Lighting: Check Point 1786 Research Shows How Business and Home Networks Can Be 1787 Hacked from a Lightbulb", February 2020, 1788 . 1793 [CIDS] OperantNetworks, "Cybersecurity Intrusion Detection System 1794 for Large-Scale Solar Field Networks", 2021, 1795 . 1797 [COMIS] Lydersen, L., "Commissioning Methods for IoT", February 1798 2019, 1799 . 1802 [COST] Guy, W., "Wireless Industrial Networking Alliance, Wired 1803 vs. Wireless: Cost and Reliability", October 2005, 1804 . 1807 [ConfusedDep] 1808 Support, G. C., "Additional authenticated data guide", 1809 July 2021, . 1812 [DCT] Pollere, "Defined-trust Communications Toolkit", 2022, 1813 . 1815 [DER] NERC, "North American Electric Reliability Corporation: 1816 Distributed Energy Resources: Connection, Modeling, and 1817 Reliability Considerations", February 2017, 1818 . 1822 [DIFF] Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese, 1823 "What's the difference?: efficient set reconciliation 1824 without prior context", 2011. 1826 [DIGN] Bandyk, M., "As Dominion, others target 80-year nuclear 1827 plants, cybersecurity concerns complicate digital 1828 upgrades", November 2019, 1829 . 1833 [DLOG] Li, N., Grosof, B., and J. Feigenbaum, "Delegation logic", 1834 February 2003, . 1836 [DMR] al., M. C. E., "Device Management Requirements to Secure 1837 Enterprise IoT Edge Infrastructure", April 2021, 1838 . 1842 [DNMP] Nichols, K., "Lessons Learned Building a Secure Network 1843 Measurement Framework Using Basic NDN", September 2019. 1845 [DTM] Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized 1846 Trust Management", June 1996, 1847 . 1849 [Demers87] Demers, A. J., Greene, D. H., Hauser, C., Irish, W., 1850 Larson, J., Shenker, S., Sturgis, H. E., Swinehart, D. C., 1851 and D. B. Terry, "Epidemic Algorithms for Replicated 1852 Database Maintenance", 1987, 1853 . 1855 [Graphene] Ozisik, A. P., Andresen, G., Bissias, G., Houmansadr, A., 1856 and B. N. Levine, "Graphene: A New Protocol for Block 1857 Propagation Using Set Reconciliation", 2017, 1858 . 1860 [Graphene19] 1861 Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D., 1862 Bissias, G., and S. Katkuri, "Graphene: efficient 1863 interactive set reconciliation applied to blockchain 1864 propagation", 2019, 1865 . 1867 [HSE] Kapersky, "Secure Element", 2022, 1868 . 1871 [IAWS] Ganapathy, K., "Using a Trusted Platform Module for 1872 endpoint device security in AWS IoT Greengrass", November 1873 2019, . 1876 [IBLT] Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom 1877 lookup tables", 2011, 1878 . 1880 [IEC] IEC, "Power systems management and associated information 1881 exchange - Data and communications security - Part 8: 1882 Role-based access control for power system management", 1883 2022, . 1885 [IEC61850] Wikipedia, "IEC 61850", 2021, 1886 . 1888 [IIOT] Rajiv, "Applications of Industrial Internet of Things 1889 (IIoT)", June 2018, . 1892 [IOTK] Nichols, K., "Trust schemas and {ICN:} key to secure home 1893 IoT", 2021, . 1895 [ISO9506MMS] 1896 ISO, "Industrial automation systems --- Manufacturing 1897 Message Specification --- Part 1: Service definition", 1898 2003, . 1901 [LANG] LANGSEC, "LANGSEC: Language-theoretic Security "The View 1902 from the Tower of Babel"", 2021, . 1904 [MATR] Alliance, C. S., "Matter is the foundation for connected 1905 things", 2021, . 1907 [MHST] Wikipedia, "MQTT", 2022, 1908 . 1910 [MINSKY03] Minsky, Y., Trachtenberg, A., and R. Zippel, "Set 1911 reconciliation with nearly optimal communication 1912 complexity", 2003, 1913 . 1915 [MODOT] Saleem, D., Granda, S., Touhiduzzaman, M., Hasandka, A., 1916 Hupp, W., Martin, M., Hossain-McKenzie, S., Cordeiro, P., 1917 Onunkwo, I., and D. Jose, "Modular Security Apparatus for 1918 Managing Distributed Cryptography for Command and Control 1919 Messages on Operational Technology Networks (Module-OT)", 1920 January 2022, 1921 . 1923 [MPSR] Mitzenmacher, M. and R. Pagh, "Simple multi-party set 1924 reconciliation", 2018. 1926 [MQTT] OASIS, "MQTT: The Standard for IoT Messaging", 2022, 1927 . 1929 [NDNS] NDN, "Named Data Networking Packet Format Specification 1930 0.3", 2022, 1931 . 1933 [NDNW] Jacobson, V., "Watching NDN's Waist: How Simplicity 1934 Creates Innovation and Opportunity", July 2019, 1935 . 1938 [NERC] NERC, "Emerging Technology Roundtable - Substation 1939 Automation/IEC 61850", November 2016, 1940 . 1943 [NMUD] al, D. D. E., "Securing Small-Business and Home Internet 1944 of Things (IoT) Devices: Mitigating Network-Based Attacks 1945 Using Manufacturer Usage Description (MUD)", May 2021, 1946 . 1949 [NPPI] Hashemian, H. M., "Nuclear Power Plant Instrumentation and 1950 Control", 2011, . 1953 [NVR] Gutmann, P., "Everything you Never Wanted to Know about 1954 PKI but were Forced to Find Out", 2002, 1955 . 1958 [ONE] OneDM, "One Data Model", 2022, . 1960 [OPR] King, R., "Commercialization of NDN in Cybersecure Energy 1961 System Communications video", 2019, . 1964 [OSCAL] NIST, "OSCAL: the Open Security Controls Assessment 1965 Language", 2022, . 1967 [OTPM] Hinds, L., "Keylime - An Open Source TPM Project for 1968 Remote Trust", November 2019, 1969 . 1971 [OWASP] owasp.org/www-project-sidekek/, "SideKEK README", June 1972 2020, . 1974 [PRAG] e}bowicz, J. W., Cabaj, K., and J. Krawiec, "Messaging 1975 Protocols for IoT Systems---A Pragmatic Comparison", 2021, 1976 . 1978 [QTPM] Arthur, D. C. W., "Quick Tutorial on TPM 2.0", January 1979 2015, . 1982 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1983 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1984 DOI 10.17487/RFC2693, September 1999, 1985 . 1987 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1988 Text on Security Considerations", BCP 72, RFC 3552, 1989 DOI 10.17487/RFC3552, July 2003, 1990 . 1992 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1993 Resource Identifier (URI): Generic Syntax", STD 66, 1994 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1995 . 1997 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1998 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1999 2006, . 2001 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2002 Cheshire, "Internet Assigned Numbers Authority (IANA) 2003 Procedures for the Management of the Service Name and 2004 Transport Protocol Port Number Registry", BCP 165, 2005 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2006 . 2008 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2009 Description Specification", RFC 8520, 2010 DOI 10.17487/RFC8520, March 2019, 2011 . 2013 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2014 and K. Watsen, "Bootstrapping Remote Secure Key 2015 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2016 May 2021, . 2018 [RSK] Ellison, C. and B. Schneier, "Ten Risks of PKI: What 2019 You're Not Being Told About Public Key Infrastructure", 2020 2000. 2022 [SDSI] Rivest, R. L. and B. W. Lampson, "SDSI - A Simple 2023 Distributed Security Infrastructure", April 1996. 2025 [SIOT] Truong, T., "How to Use the TPM to Secure Your IoT/Device 2026 Data", January 2017, . 2029 [SKH] Yates, T., "Secure key handling using the TPM", October 2030 2018, . 2032 [SNC] Smetters, D. K. and V. Jacobson, "Securing Network 2033 Content", October 2009, . 2036 [SOD] Bernstein, D., Lange, T., and P. Schwabe, "libsodium", 2037 2022, . 2039 [SPRV] AgendalessConsulting, "Supervisor: A Process Control 2040 System", 2022, . 2042 [ST] Samsung, "SmartThings API (v1.0-PREVIEW)", 2020, 2043 . 2046 [STNDN] Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson, 2047 V., and L. Zhang, "Schematizing Trust in Named Data 2048 Networking", 2015. 2050 [TATT] Microsoft, "TPM attestation", June 2021, 2051 . 2054 [TLSvuln] al., C. B. E., "Using Frankencerts for Automated 2055 Adversarial Testing of Certificate Validation in SSL/TLS 2056 Implementations", November 2014, 2057 . 2059 [TPM] Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device 2060 Authentication", September 2020, 2061 . 2065 [W509] Wikipedia, "X.509: Security", October 2021, 2066 . 2068 [WSEN] Kintner-Meyer, M., Brambley, M., Carlon, T., and N. 2069 Bauman, "Wireless Sensors: Technology and Cost-Savings for 2070 Commercial Buildings", 2002, 2071 . 2074 [WegmanC81] 2075 Wegman, M. N. and L. Carter, "New Hash Functions and Their 2076 Use in Authentication and Set Equality", 1981, 2077 . 2079 [ZCL] zigbeealliance, "Zigbee Cluster Library Specification 2080 Revision 6", 2019, . 2084 Contributors 2086 Lixia Zhang 2087 UCLA 2088 Email: lixia@cs.ucla.edu 2090 Roger Jungerman 2091 Operant Networks Inc. 2093 Roger contributed much to Section 5. 2095 Authors' Addresses 2097 Kathleen Nichols 2098 Pollere LLC 2099 Email: nichols@pollere.net 2101 Van Jacobson 2102 UCLA 2103 Email: vanj@cs.ucla.edu 2105 Randy King 2106 Operant Networks Inc. 2107 Email: randy.king@operantnetworks.com