Defined-Trust Transport (DeftT) Protocol for Limited Domains
draft-nichols-iotops-defined-trust-transport-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Kathleen Nichols , Van Jacobson , Randy King | ||
| Last updated | 2023-01-25 (Latest revision 2022-11-20) | ||
| Replaces | draft-nichols-tsv-defined-trust-transport | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Reviews |
IOTDIR Early review
(of
-01)
by Suresh Krishnan
On the right track
|
||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists::Revised I-D Needed | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nichols-iotops-defined-trust-transport-00
Network Working Group K. Nichols
Internet-Draft Pollere LLC
Intended status: Informational V. Jacobson
Expires: 24 May 2023 UCLA
R. King
Operant Networks Inc.
20 November 2022
Defined-Trust Transport (DeftT) Protocol for Limited Domains
draft-nichols-iotops-defined-trust-transport-00
Abstract
This document describes a broadcast-friendly, many-to-many Defined-
trust Transport (DeftT) that makes it simple to express and enforce
application and deployment specific integrity, authentication, access
control and behavior constraints directly in the protocol stack.
DeftT combined with IPv6 multicast and modern hardware-based methods
for securing keys and code provides an easy to use foundation for
secure and efficient communications in Limited Domains (RFC8799), in
particular for Operational Technology (OT) networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 May 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Nichols, et al. Expires 24 May 2023 [Page 1]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Environment and use . . . . . . . . . . . . . . . . . . . 4
1.2. Transporting information . . . . . . . . . . . . . . . . 5
1.3. Securing information . . . . . . . . . . . . . . . . . . 7
1.4. Current status . . . . . . . . . . . . . . . . . . . . . 9
2. DeftT and Defined-trust Communications . . . . . . . . . . . 10
2.1. DeftT role in application communications . . . . . . . . 10
2.2. Set Reconciliation enables a broadcast-friendly
transport . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Information movement is based on trust rules . . . . . . 12
2.4. DeftT and congestion control . . . . . . . . . . . . . . 14
2.5. Defined-trust management engine . . . . . . . . . . . . . 15
2.5.1. About trust schemas . . . . . . . . . . . . . . . . . 15
2.5.2. A language for DeftT trust schemas . . . . . . . . . 16
2.6. DC certificates and identity bundles . . . . . . . . . . 19
2.6.1. About DC certificates . . . . . . . . . . . . . . . . 20
2.6.2. Identity bundles . . . . . . . . . . . . . . . . . . 21
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Secure Industrial IoT . . . . . . . . . . . . . . . . . . 22
3.2. Secure access to Distributed Energy Resources (DER) . . . 24
3.3. Using Defined-trust Communications without DeftT . . . . 26
4. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7. Normative References . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. DeftT run-time modules . . . . . . . . . . . . . . . 38
Appendix B. Formats . . . . . . . . . . . . . . . . . . . . . . 39
B.1. Publications . . . . . . . . . . . . . . . . . . . . . . 39
B.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 40
B.3. cState . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.4. cAdd . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
Nichols, et al. Expires 24 May 2023 [Page 2]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
1. Introduction
Decades of success in providing IP connectivity over any physical
media ("IP over everything") has commoditized IP-based
communications. This makes IP an attractive option for Internet of
Things (IoT), Industrial Control Systems (ICS) and Operational
Technologies (OT) applications like building automation, embedded
systems and transportation control, that previously required
proprietary or analog connectivity. For the energy sector in
particular, the growing use of Distributed Energy Resources (DER)
like residential solar has created interest in low cost commodity
networked devices but with added features for security, robustness
and low-power operation [MODOT][OPR][CIDS]. Other emerging uses
include connecting controls and sensors in nuclear power plants and
carbon capture monitoring [DIGN][IIOT].
While moving to an IP network layer is a major advance for OT,
current Internet transport options are a poor match to its needs.
TCP generalized the Arpanet transport notion of a packet "phone call"
between two endpoints into a generic, reliable, bi-directional
bytestream working over IP's stateless unidirectional best-effort
delivery model. Just as the voice phone call model spawned a global
voice communications infrastructure in the 1900s, TCP/IP's two-party
packet sessions are the foundation of today's global data
communication infrastructure. But "good for global communication"
isn't the same as "good for everything". OT applications tend to be
localized and communication-intensive with a primary function of
coordination and control and communication patterns that are many-to-
many. Implementing many-to-many applications over two-party
transport sessions changes the configuration burden and traffic
scaling from the native media's O(_n_) to O(_n_^2) (see Section 1.2).
Further, as OT devices have specific, highly prescribed roles with
strict constraints on "who can say what to which", the opacity of
modern encrypted two-party sessions can make it impossible to enforce
or audit these constraints.
Nichols, et al. Expires 24 May 2023 [Page 3]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
This memo describes a new transport protocol, Defined-trust Transport
(DeftT) for Limited Domains [RFC8799] in which multipoint
communications are enabled through use of a named collection
abstraction and secured by an integrated trust management engine.
DeftT employs multicast (e.g., IPv6 link-local [RFC4291]),
distributed set reconciliation PDU transport, a flexible pub/sub API,
chain-of-trust membership identities, and rules that define the local
context and communication constraints of a deployment in a
declarative language. The rules are used by DeftT's runtime trust
management engine to enforce adherence to the constraints. The
resulting system is efficient, secure and scalable: communication,
signing and validation costs are constant per-publication,
independent of the richness and complexity of the deployment's
constraints or the number of entites deployed.
Device enrollment consists of securely configuring a device with
_identity bundles_, each containing a trust anchor certificate, a
compact and secured copy of the trust rules, and a membership
identity which comprises a secret signing key plus its public
certificate together with all the certs in its signing chain (which
can be used to confer attributes) terminated at the trust anchor.
The signing chains of all communicating members share a common trust
anchor and the rules define legal signing chains, so the bundle
suffices for a member to authenticate and authorize communication
from peers and vice-versa. New members can join and communicate
without labor intensive and error-prone device-to-device association
configuration.
1.1. Environment and use
Due to physical deployment constraints and the high cost of wiring,
OT networks preferentially use radio as their communication medium.
Use of wires is impossible in many installations (untethered Things,
adding connected devices to home and infrastructure networks,
vehicular uses, etc.). Wiring costs far exceed the cost of current
System-on-Chip Wi-Fi IoT devices and the cost differential is
increasing [WSEN][COST]. For example, the popular ESP32 is a
32bit/320KB SRAM RISC with 60 analog and digital I/O channels plus
complete 802.11b/g/n and bluetooth radios on a 5mm die that consumes
70uW in normal operation. It currently costs $0.13 in small
quantities while the estimated cost of pulling cable to retrofit
nuclear power plants is presently $2000/ft [NPPI].
OT applications are frequently Limited Domain with communications
that are local, have a many-to-many pattern, and use application-
specific identifiers ("topics") for rendezvous. This fits the
generic Publish/Subscribe communications model ("pub/sub") and, as
table 1 in [PRAG] shows, nine of the eleven most widely used IoT
Nichols, et al. Expires 24 May 2023 [Page 4]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
protocols use a topic-based pub/sub transport. For example MQTT, an
open standard developed in 1999 to monitor oil pipelines over
satellite [MQTT][MHST], is now likely the most widely used IoT
protocol (https://mqtt.org/use-cases/ (https://mqtt.org/use-cases/)).
Microsoft Azure, Amazon AWS, Google Cloud, and Cloudflare all offer
hosted MQTT brokers for collecting and connecting sensor and control
data in addition to providing local pub/sub in buildings, factories
and homes. Pub/sub protocols communicate by using the same topic but
need no knowledge of one another. These protocols are typically
_implemented_ as an application layer protocol over a two-party
Internet transport like TCP or TLS which require in-advance
configuration of peer addresses and credentials at each endpoint and
incur unnecessary communications overhead Section 1.2.
1.2. Transporting information
The smart lighting example of Figure 1 illustrates a topic-based pub/
sub application layer protocol in a wireless broadcast subnet. Each
switch is set up to do triple-duty: one click of its on/off paddle
controls some particular light(s), two clicks control all the lights
in the room, and three clicks control all available lights (five
kitchen plus the four den ceiling). Thus a switch button push may
require a message to as many as nine light devices. On a broadcast
physical network each packet sent by the switch is heard by all nine
devices. IPv6 link-level multicast provides a network layer that can
take advantage of this but current IP transport protocols cannot.
Instead, each switch needs to establish nine bi-lateral transport
associations in order to send the published message for all lights to
turn on. Communicating devices must be configured with each other's
IP address and enrolled identity so, for _n_ devices, both the
configuration burden and traffic scale as O(_n^2_). For example,
when an "_all_" event is triggered, every light's radio will receive
nine messages but discard the eight determined to be "not mine." If
a device sleeps, is out-of-range, or has partial connectivity,
additional application-level mechanisms have to be implemented to
accommodate it.
(Artwork only available as svg: iotDeftt-rfc.svg)
Figure 1: Smart lighting use of Pub/Sub
MQTT and other broker-based pub/sub approaches mitigate this by
adding a _broker_ where all transport connections terminate
(Figure 2). Each entity makes a single TCP transport connection with
the broker and tells the broker the topics to which it subscribes.
Thus the kitchen switch uses its single transport session to publish
commands to topic kitchen/counter, topic kitchen or all. The kitchen
counter light uses its broker session to subscribe to those same
Nichols, et al. Expires 24 May 2023 [Page 5]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
three topics. The kitchen ceiling lights subscribe to topics kitchen
ceiling, kitchen and all while den ceiling lights subscribe to topics
den ceiling, den and all. Use of a broker reduces the configuration
burden from O(_n_^2) to O(_n_): 18 transport sessions to 11 for this
simple example but for realistic deployments the reduction is often
greater. There are other advantages: besides their own IP addresses
and identities, devices only need to be configured with those of the
broker. Further, the broker can store messages for temporarily
unavailable devices and use the transport session to confirm the
reception of messages. This approach is popular because the pub/sub
application layer protocol provides an easy-to-use API and the broker
reduces configuration burden while maintaining secure, reliable
delivery and providing short-term in-network storage of messages.
Still the broker implementation doubles the per-device configuration
burden by adding an entity that exists only to implement transport
and traffic still scales as O(_n^2_), e.g., any switch publishing to
all lights results in ten (unicast) message transfers over the wifi
network. Further, the broker introduces a single point of failure
into a network that is richly connected physically.
(Artwork only available as svg: iotMQTT-rfc.svg)
Figure 2: Brokers enable Pub/Sub over connection/session protocols
Nichols, et al. Expires 24 May 2023 [Page 6]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Clearly, a transport protocol able to exploit a physical network's
broadcast capabilities would better suit this problem. (Since
unicast is just multicast restricted to peer sets of size 2, a
multicast transport handles all unicast use cases but the converse is
not true.) In the distributed systems literature, communication
associated with coordinating shared objectives has long been modeled
as distributed set reconciliation [WegmanC81][Demers87]. In this
approach, each domain of discourse is some named set, e.g.,
_myhouse.iot_. Each event or action, e.g., a switch button press, is
added as a new element to the instance of _myhouse.iot_ at its point
of origin then the reconciliation process ensures that every instance
of _myhouse.iot_ has this element. In 2000, [MINSKY03] developed a
broadcast-capable set reconciliation algorithm whose communication
cost equaled the set instance _differences_ (which is optimal) but
its polynomial computational cost impeded adoption. In 2011, [DIFF]
used Invertible Bloom Lookup Tables (IBLTs) [IBLT][MPSR] to create a
simple distributed set reconciliation algorithm providing both
optimal communication and computational cost. DeftT uses this
algorithm (see Section 2.2) and takes advantage of IPv6's self-
configuring link local multicast to avoid all manual configuration
and external dependencies. This restores the system design to
Figure 1 where each device has a single, auto-configured transport
that makes use of the broadcast radio medium without need for a
broker or multiple transport associations. Each button push is
broadcast exactly once to be added to the distributed set.
1.3. Securing information
Conventional session-based transports combine publications with
independent topics and purposes under a single session key, providing
privacy by encrypting the sessions between endpoints. The
credentials of endpoints (e.g., a website) are usually attested by a
third party certificate authority (CA) and bound to a DNS name; each
secure transport association requires the exchange of these
credentials which allows for secure exchange of a nonce symmetric
key. In Figure 2 each transport session is a separate security
association where each device needs to validate the broker's
credential and the broker has to validate each device's. This
ensures that transport associations are between two enrolled devices
(protecting against outsider and some MITM attacks) but, once the
transport session has been established there are no constraints
whatsoever on what devices can say. Clearly, this does not protect
against the insider attacks that currently plague OT, e.g., [CHPT]
description of a lightbulb taking over a network. For example, the
basic function of a light switch requires that it be allowed to tell
a light to turn on or off but it almost certainly shouldn't be
allowed to tell the light to overwrite its firmware (fwupd), even
though "on/off" and "fwupd" are both standard capabilities of most
Nichols, et al. Expires 24 May 2023 [Page 7]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
smart light APIs. Once a TLS session is established, the transport
handles "fwupd" publications the same way as "on/off" publications.
Such attacks can be prevented by requiring trust management that
operates per-publication, using trust rules that enable the "fwupd"
from the light switch to be rejected. Combining per-publication
trust decisions with many-to-many communications over broadcast
infrastructure requires per-publication signing rather than session-
based signing. Securing each publication rather than the path it
arrives on deals with a wider spectrum of threats while avoiding the
quadratic session state and traffic burden.
This requires a trust management system such as [DLOG] where each
publisher is responsible for supplying all of the "who/what/where/
when" information needed for each subscriber to _prove_ the
publication complies with system policies. In OT, valid messages
conform to rigid standards on syntax and semantics
[IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL] that can be
combined with site-specific requirements on identities and
capabilities to create a system's trust requirements. Instead of
vulnerable third-party CAs [W509], sites can employ a local root of
trust and locally created certificates. If, as described in [DLOG],
the system's trust requirements are expressed using a _declarative_
framework, they can be validated for consistency and completeness.
These trust requirements in the declarative language can be converted
to a compact runtime form which can be authorized and secured via
signing with the system trust anchor. This _trust schema_ (TS) is a
type of certificate that can be distributed, validated and updated
using on-device trusted enclaves [TPM][HSE][ATZ] as part of the
device enrollment process. In DeftT's publication-based transport,
the TS can be used to both construct and validate publications,
guaranteeing that _all_ parts of the system _always_ conform to and
enforce the same rules, even as those rules evolve to meet new
threats (more in Section 2.5.1). DeftT embeds the trust management
mechanism described above directly in the publish and subscribe data
paths as shown below:
(Artwork only available as svg: trustElements-rfc.svg)
Figure 3: Trust management elements of DeftT.
This approach extends LangSec's [LANG] "be definite in what you
accept" principle by using the authenticated common ruleset for belt-
and-suspenders enforcement at both publication and subscription
functions of the transport. If an application asks the Publication
Builder to publish something for which the TS shows it lacks
credentials, an error is thrown and nothing is published.
Independently, the Publication Validator ignores publications that:
Nichols, et al. Expires 24 May 2023 [Page 8]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
* don't have a locally validated, complete signing chain for the
credential that signed it
* the TS shows its signing chain isn't appropriate for this
publication
* have a publication signature that doesn't validate
Note that since an application's subscriptions determine which
publications it wants, only certificates from chains that can sign
publications matching the subscriptions need to be validated or
retained. Thus a device's communication state burden and computation
costs are a function of how many different things are allowed to talk
to it but not how many things it talks to or the total number of
devices in the system. In particular, event driven, publish-only
devices like sensors spend no time or space on validation. Unlike
most 'secure' systems, adding additional constraints to trust schemas
to reduce attack surface results in devices doing _less_ work.
A Limited Domain where all the members communicate via DeftT and are
configured with the same trust anchor, TS, and an identity that
conforms to the TS and is signed by the trust anchor at its root are
in a Defined-trust Communications (DC) Trust Domain (TD). Note that
the particular rules for any deployment are application-specific
(e.g., Is it home IoT or a nuclear power plant?) and site-specific
(specific form of credential and idiosyncrasies in rules) which DeftT
accommodates by being invoked with a ruleset particular for a
deployment. We anticipate that the efforts to create common data
models for specific sectors will lead to easier and more forms-based
configuration of DeftT deployments. (DC
1.4. Current status
An open-source Defined-trust Communications Toolkit [DCT] with an
example implementation of DeftT is maintained by the corresponding
author's company. [DCT] has examples of using DeftT to implement
secure brokerless message-based pub/sub using UDP/IPv6 multicast and
unicast UDP/TCP and include extending a Trust Domain via a unicast
connection or between two broadcast network segments. Working
implementations and performance improvements are occasionally added
to the repository.
Massive build out of the renewable energy sector is driving
connectivity needs for both monitoring and control. Author King's
company, Operant, is currently developing extensions of DeftT in a
mix of open-source and proprietary software tailored for commercial
deployment in support of distributed energy resources (DER). Current
small scale use cases have performed well and expanded usage is
planned. Pollere is also working on home IoT uses. As the needs of
our use cases expand, the Defined-trust Communications (DC)
Nichols, et al. Expires 24 May 2023 [Page 9]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
architecture will evolve. This reflects the development philosophy
of DC to start from solving useful problems with a well-defined scope
and extend from there. DeftT's code is open-source, as befits any
communications protocol, but even more critical for one attempting to
offer security. DCT itself makes use of the open source
cryptographic library libsodium [SOD] and the project is open to
feedback on potential security issues as well as hearing from
potential collaborators.
2. DeftT and Defined-trust Communications
DeftT synchronizes and secures communications between enrolled
members of a Limited Domain [RFC8799]. Like QUIC, DeftT is a user-
space transport protocol that sits between an application and a
system-provided transport like UDP or UDP multicast. DeftT's set
reconciliation communication model between multiple parties contrasts
with the bilateral communication model of TCP or QUIC where a source
and a destination coordinate with one another to transport
information. DeftT collections are denoted by structured names which
include the identifier of a particular TS. Set reconciliation is
used by a protocol that synchronizes the currently active elements of
DeftT collections among all members. Communicating DeftTs may hold
different subsets of the collection at any time (e.g., immediately
after entities add elements to the collection) but its
synchronization protocol ensures they all converge to holding the
complete set of elements within a few round-trip-times following the
changes.
2.1. DeftT role in application communications
Applications use DeftT to add to and access from a distributed
collection of Publications. DeftT enforces "who can say what to
which" as well as providing required integrity, authenticity and
confidentiality. A DeftT instance both constructs and validates all
Publications against the TS's formal, validated rules transparently
to applications. The compiled binary TS is distributed as a trust-
root-signed certificate and that certificate's thumbprint (see
Section 2.6.1 and Section 4) _uniquely_ identifies a _trust domain_
(TD) in DeftT PDU headers. Each DeftT is configured with the trust
anchor used in the TD, the TS cert, and its own credentials for
membership in the TD. Credentials comprise a unique private signing
key along with a public certificate chain rooted at the TD's trust
anchor, contain the capabilities of the member identity and have the
member's public signing key in its leaf certificate. Communicating
DeftTs must be in the same TD, i.e., credentials trace to the TD root
of trust and follow an identical TS. Each DeftT must publish its
credentials to the TD's certificate collection in order to join the
TD. DeftT validates credentials as a certificate chain against the
Nichols, et al. Expires 24 May 2023 [Page 10]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
TS and does not accept Publications without a fully validated signer
identity. This provides fully distributed policy enforcement for the
TD without relying on a secured-perimeter physical network and/or
extensive per-device configuration. DeftT can share an IP network
with non-DeftT traffic as well as DeftT traffic of a different TD.
Privacy via AEAD PDU content encryption is automatically handled
within DeftT.
(Artwork only available as svg: ./transportBD0v2-rfc.svg)
Figure 4: DeftT's external interaction in a network stack
Figure 4 shows the data flow of a DeftT instance. An application-
specific format is used to exchange information with an application.
DeftT uses its TS to package this information into Publications that
is added to its local view of the collection. DeftT's communication
goal is to synchronize the state of this collection for all members.
To this end, two types of PDUs are used to manage the set: cState and
cAdd. cStates are used to report the state of the local collection;
cAdds are used to transport Publications to other TD members that
need them. These PDUs are broadcast on their subnet (e.g., UDP
multicast).
2.2. Set Reconciliation enables a broadcast-friendly transport
DeftT's collection management, described above, is efficiently
realized using set reconciliation where the collection is the set and
the Publications are the elements of the set. In particular, IBLTs
[DIFF][IBLT][MPSR] solve the multi-party set-difference problem
efficiently without the use of prior context and with communication
proportional to the size of the difference between the sets being
compared. DeftT's collection synchronization is carried out in its
_syncps_ module. Syncps announces its _collection state_ (set of
currently known Publications) by sending a cState PDU containing an
IBLT. The cState serves as a query for additional data that isn't
reflected in its local state. Receipt of a cState performs three
simultaneous functions: (1) announces new Publications, (2) notifies
of Publications that peer member(s) are missing and (3) acknowledges
Publication receipt. The first may prompt the recipient to send a
cState to get the new Publication(s). The second results in sending
a cAdd PDU containing all the missing and locally available
Publications that will fit. The third may result in a progress
notification sent up the protocol stack so anything waiting for
delivery confirmation can proceed.
On broadcast media, syncps uses the cStates it hears to suppress
sending its own and listens for any cAdds that add to its cState.
This means that one-to-many Publications require one cState and one
Nichols, et al. Expires 24 May 2023 [Page 11]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
cAdd to be sent, independent of the number of members desiring the
Publication (the theoretical minimum possible for reliable delivery).
The digest size of a cState can be controlled by Publication
lifetime, dynamically constructing the digest to maximize
communication progress [Graphene][Graphene19] and, if necessary for a
large network, dynamically adapting topic specificity.
A cAdd with new Publication(s) responds to a particular cState so a
receiving syncps removes that cState as a pending query (it will be
replaced with a new cState with the addition of the new items). Any
DeftT that is missing a Publication (due to being out-of-range or
asleep, etc.) can receive it from any other DeftT. A syncps will
continue to send cAdds as long as cStates are received that don't
contain some of their Publications. This results in reliability that
is subscriber-oriented, not publisher-oriented and is efficient for
broadcast media, particularly with protocol features designed to
prevent multiple redundant broadcasts.
2.3. Information movement is based on trust rules
Although the Internet's transport and routing protocols emphasize
universal reachability with packet forwarding based on destination, a
significant number of applications neither need nor desire to transit
the Internet (e.g., see [RFC8799]). This is true for a wide class of
OT application. Further, the liberal acceptance of packets while
depending on the good sending practices of others leaves critical
applications open to misconfiguration and attacks. DeftT only moves
its Publications in accordance with fully specified trust rules.
This approach differs from Internet forwarding but offers new
opportunities to address the specific security requirements of
applications in many Limited Domains.
Nichols, et al. Expires 24 May 2023 [Page 12]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
DeftTs on the same subnet may not be in the same TD and DeftTs in the
same TD may not be on the same subnet. In the former case, cState
and cAdd PDUs of different TDs are differentiated by the trust domain
id (thumbprint of the TD's TS certificate) which can be used to
determine whether or not to process a PDU. A particular _sync zone_
is managed on a single subnet: cState and cAdds are not forwarded off
that subnet. Trust-based _Relays_ connect Publications of separate
sync zones that share the same TD. A Relay is currently implemented
by an application running on a device with a DeftT network interface
on each subnet (two or more) or with multiple DeftT interfaces to the
same subnet where each uses a different but compatible version of the
others' TS. Each DeftT participates in a different sync zone and has
a member identity valid for its sync zone. All DeftTs of a sync zone
use an identical TS to validate Publications. Publications that
arrive via one DeftT may be added to the collections of other DeftTs
of the Relay after validation. Only Publications are relayed between
subnets and the Publication must validate against the TS of each
DeftT. Thus cAdd encryption is unique per subnet/sync zone.
As Relays do not create Publications, they use a special DeftT API
module (a "shim", see Appendix A) that performs "pass-through" of
valid Publications from the application. The Relay of Figure 5-left
is on three separate wireless subnets. If all three DeftTs are using
an identical TS, a new validated cert added to the cert store of its
incoming DeftT then passed to the other two, where each will validate
it before adding to its own cert store (superfluous in this case, but
not a lot of overhead for additional security). When a valid
Publication is received at one DeftT, it is passed to the other two
DeftTs to validate against their copies of the TS and published if it
passes.
(Artwork only available as svg: relayextend-rfc.svg)
Figure 5: Relays connect subnets
A Relay may have different membership identities and TSs for each
DeftT but _must_ have the same trust anchor. Relays can also connect
subsets of a TD, either proper subsets or overlapping subsets.
Publications that are undefined for a particular DeftT will be
silently discarded when they do not validate. This means the Relay
application of Figure 5-left can remain the same but Publications
will only be published to a different subnet if its DeftT has that
format in its TS. Relays may filter Publications at the application
level or restrict subscriptions on some of their DeftT interfaces.
Figure 5-right shows extending a TD geographically by using a unicast
connection (e.g., over a cell line or tunnel over the Internet)
between two Relays which also interface to local broadcast subnets.
Everything on each local subnet shows up on the other. A TD subset
Nichols, et al. Expires 24 May 2023 [Page 13]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
could be used here to limit the types of Publications sent on the
remote link, e.g., logs or alerts. Using this approach in
Figure 5-right, local communications for subnet 1 can be kept local
while subnet 2 might send commands and/or collect log files from
subnet 1.
More generally, Relays can form a mesh of broadcast subnets with no
additional configuration (i.e., Relays on a broadcast network do not
need to be configured with others' identities). The mesh is
efficient: publications are only added to an individual DeftT's
collection once regardless of how it is received. More on the
applicability of DeftT meshes is in Section 3.
2.4. DeftT and congestion control
Each DeftT instance manages its collection on a single broadcast
subnet (since unicast is a proper subset of multicast, a point-to-
point connection is viewed as a trivial broadcast subnet) thus only
has to deal with that subnet's congestion. As described in the
previous section, a device connected to two or more subnets may
create DeftT instances having the same collection name on each subnet
with a _Publication_ Relay between them but DeftT never forwards
_PDUs_ between subnets. It is, of course, possible to run DeftT over
an extended broadcast network like a PIM multicast group but the
result will generally require more configuration and be less
reliable, efficient and secure than DeftT's self-configuring peer-to-
peer Relay mesh.
DeftT sends _at most one_ copy of any publication over any subnet,
_independent_ of the number of publishers and subscribers on the
subnet. Thus the total DeftT traffic on a subnet is strictly upper
bounded by the application-level publication rate. As described in
Section 2.1, DeftTs publish a cState specifying the set elements they
currently hold. If a DeftT receives a cState specifying the same
elements (Publications) it holds, it doesn't send its cState. Thus
the upper bound on cState publication rate is the number of peers on
the subnet divided by the cState lifetime (typically seconds to
minutes) but is typically one per cState lifetime due to the
duplicate suppression. Each peer can send at most one cAdd in
response to a cState. This creates a strict request/response flow
balance which upper bounds the cAdd traffic rate to (number of peers
- 1) times the cState publication rate. The flow balance ensures an
instance can't send a new cState until it's previous one is either
obsoleted by a cAdd or times out. Similarly a cAdd can only be sent
in response to the cState which it obsoletes. Thus the number of
outstanding PDUs per instance is at most one and DeftT cannot cause
subnet congestion collapse.
Nichols, et al. Expires 24 May 2023 [Page 14]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
If a Relay is used to extend a TD over a path whose bandwidth delay
product is many times larger than typical subnet MTUs (1.5-9KB), the
one-outstanding-PDU per peer constraint can result in poor
performance (1500 bytes per 100ms transcontinental RTT is only
120Kbps). DeftT can run over any lower layer transport and stream-
oriented transports like TCP or QUIC allow for a 'virtual MTU' that
can be set large enough for DeftT to relay at or above the average
publication rate (the default is 64KB which can relay up to 5Mbps of
publications into a 100ms RTT). In this case there can be many lower
layer packets in flight for each DeftT cAdd PDU but their congestion
control is handled by TCP or QUIC.
2.5. Defined-trust management engine
OT applications are distinguished (from general digital
communications) by well-defined roles, behaviors and relationships
that constrain the information to be communicated (e.g., as noted in
[RFC8520]). Structured abstract profiles characterize the
capabilities and attributes of Things and can be machine-readable
(e.g., [ONE][RFC8520][ZCL]). Energy applications in particular have
defined strict role-based access controls [IEC] though proposed
enforcement approaches require interaction of a number of mechanisms
across the communications stack [NERC]. Structured profiles and
rules strictly define permitted behaviors including what types of
messages can be issued or acted on; undefined behaviors are not
permitted. These rules, along with local configuration, are
incorporated directly into the TSs used by DeftT's integrated trust
management engine to both prohibit undefined behaviors and to
construct compliant Publications. This not only provides a fine-
grained security but a highly _usable_ security, an approach that can
make an application writer's job easier since applications do not
need to contain local configuration and security considerations.
DCT [DCT] includes a language for expressing the rules of
communication, its compiler, and other tools to create the
credentials a DeftT needs at run-time to function in a particular TD.
2.5.1. About trust schemas
DC's use of trust schemas has been influenced by [SNC][SDSI] and by
_trust management_ defined by Blaze et. al. [DTM] as the study of
security policies, security credentials, and trust relationships. Li
et. al. [DLOG] refined some trust management concepts arguing that
the expressive language for the rules should be _declarative_ (as
opposed to the original work). This body of work influences that of
trust schemas. Trust schemas for Named-Data Networking were
described by Yu et al [STNDN] as "an overall trust model of an
application, i.e., what is (are) legitimate key(s) for each data
Nichols, et al. Expires 24 May 2023 [Page 15]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
packet that the application produces or consumes." [STNDN] gave a
general description of how trust schema rules might be used by an
authenticating interpreter finite state machine to validate packets.
A new approach to both trust schema language and their integration
with applications was introduced in [NDNW] and extended in
[DNMP][IOTK][DCT]. In this approach, a trust schema is analogous to
the plans for constructing a building. Construction plans serve
multiple purposes:
1. Allow permitting authorities to check that the design meets
applicable codes
2. Show construction workers what to build
3. Let building inspectors validate that as-permitted matches as-
built
Construction plans get this flexibility from being declarative: they
describe "what", not "how". As noted in p4 of [DLOG], a declarative
trust management specification based on a formal foundation
guarantees all parties to a communication have the same notion of
what constitutes compliance. This allows a single schema to provide
the same protection as dozens of manually configured, per-node ACL
rules. This approach is a critical part of DC.
VerSec, an implementation approach to creating trust schemas, is
included with the DC Toolkit [DCT]. VerSec includes a declarative
schema specification language with a compiler that checks the formal
soundness of a specification (case 1 above) then converts it to a
signed, compact, binary form. The binary form is used by DeftT to
build (case 2) or validate (case 3) the Publications of a sync
collection. Publications (whose format is covered in Appendix B)
have names, content and signatures in TLVs. DC Certificates
(Section 2.6.1,Appendix B.2) are a type of Publication, allowing them
to be distributed and validated using DeftT, but they are subject to
many additional constraints that ensure DeftT's security framework is
well-founded.
2.5.2. A language for DeftT trust schemas
The VerSec language follows LangSec [LANG] principles to minimize
misconfiguration and attack surface. Its structure is amenable to a
forms-based input or a translator from the structured data profiles
often used by standards [ONE][RFC8520][ZCL]. Declarative languages
are expressive and strongly typed, so they can express the constructs
of these standards in their trust rules. VerSec continues to evolve
to add new features as its application domain is expanded and the
latest released version is at [DCT]. Other languages and compilers
are possible as long as they supply the features and output needed
for DeftT.
Nichols, et al. Expires 24 May 2023 [Page 16]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
A TS expresses the intent for an application domain's communications
in fine-grained rules: "who can say what." Credentials that define
"who" are specified along with complete definitions of "what". DC is
targeted at OT networking where administrative control is explicit
and it is not unreasonable to assume that identities and trust rules
are securely configured at every device. The TS details the meaning
and relationship of individual components of the filename-like names
(URI syntax RFC3986) of Publications and certificates. A simple TS
(Figure 6) defines a Publication in this TD as #pub with a six
component name. The strings between the slashes are the tags used to
reference each component in the structured format and in the run-time
schema library. An example of this usage is the component constraint
following the "&" where _ts_ is a timestamp (64-bit unix timepoints
in microseconds) which will be set with the current time when a
publication is created. The first component gets its value from the
variable "domain" and #pubPrefix is designated as having this value
so that the TS contains information on what part of the name is
considered common prefix. For the sake of simplicity, the Figure 6
trust schema puts no constraints on other name components (not the
usual case for OT applications) but requires that Publications of
template #pub are signed by ("<=") a mbrCert whose format and signing
rule (signed by a netCert) is also defined. The "Validator" lines
specify cryptographic signing and validation algorithms from DCT's
run-time library for both the Publication and the cAdd PDU that
carries Publications. Here, both use EdDSA signing. This schema has
no constraints on the inner four name components (additional
constraints could be imposed by the application but they won't be
enforced by DeftT). Member identity comes from a mbrCert (including
private key) which allows it to create legal communications. The
signing certificate MUST adhere to the TS; Publications or cAdds with
unknown signers are discarded. The timestamp component is used to
prevent replay attacks. DeftT is structured to add its certificate
identity chain to the TD certificate collection (see Section 2.6.2)
when instantiated, making its identity available to all other members
of the TD. Using the pre-configured TD trust anchor and TS, any
member can verify the identity of any other member. This approach
means members are not configured with identities of other members of
a trust domain and new entities can join a trust domain at any time.
#pub: /_domain/trgt/topic/loc/arg/_ts & { _ts: timestamp() } <= mbrCert
mbrCert: _domain/_mbrType/_mbrId/_keyinfo <= netCert
netCert: _domain/_keyinfo
#pubPrefix: _domain
#pubValidator: "EdDSA"
#cAddValidator: "EdDSA"
_domain: "example"
_keyinfo: "KEY"/_/"dct"/_
Nichols, et al. Expires 24 May 2023 [Page 17]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Figure 6: An example trust schema
To keep the trust schema both compact and secure, it is compiled into
a binary format that becomes the content of a TS certificate.
[DCT]'s _schemaCompile_ converts the text version (e.g. Figure 6) of
the TS into a binary output file as well as outputing diagnostics
(see Figure 7) used to confirm the intent of the trust rules (and to
flag problems). TD member entities are configured with the TD's
trust anchor, the TS cert and their own identity. Secure device
configuration and on-boarding should be carried out using appropriate
applicable best practices [TATT][DMR][IAWS][TPM][RFC8995].
Publication #pub:
parameters: trgt topic loc arg
tags: /_domain/trgt/topic/loc/arg/_ts
Publication #pubPrefix:
parameters:
tags: /_domain
Publication #pubValidator:
parameters:
tags: /"EdDSA"
Publication #cAddValidator:
parameters:
tags: /"EdDSA"
Certificate templates:
cert mbrCert: /"example"/_mbrType/_mbrIdId/"KEY"/_/"dct"/_
cert netCert: /"example"/"KEY"/_/"dct"/_
binary schema is 301 bytes
Figure 7: schemaCompile diagnostic output for example of Figure 6
This simple TS provides useful security, using enrolled identities
both to constrain communications actions (via its #pub format) and to
convey membership. To increase security, more detail can be added to
Figure 6. For example, different types of members can be created,
e.g., "admin" and "sensor", and communications privacy can added by
specifying AEAD Validator to encrypt cAdds. To make those member
types meaningful, Publications can be defined such that only admins
can issue commands and only sensors can issue status, a role-based
security policy. Specifying the AEAD validator means that at least
one member of the TD will need the key maker capability in its
signing chain. In Figure 7 key maker capability is added to the
signing chain of all sensors. WIth AEAD specified, a key maker is
elected during DeftT start up and that key maker creates, publishes,
and periodically updates the shared encryption key. (Late joining
entities are able to discover that a key maker has already been
chosen.) These are the _only_ changes required in order to increase
security and add privacy: neither code nor binary needs to change and
Nichols, et al. Expires 24 May 2023 [Page 18]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
DeftT handles all aspects of validators. The unique approach to
integrating the communication rules into the transport makes it easy
to produce secure application code.
adminCert: mbrCert & { _mbrType: "admin" } <= netCert
sensorCert: mbrCert & { _mbrType: "sensor" } <= kmCap
capCert: _network/"CAP"/_capId/_capArg/_keyinfo <= netCert
kmCap: capCert & { _capId: "KM" }
#reportPub: #pub & {topic:"status"} <= sensorCert
#commandPub: #pub & {topic:"command"} <= adminCert
#cAddValidator: "EdDSA"
Figure 8: Enhancing security in the example trust schema
In DC, identities include the member cert and its entire signing
chain. By adding capabilities or attributes via certificates of a
member cert's signing chain, attribute-based security policies can be
implemented without the need for separate servers accessed at run-
time (and the attendant security weaknesses). More on DC certs will
be covered in Section 2.6.
Converting desired behavioral structure into a TS is the major task
of applying Defined-trust Communications to an application domain.
Once completed, all the deployment information is contained in the
TS. Although a particular TS cert defines a particular TD, the text
version of a TS can be re-used for related applications. For
example, a home IoT TS could be edited to be specific to a particular
home network or a solar rooftop neighborhood and then signed with a
chosen trust anchor.
2.6. DC certificates and identity bundles
DC's approach is partially based on the seminal SDSI [SDSI] approach
to create user-friendly namespaces that create transitive trust
through a certificate (cert) chain that validates locally controlled
and managed keys, rather than requiring a global Public Key
Infrastructure (PKI). Certificates are created that have a
particular context in which they should be utilized and trusted
rather than conferring total authority. This is particularly useful
in OT where communicating applications share an administrative
control and using a third party to certify identity is both
unnecessary and a potential security vulnerability. Well-formed
certificates and identity deployment are critical elements of DC.
This section describes certificate requirements and the construction
and installation of an identity _bundle_. DCT includes utilities to
create certs and bundles.
Nichols, et al. Expires 24 May 2023 [Page 19]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
2.6.1. About DC certificates
Use of third party certificate authorities (CAs) is often
antithetical to OT security needs. Any use of a CA (remote or local)
results in a single point of failure that greatly reduces system
reliability. Employing an architecture with a single, local, trust
root cert (trust anchor) and no CAs simplifies trust management and
avoids the well-known CA federation and delegation issues and other
weaknesses of the X.509 architecture (summarized at [W509], original
references include [RSK][NVR]). DC certs (see Appendix B.2) can be
generated and signed locally so there is no reason to aggregate a
plethora of unrelated claims into one cert (avoiding the Aggregation
problem [W509]).
A DC cert's one and only Subject Name is the name of the Publication
that contains the public key as its content and neither name nor
content are allowed to contain any optional information or
extensions. Certificates are created with a lifetime; local
production means cert lifetimes can be just as long as necessary (as
recommended in [RFC2693]) so there's no need for the code burden and
increased attack surface associated with certificate revocation lists
(CRLs) or use of on-line certificate status protocol (OSCP). Keys
that require longer lifetimes, like device keys, get new certs before
the current ones expire and may distribute those through DeftT. If
there is a need to exclude previously authorized identities from a
TD, there are a variety of options. The most expedient is via use of
the AEAD Validator by ensuring that the group key maker(s) of a TD
exclude that entity from subsequent symmetric key distributions until
the identity cert expires. Another option is to publish an identity
that supplants that of the excluded member. Though more complex, it
is also possible to distribute a new TS and identities (without
changing the trust anchor), e.g., using remote attestation via the
TPM.
From Section 2.5, a member cert is granted attributes and
capabilities in the TS via the certs that appear in its signing
chain. Thus member certs are always accompanied by their full
signing chains, both when installed and when the member publishes its
identity (without the private key, of course) to the cert collection.
Without the entire chain, a signer's right to issue publications
cannot be validated. Every signing chain in the TD has the same
trust anchor at its root. DC cert validation is according to the TS
which may specify attributes and capabilities for Publication signing
from any certificate in the chain. For this model to be well
founded, each cert's "key locator" must _uniquely_ identify the cert
that actually signed it. This property ensures that each locator
resolves to one and only one signing chain. A DC cert's key locator
is a _thumbprint_, a SHA256 hash of the _entire_ signer's Publication
Nichols, et al. Expires 24 May 2023 [Page 20]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
(name, content, key locator, and signature), ensuring that each
locator resolves to one and only one cert and signing chain. Use of
the thumbprint locator ensures that DC certs are not open to the
substitution attacks of name-based locators like X.509's "Authority
Key Identifier" and "Issuer" [ConfusedDep][CAvuln][TLSvuln].
2.6.2. Identity bundles
Identity bundles hold the certificates needed to participate in a TD:
trust anchor, trust schema, the member's identity chain, and the
private key corresponding to the leaf certificate of that member's
chain. Identity bundles are intended to be installed securely when a
device is first commissioned (out-of-band) for a network. The public
certs can be placed in a file in a well-known location; only the
private key of the bundle must be secured. The process of enrolling
a device by provisioning an initial secret and identity in the form
of public-private key pair and using this information to securely
onboard a device to a network has a long history. Current and
emergent industry best practices provide a range of approaches for
secure installation and update of private keys. For example, the
private key of the bundle can be secured using the Trusted Platform
Module, the best current practice in IoT
[TATT][DMR][IAWS][TPM][OTPM][SIOT][QTPM][SKH], or secure enclave or
trusted execution environment (TEE) [ATZ]. Then an authorized
configurer adding a new device can use TPM tools to secure the
private signing key and install the rest of the bundle file in a
known location before deploying the device in the network. Figure 9
shows the steps involved in configuring entities and the
correspondence of the steps to the "building plans" model. The
corresponding tools available in DCT are shown across the bottom and
the relationship to the "building plans" model is shown across the
top.
(Artwork only available as svg: tools.config-rfc.svg)
Figure 9: Creating and configuring identity bundles
In the examples at [DCT], an identity bundle is given directly to an
application directly via the command line, useful for development.
For deployment, good key hygiene using best current practices must be
followed e.g., [COMIS]. In deployment, a small application manager
may be programmed for two specific purposes. First, it is registered
with a supervisor [SPRV] (or similar process control) for its own
(re)start to serve as a bootstrap for the application. Second, it
has access to the TPM functions and the ability to create "short-
lived" (~hours to several days) public/private key pair(s) that will
be signed by the private key of the installed identity cert using the
TPM, which will happen at (re)start and at the periodicity of the
Nichols, et al. Expires 24 May 2023 [Page 21]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
cert lifetime. Since the signing happens via requests to the TPM,
the key cannot be exfiltrated. At (re)start, the signing cert is
added to the stored bundle file (the entire chain should be rechecked
for validity) and passed to the application entity as it is invoked.
For periodic signing cert updates, only the new cert needs to be
passed to the already running entity as the rest of the bundle does
not change. Then DeftT uses its cert distributor to publish its new
certs. Figure 10 outlines the procedures.
(Artwork only available as svg: InstallIdbundle-rfc.svg)
Figure 10: Representative commissioning and signing key maintenance
All DCT certs have a validity period. Certs that sign publications
are typically generated locally for the application that's going to
use them so can easily be refreshed as needed. Trust anchors, TSs,
and the secured signing identity are higher value and often require
generation under hermetic conditions by some central authority.
Their lifetime should be application- and deployment-specific, but
the higher difficulty of cert production and distribution often
necessitates liftetimes of weeks to years. Updating trust schemas
and other certificates over the deployed network (OTA) is
application-domain specific and can either make use of domain best
practices or develop custom DeftT-based distribution. Changing the
trust anchor is considered a re-commissioning and not expected to be
done over-the-air.
3. Use Cases
3.1. Secure Industrial IoT
IIoT sensors offer significant advantages in industrial process
control including improved accuracy, process optimization, predictive
maintenance and analysis, higher efficiency, low-cost remote
accessibility and monitoring, reduced downtime, power savings, and
reduced costs [IIOT]. The large physical scale of many industrial
processes necessitates that expensive cabling costs be avoided
through wireless transport and battery power. This is a particular
issue in nuclear power plant applications where radioactive shielding
walls are very thick concrete and security regulations make any plant
modifications to add cabling subject to expensive and time-consuming
reviews and permitting. Wireless sensor deployments in an industrial
environment can suffer from signal outages due to shielding walls and
interference caused by rotating machinery and electrical generators.
Multiple _gateway_ devices that can receive sensor information and
transmit to monitor/controllers and servers can run DeftT Relay
applications and be deployed in a robust wireless mesh that is
resilient against transmission outages, facilitating reliability.
Nichols, et al. Expires 24 May 2023 [Page 22]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
DeftT forms meshes with no additional configuration as Publications
are sent once and heard by all in-range members while Publications
missing from one DeftT's set can be supplied by another within range.
Several gateways may typically be within a single sensor's wireless
range, reducing the number of lost sensor packets. Other meshed
gateways can relay the sensor's Publications either wirelessly or via
a wired ethernet backhaul.
IIoT sensors require tight security. Critical Digital Assets (CDA)
are a class of industrial assets such as power plants or chemical
factories which must be carefully controlled to avoid loss-of-life
accidents. Even when IIoT sensors are not used for direct control of
CDA, spoofed sensor readings can lead to destructive behavior. There
are real-life examples (such as uranium centrifuges) of nation-state
actors changing sensor readings through cyberattacks leading to
equipment damage. These risks result in a requirement for stringent
security reviews and regulation of CDA sensor networks. Despite the
advantages of deploying CDA sensors, adequate security is
prerequisite to deploying the CDA sensors. Information conveyed via
DeftT has an ensured provenance and may be encrypted in an efficient
implementation making it ideal for this use.
IIoT sensors may be mobile (including drone-based) and different
gateways may receive the wireless broadcast of a particular sensor
over time. A DeftT mesh captures Publications anywhere within its
combined wireless network coverage area and ensures it efficiently
reaches all other subscribing DeftTs as long as they are in range of
at least one that has received the information. An out-of-service or
out-of-range DeftT can receive all active subscribed publications
once it is in range and/or able to communicate. This type of use of
DeftT is illustrated in Figure 11 where gateway devices are deployed
with DeftT Relay applications that have a Bluetooth (BT) interface
and a WiFi interface. A number of BT devices are deployed as
sensors, switches, cameras, lock openers, etc. The WiFi network
includes tablet devices and a monitor/controller computer. Gateways
are placed so that there is always at least one gateway in range of a
BT device and at least one gateway (or the controller) in its WiFi
range. WiFi tablets can move around within range of one or more
gateways. If all the DeftTs have an identical trust schema, devices
on the WiFi network have access to all of the BT devices though
applications on any particular device may subscribe to any subset of
the information available. The WiFi DeftTs can be given a trust
schema that requires encrypting its cAdds so that longer-range data
is kept private. These configuration choices are made by changes in
the trust schemas alone, the application code is exactly the same.
No configuration is needed to make devices recognize one another and
the dynamics of syncps will keep communications efficient, ensuring
that all DeftTs in the trust domain know what information is
Nichols, et al. Expires 24 May 2023 [Page 23]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
available. The Face implementation ensures that requested
Publications are only sent once (within a particular range). These
features mean that DeftT forms efficient broadcast meshes with no
additional configuration beyond their identity bundles, an important
advantage.
(Artwork only available as svg: relaymesh-rfc.svg)
Figure 11: IIOT meshed gateways using DeftT Relay applications
In addition to specifying encryption and signing types, trust rules
control which users can access specific sensors. For example, an
outside predictive maintenance analysis vendor can be allowed access
to the vibration sensor data from critical motors which is relayed
through the internet, while only plant Security can see images from
the site cameras due to privacy concerns.
3.2. Secure access to Distributed Energy Resources (DER)
The electrical power grid is evolving to encompass many smaller
generators with complex interconnections. Renewable energy systems
such as smaller-scale wind and solar generator sites must be
economically accessed by multiple users such as building owners,
renewable asset aggregators, utilities, and maintenance personnel
with varying levels of access rights. North American Electric
Reliability Corporation Critical Infrastructure Protection (NERC CIP)
regulations specify requirements for communications security and
reliability to guard against grid outages [DER]. Legacy NERC CIP
compliant utility communications approaches, using dedicated
physically secured links to a few large generators, are no longer
practical. DeftT offers multiple advantages over bilateral TLS
sessions for this use case:
* Security. Encryption, authentication, and authorization of all
information objects. Secure broker-less pub/sub avoids single-
point broker vulnerabilities. Large generation assets of hundreds
of megawatts to more than 1 gigawatt, particularly nuclear power
plants must be controlled securely or risk large-scale loss of
life accidents. Hence, they are attractive targets for
sophisticated nation-state cyber attackers seeking damage with
national security implications. Even small-scale DER generators
are susceptible to a coordinated attack which could still bring
down the electric grid.
* Scalability. Provisioning, maintaining, and distributing multiple
keys with descriptive, institutionalized, hierarchical names.
DeftT allows keys to be published and securely updated on-line.
Where historically a few hundred large-scale generators could
supply all of the energy needs for a wide geographic area, now
Nichols, et al. Expires 24 May 2023 [Page 24]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
small-scale DER such as residential solar photovoltaic (PV)
systems are located at hundreds of thousands of geographically
dispersed sites. Many new systems are added daily and must be
accommodated economically to spur wider adoption.
* Resiliency. A mesh network of multiple client users, redundant
servers, and end devices adds reliability without sacrificing
security. Generation assets must be kept on-line continuously or
failures risk causing a grid-wide blackout. Climate change is
driving frequent natural disasters including wildfires,
hurricanes, and temperature extremes which can impact the
communications infrastructure. If the network is not resilient
communications breakdowns can disable generators on the grid
leading to blackouts.
* Efficiency. Data can be published once from edge gateways over
expensive cellular links and be accessed through servers by
multiple authorized users, without sacrificing security. For
small residential DER systems, economical but reliable
connectivity is required to spur adoption of PV compared to
purchasing from the grid. However, for analytics, maintenance and
grid control purposes, regular updates from the site by multiple
users are required. Pub/sub via DefT allows both goals to be met
efficiently.
* Flexible Trust rules: Varying levels of permissions are possible
on a user-by-user and site-by-site basis to tightly control user
security and privacy at the information object level. In an
energy ecosystem with many DER, access requirements are quite
complex. For example, a PV and battery storage system can be
monitored on a regular basis by a homeowner. Separate equipment
vendors for batteries and solar generation assets, including
inverters, need to perform firmware updates or to monitor that the
equipment is operating correctly for maintenance and warranty
purposes. DER aggregators may contract with a utility to supply
and control multiple DER systems, while the utility may want to
access production data and perform some controls themselves such
as during a fire event where the system must be shut down.
Different permissions are required for each user. For example,
hourly usage data which gives detailed insight into customer
behaviors can be seen by the homeowner, but for privacy reasons
might only be shared with the aggregator if permission is given.
These roles and permissions can be expressed in the trust rules
and then secured by DeftT's use of compiled trust schemas.
The specificity of the requirements of NERC CIP can be used to create
trust schemas that contain site-specifics, allowing applications to
be streamlined and generic for their functionality, rather than
containing security and site-specifics.
Nichols, et al. Expires 24 May 2023 [Page 25]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
3.3. Using Defined-trust Communications without DeftT
Parts of the DC framework could be used without the DeftT protocol.
There are two main elements used in DeftT: the integrated trust
management engine and the multi-party communications networking layer
that makes use of the properties of a broadcast medium. It's
possible to make use of either of these without DeftT. For example,
a message broker could implement the trust management engine on
messages as they arrive at the broker (e.g., via TLS) to ensure the
sender has the proper identity to publish such a message. If a
credential is required in order to subscribe to certain messages,
that could also be checked. Set reconciliation could be used at the
heart of a transport protocol without using defined-trust security,
though signing, encryption, or integrity hashing could still be
employed.
4. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
* DC: Defined-trust Communications
* Defined-trust transport (DeftT): the transport protocol of DC
* DCT: Defined-trust Communications Toolkit. Running code, examples
and documentation for DC tools, a trust schema language and
compiler, a DeftT implementation, and illustrative examples
* trust schema (TS): defined set of rules that cover the
communications for a particular application domain. Where it is
necessary to distinguish between the human readable version and
the compiled binary version, the modifiers "readable" or "binary"
will be used. The binary version is placed in a certificate
signed by a trust anchor.
Nichols, et al. Expires 24 May 2023 [Page 26]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
* trust anchor (TA): NIST SP 800-57 Part 1 Rev. 5 definition "An
authoritative entity for which trust is assumed. In a PKI, a
trust anchor is a certification authority, which is represented by
a certificate that is used to verify the signature on a
certificate issued by that trust-anchor. The security of the
validation process depends upon the authenticity and integrity of
the trust anchor's certificate. Trust anchor certificates are
often distributed as self-signed certificates." In DCF, a trust
anchor is a self-signed certificate which is the ultimate signer
of all certificates in use in a trust domain, including the trust
schema. From RFC4949: trust anchor definition: An established
point of trust (usually based on the authority of some person,
office, or organization) from which a certificate user begins the
validation of a certification chain.
* trust domain (TD): a zero trust network governed by a single trust
anchor and trust schema which is enforced at run-time by a library
using a signed binary copy of the trust schema at each member
entity. Nothing is accepted without validation; non-conforming
communications are silently discarded. As the trust schema cert
is signed by the trust anchor, the trust schema cert's thumbprint
uniquely identifies a trust domain.
* identity: a signing chain with a particular TD's TA at its root
and a unique member certificate as the leaf. The public
certificates in the chain contain attributes and capabilities for
the leaf member cert. The secret key associated with the public
key of the member cert is securely configured for member use.
* certificate thumbprint: the 32 byte SHA256 digest of an _entire_
certificate including its signature ensuring that each thumbprint
resolves to one and only one cert and signing chain
* identity bundle - entities in a trust zone are commissioned with
an identity bundle of trust anchor, signed trust schema, and the
signing certs associated with a particular identity
* protocol data unit (PDU): a single unit of information transmitted
among peer entities of a computer network composed of protocol-
specific control information and user data
* Publication: a named information object exchanged used by DeftT
where name structure and the required identity roles and
capabilities for Publications are specified by the trust schema.
Publications are the elements of sets that are reconciled by
DeftT's sync protocol. (Capitalization is used to distinguish
this specific use from both the action and more generic use of the
term.)
* sync zone: a trust domain, or subdomain, on a single subnet. A
sync zone comprises all the sync collections that DeftTs with a
particular trust schema participate in on a single subnet (e.g.,
pubs, cert, keys)
* sync protocol: a protocol that implements the set reconciliation
of Publications making use of cState and cAdd PDUs
Nichols, et al. Expires 24 May 2023 [Page 27]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
* collection: a set of elements denoted by a structured name that
includes the identifier of a particular trust schema
* cState: (from "collection state")
* cAdd: (from "collection additions")
* Face: maintains tables of DeftT's cState PDUs to manage efficient
communications with the system transport in use (UDP multicast,
TCP, etc.)
* trust-based Relay: a special-purpose entity that connects a trust
domain across different subnets
* Things: as per [RFC8520], networked digital devices specifically
not intended to be used for general purpose computing
5. Security Considerations
This document covers a transport protocol that secures the
information it conveys (COMSEC in the language of [RFC3552]).
Security of data in the application space is out-of-scope for this
document, but use of a trusted execution environment (TEE), e.g.,
ARM's TrustZone, is recommended where this is of concern.
Unauthorized changes to DeftT code could bypass validation of
received PDUs or modify the content of outgoing PDUs prior to signing
(but valid PDUs would still have to be sent or else they will be
dropped by uncompromised entities). Although the security of DeftT's
code is out-of-scope for this document, DeftT has been designed to be
easily deployed with a TEE. Revisiting Figure 3, Figure 12
highlights how all of the DeftT code and data can be placed in the
secure zone (long-dashed line), reachable _only_ via callgates for
the Publish and Subscribe API calls.
(Artwork only available as svg: hwtrust-rfc.svg)
Figure 12: DeftT secured with a Trusted Execution Environment
Providing crypto functions is out-of-scope of this document. The
example implementation uses *libsodium*, an open source library
maintained by experts in the field [SOD]. Crypto functions used in
any alternative implementation should be high quality.
Enrollment of devices is out of scope. A range of solutions are
available and selection of one can be dependent on specifics of a
deployment. Example approaches include the Open Connectivity
Foundation (OCF) onboarding and BRSKI [RFC8995].
Protecting private signing keys is out-of-scope for this document.
Good key hygiene should be practiced, securing private credentials
using best practices for a particular application class, e.g.
[COMIS][OWASP].
Nichols, et al. Expires 24 May 2023 [Page 28]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
DeftT's unit of information transfer is a Publication. It is an
atomic unit sized to fit in a lower layer transport PDU (if needed,
fragmentation and reassembly are done in shim or application). All
Publications MUST be signed and the signature MUST be validated. All
Publications start with a 'name' (Appendix B.1). Publications are
used both for ephemeral communication, like commands and status
reports, and long-lived information like certs. The set
reconciliation-based syncps protocol identifies Publications using a
hash of the _entire_ Publication, including its signature. A sync
collection can contain at most one instance of any Publication so
replays of Publications in the collection are discarded as duplicates
on arrival. The current DeftT implementation requires weakly
synchronized clocks with a known maximum skew. Ephemeral
Publications have a lifetime enforced by their sync collection and
their names include a timestamp used both to enforce that lifetime
and prevent replay attacks by keeping a Publication in the local
collection (but not advertising its existence) until its lifetime
plus the skew has passed. (Lifetimes in current applications range
from days or years for certs to milliseconds for status and command
communications). Publications arriving a skew time before their
timestamp or a skew time plus lifetime after their timestamp are
discarded.
An attacker can modify, drop, spoof, or replay any DeftT PDU or
Publication but DeftT is designed for this to have minimal effect.
1. modification - all DeftT cAdd PDUs MUST be either signed or AEAD
encrypted with a securely distributed nonce group key. This
choice is specified in the trust schema and the per-app startup
checks that one of these two properties holds for the trust
schema and throws an error if not.
* for signed PDUs each receiving DeftT MUST already have the
complete, fully validated signing chain of the signer or the
PDU is dropped. The signing cert MUST validate the PDUs
signature or the PDU is dropped.
* for encrypted PDUs the symmetric group key is automatically
and securely distributed using signing identities. Each
receiver uses its copy of the current symmetric key to
validate the AEAD MAC and decrypt the PDU content. Invalid or
malformed PDUs are dropped.
cState modification to continually send an older, less complete
state in order to generate the sending of cAdds could create a
DoS attack but counter measures could be implemented using
available DeftT information in order to isolate that entity or
remove it from the trust domain.
Nichols, et al. Expires 24 May 2023 [Page 29]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
2. dropped PDUs - DeftT's sync protocol periodically republishes
cState messages which results in (re)sending cAdds. Unlike
unicast transports, DeftT can and will obtain any Publications
missing from its collection from any peer that has a valid copy.
3. spoofing - DeftT uses a trust management engine that validates
the signing. Malformed Publications and PDUs are dropped as
early as possible.
4. replay - A cAdd is sent in response to a specific cState, so a
replayed cAdd that matches a current cState simply serves a
retransmit of the cAdd's Publication which will be filtered for
duplicates and obsolescence as described above. A cAdd that
doesn't match a current cState will be dropped on arrival.
Peer entity authentication in DeftT comes through the integrated
trust management engine. Every DeftT instance is started with an
identity bundle that includes the domain trust anchor, the trust
schema in certificate format signed by this trust anchor, and its own
member identity chain with a private signing key and the chain signed
at the root by trust anchor. Members publish their identity chains
before any Publications are sent. The trust management engine
unconditionally drops any Publication or PDU that does not have a
valid signer or whose signer lacks the role or capabilities required
for that particular Publication or PDU.
DeftT takes a modular approach to signing/validation of its PDUs and
Publications, so a number of approaches to integrity, authenticity,
and confidentiality are possible (and several are available at
[DCT]). Security features that are found to have vulnerabilities
will be removed or updated and new features are easily added.
A compromised member of a trust domain can only build messages that
match the role and capabilities in its signing chain. Thus, a
compromised lightbulb can lie about its state or refuse to turn on,
but it can't tell the front door to unlock or send camera footage to
a remote location. Multiple PDUs could be generated, resulting in
flooding the subnet. There are possible counter-measures that could
be taken if some detection code is added to the current DeftT, but
this is deferred for specific applications with specific types of
threats and desired responses.
Nichols, et al. Expires 24 May 2023 [Page 30]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
The example encryption modules currently use encryption only on cAdd
PDUs (so the specific entity that sent the cAdd cannot be determined)
but the Publications it carries MUST be signed and will be validated.
In DeftT, any member can resend a Publication from any other member
(without modification) so group encryption (in effect, group signing)
is no different. Some other encryption approaches are provided whose
potential vulnerabilities are described with their implementations
and a signed, encrypted approach is also available [DCT].
6. IANA Considerations
This document has no IANA actions.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
8. Informative References
[ATZ] Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S.
Martin, "TrustZone Explained: Architectural Features and
Use Cases", 2016, <https://doi.org/10.1109/CIC.2016.065>.
[CAvuln] Marlinspike, M., "More Tricks for Defeating SSL in
Practice", 2009, <http://2015.hack.lu/archive/2009/moxie-
marlinspike-
some_tricks_for_defeating_ssl_in_practice.pdf>.
[CHPT] CheckPoint, "The Dark Side of Smart Lighting: Check Point
Research Shows How Business and Home Networks Can Be
Hacked from a Lightbulb", February 2020,
<https://www.globenewswire.com/news-
release/2020/02/05/1980090/0/en/The-Dark-Side-of-Smart-
Lighting-Check-Point-Research-Shows-How-Business-and-Home-
Networks-Can-Be-Hacked-from-a-Lightbulb.html>.
Nichols, et al. Expires 24 May 2023 [Page 31]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[CIDS] OperantNetworks, "Cybersecurity Intrusion Detection System
for Large-Scale Solar Field Networks", 2021,
<https://www.sbir.gov/sbirsearch/detail/2104327>.
[COMIS] Lydersen, L., "Commissioning Methods for IoT", February
2019,
<https://www.silabs.com/documents/public/presentations/ew-
2019-iot-security-commissioning-methods-for-iot.pdf>.
[COST] Guy, W., "Wireless Industrial Networking Alliance, Wired
vs. Wireless: Cost and Reliability", October 2005,
<https://www.fierceelectronics.com/embedded/wired-vs-
wireless-cost-and-reliability>.
[ConfusedDep]
Support, G. C., "Additional authenticated data guide",
July 2021, <https://cloud.google.com/kms/docs/additional-
authenticated-data#confused_deputy_attack_example>.
[DCT] Pollere, "Defined-trust Communications Toolkit", 2022,
<https://github.com/pollere/DCT>.
[DER] NERC, "North American Electric Reliability Corporation:
Distributed Energy Resources: Connection, Modeling, and
Reliability Considerations", February 2017,
<https://www.nerc.com/pa/RAPA/ra/
Reliability%20Assessments%20DL/
Distributed_Energy_Resources_Report.pdf>.
[DIFF] Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese,
"What's the difference?: efficient set reconciliation
without prior context", 2011.
[DIGN] Bandyk, M., "As Dominion, others target 80-year nuclear
plants, cybersecurity concerns complicate digital
upgrades", November 2019,
<https://www.utilitydive.com/news/as-nuclear-plants-look-
to-digitize-controls-and-enhance-performance-
cyber/566478/>.
[DLOG] Li, N., Grosof, B., and J. Feigenbaum, "Delegation logic",
February 2003, <https://doi.org/10.1145/605434.605438>.
[DMR] al., M. C. E., "Device Management Requirements to Secure
Enterprise IoT Edge Infrastructure", April 2021,
<https://www.wwt.com/white-paper/device-management-
requirements-to-secure-enterprise-iot-edge-
infrastructure/>.
Nichols, et al. Expires 24 May 2023 [Page 32]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[DNMP] Nichols, K., "Lessons Learned Building a Secure Network
Measurement Framework Using Basic NDN", September 2019.
[DTM] Blaze, M., Feigenbaum, J., and J. Lacy, "Decentralized
Trust Management", June 1996,
<https://doi.org/10.1109/SECPRI.1996.502679>.
[Demers87] Demers, A. J., Greene, D. H., Hauser, C., Irish, W.,
Larson, J., Shenker, S., Sturgis, H. E., Swinehart, D. C.,
and D. B. Terry, "Epidemic Algorithms for Replicated
Database Maintenance", 1987,
<https://doi.org/10.1145/41840.41841>.
[Graphene] Ozisik, A. P., Andresen, G., Bissias, G., Houmansadr, A.,
and B. N. Levine, "Graphene: A New Protocol for Block
Propagation Using Set Reconciliation", 2017,
<https://doi.org/10.1007/978-3-319-67816-0\_24>.
[Graphene19]
Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D.,
Bissias, G., and S. Katkuri, "Graphene: efficient
interactive set reconciliation applied to blockchain
propagation", 2019,
<https://doi.org/10.1145/3341302.3342082>.
[HSE] Kapersky, "Secure Element", 2022,
<https://encyclopedia.kaspersky.com/glossary/secure-
element/>.
[IAWS] Ganapathy, K., "Using a Trusted Platform Module for
endpoint device security in AWS IoT Greengrass", November
2019, <Using a Trusted Platform Module for endpoint device
security in AWS IoT Greengrass>.
[IBLT] Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom
lookup tables", 2011,
<https://doi.org/10.1109/Allerton.2011.6120248>.
[IEC] IEC, "Power systems management and associated information
exchange - Data and communications security - Part 8:
Role-based access control for power system management",
2022, <https://webstore.iec.ch/publication/61822>.
[IEC61850] Wikipedia, "IEC 61850", 2021,
<https://en.wikipedia.org/wiki/IEC_61850>.
Nichols, et al. Expires 24 May 2023 [Page 33]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[IIOT] Rajiv, "Applications of Industrial Internet of Things
(IIoT)", June 2018, <https://www.rfpage.com/applications-
of-industrial-internet-of-things/>.
[IOTK] Nichols, K., "Trust schemas and {ICN:} key to secure home
IoT", 2021, <https://doi.org/10.1145/3460417.3482972>.
[ISO9506MMS]
ISO, "Industrial automation systems --- Manufacturing
Message Specification --- Part 1: Service definition",
2003, <https://www.iso.org/obp/ui/#iso:std:iso:9506:-1:ed-
2:v1:en>.
[LANG] LANGSEC, "LANGSEC: Language-theoretic Security "The View
from the Tower of Babel"", 2021, <http://langsec.org>.
[MATR] Alliance, C. S., "Matter is the foundation for connected
things", 2021, <https://buildwithmatter.com/>.
[MHST] Wikipedia, "MQTT", 2022,
<https://en.wikipedia.org/wiki/MQTT>.
[MINSKY03] Minsky, Y., Trachtenberg, A., and R. Zippel, "Set
reconciliation with nearly optimal communication
complexity", 2003,
<https://doi.org/10.1109/TIT.2003.815784>.
[MODOT] Saleem, D., Granda, S., Touhiduzzaman, M., Hasandka, A.,
Hupp, W., Martin, M., Hossain-McKenzie, S., Cordeiro, P.,
Onunkwo, I., and D. Jose, "Modular Security Apparatus for
Managing Distributed Cryptography for Command and Control
Messages on Operational Technology Networks (Module-OT)",
January 2022,
<https://www.nrel.gov/docs/fy22osti/79974.pdf>.
[MPSR] Mitzenmacher, M. and R. Pagh, "Simple multi-party set
reconciliation", 2018.
[MQTT] OASIS, "MQTT: The Standard for IoT Messaging", 2022,
<mqtt.org>.
[NDNS] NDN, "Named Data Networking Packet Format Specification
0.3", 2022,
<https://named-data.net/doc/NDN-packet-spec/current/>.
Nichols, et al. Expires 24 May 2023 [Page 34]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[NDNW] Jacobson, V., "Watching NDN's Waist: How Simplicity
Creates Innovation and Opportunity", July 2019,
<http://ice-ar.named-data.net/meetings/2019-ICE-WEN-
Annual/0-ICNWEN-Van-Keynote.pdf>.
[NERC] NERC, "Emerging Technology Roundtable - Substation
Automation/IEC 61850", November 2016,
<https://www.nerc.com/pa/CI/Documents/roundtable%20-%20IEC
%2061850%20slides%20%20(20161115).pdf>.
[NMUD] al, D. D. E., "Securing Small-Business and Home Internet
of Things (IoT) Devices: Mitigating Network-Based Attacks
Using Manufacturer Usage Description (MUD)", May 2021,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.1800-15.pdf>.
[NPPI] Hashemian, H. M., "Nuclear Power Plant Instrumentation and
Control", 2011, <https://cdn.intechopen.com/pdfs/21051/InT
echNuclear_power_plant_instrumentation_and_control.pdf>.
[NVR] Gutmann, P., "Everything you Never Wanted to Know about
PKI but were Forced to Find Out", 2002,
<https://www.cs.auckland.ac.nz/~pgut001/pubs/
pkitutorial.pdf>.
[ONE] OneDM, "One Data Model", 2022, <https://onedm.org/>.
[OPR] King, R., "Commercialization of NDN in Cybersecure Energy
System Communications video", 2019, <https://www.nist.gov/
news-events/events/2019/09/ndn-community-meeting>.
[OSCAL] NIST, "OSCAL: the Open Security Controls Assessment
Language", 2022, <https://pages.nist.gov/OSCAL/>.
[OTPM] Hinds, L., "Keylime - An Open Source TPM Project for
Remote Trust", November 2019,
<https://www.youtube.com/watch?v=YtPsruEqGeY>.
[OWASP] owasp.org/www-project-sidekek/, "SideKEK README", June
2020, <https://github.com/OWASP/SideKEK>.
[PRAG] e}bowicz, J. W., Cabaj, K., and J. Krawiec, "Messaging
Protocols for IoT Systems---A Pragmatic Comparison", 2021,
<https://www.mdpi.com/1424-8220/21/20/6904>.
[QTPM] Arthur, D. C. W., "Quick Tutorial on TPM 2.0", January
2015, <https://link.springer.com/
chapter/10.1007/978-1-4302-6584-9_3>.
Nichols, et al. Expires 24 May 2023 [Page 35]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
DOI 10.17487/RFC2693, September 1999,
<https://www.rfc-editor.org/info/rfc2693>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RSK] Ellison, C. and B. Schneier, "Ten Risks of PKI: What
You're Not Being Told About Public Key Infrastructure",
2000.
[SDSI] Rivest, R. L. and B. W. Lampson, "SDSI - A Simple
Distributed Security Infrastructure", April 1996.
[SIOT] Truong, T., "How to Use the TPM to Secure Your IoT/Device
Data", January 2017, <https://tonytruong.net/how-to-use-
the-tpm-to-secure-your-iot-device-data/>.
[SKH] Yates, T., "Secure key handling using the TPM", October
2018, <https://lwn.net/Articles/768419/>.
[SNC] Smetters, D. K. and V. Jacobson, "Securing Network
Content", October 2009, <https://named-data.net/wp-
content/uploads/securing-network-content-tr.pdf>.
Nichols, et al. Expires 24 May 2023 [Page 36]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
[SOD] Bernstein, D., Lange, T., and P. Schwabe, "libsodium",
2022, <https://doc.libsodium.org/>.
[SPRV] AgendalessConsulting, "Supervisor: A Process Control
System", 2022, <http://supervisord.org/>.
[ST] Samsung, "SmartThings API (v1.0-PREVIEW)", 2020,
<https://smartthings.developer.samsung.com/docs/api-ref/
st-api.html##operation/listCapabilities>.
[STNDN] Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson,
V., and L. Zhang, "Schematizing Trust in Named Data
Networking", 2015.
[TATT] Microsoft, "TPM attestation", June 2021,
<https://docs.microsoft.com/en-us/azure/iot-dps/concepts-
tpm-attestation>.
[TLSvuln] al., C. B. E., "Using Frankencerts for Automated
Adversarial Testing of Certificate Validation in SSL/TLS
Implementations", November 2014,
<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4232952/>.
[TPM] Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device
Authentication", September 2020,
<https://www.globalsign.com/en/resources/white-papers-
ebooks/white-paper-tpm-20-and-certificate-based-iot-
device-authentication>.
[W509] Wikipedia, "X.509: Security", October 2021,
<https://en.wikipedia.org/wiki/X.509#Security>.
[WSEN] Kintner-Meyer, M., Brambley, M., Carlon, T., and N.
Bauman, "Wireless Sensors: Technology and Cost-Savings for
Commercial Buildings", 2002,
<https://www.aceee.org/files/proceedings/2002/data/papers/
SS02_Panel7_Paper10.pdf>.
[WegmanC81]
Wegman, M. N. and L. Carter, "New Hash Functions and Their
Use in Authentication and Set Equality", 1981,
<https://doi.org/10.1016/0022-0000(81)90033-7>.
[ZCL] zigbeealliance, "Zigbee Cluster Library Specification
Revision 6", 2019, <https://zigbeealliance.org/wp-content/
uploads/2019/12/07-5123-06-zigbee-cluster-library-
specification.pdf>.
Nichols, et al. Expires 24 May 2023 [Page 37]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Appendix A. DeftT run-time modules
DeftT's required functionality has been implemented in libraries in
the example implementation [DCT]. DeftT is organized in functional
modules that may provide services to other modules in the course of
preparing application-level information for transport and for
extracting application-level information from packets. Extensions
and alternate module implementations are possible but the
functionality and interfaces must be preserved. Following good
security practice, DeftT's Publications are constructed and signed
early in their creation, then are validated (or discarded) early in
the reception process. The signing and validation modules
(_signature managers_) are used for both Publications and cAdds.The
_schemaLib_ module provides certificate store access throughout DeftT
along with access to _distributors_ of group keys, Publication
building and structural validation, and other functions of the trust
management engine. This organization would not be possible in a
strictly layered implementation.
Figure 13 shows the DC module libraries of DCT. The component
descriptions and interactions can appear complex but the internals of
DeftT are completely transparent to an application and the reference
implementation is efficient in both lines of code and performance.The
trust schema completely determines which modules are used. A DeftT
participates in two required collections and MAY participate in
others if required by the schema-designated signature managers. One
of the required collections handles the Publications that carry out
application communications and uses "pubs" for the descriptive
collection name component (see Table 2). The other required
collection manages the certificates of the trust domain and uses
"cert" for the descriptive collection name component. Specific
signature managers MAY require group key distribution in descriptive-
named Collection "keys."
(Artwork only available as svg: DeftTmodules-rfc.svg)
Figure 13: Run-time library modules
A shim serves as the translator between application semantics and the
named information objects (Publications) whose format is defined by
the trust schema. Besides the shim, DeftT components are not
application-specific. New signature managers, distributors, and Face
modules may be added to the library to extend features. More detail
on each module can be found at [DCT] in both code files and
documents.
Nichols, et al. Expires 24 May 2023 [Page 38]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Appendix B. Formats
Application information is packaged in Publications which are carried
in cAdds that are used along with cState PDUs to communicate about
and synchronize Collections. This section documents the format of
Publications, cStates, and cAdds along with certificates, which are a
special case of Publication (where keys are the information carried).
Publications and cAdds use a compatible format which allows them to
use the same library signing/validation modules (_sigmgrs_) and the
same parser. The cState/cAdd formats and dynamics were originally
prototyped using Named Data Networking and a restricted version of
the NDNv3 TLV encoding is still used, with TLV types from NDN's TLV
Type Registry [NDNS], as is its IANA assigned port number [RFC6335].
In Tables 1-3, the Type in level _i_ is contained within the TLV of
the previous level _i-1_ TLV.
B.1. Publications
Publications are used throughout DeftT's modules. A Name TLV is used
to encode the name defined in the trust schema. A Publication is
valid if it starts with the correct TLV, its Name validates against
the trust schema and it contains the five required Level 1 TLVs in
the right order (top-down in Table 1) and nothing else. MetaInfo
contains the ContentType (in DeftT either type Key or Blob). The
Content carries the named information and MAY be empty.
SignatureInfo indicates the SignatureType used to select the
appropriate signature manager (Figure 13). The SignatureType for a
collection's Publications is specified in the trust schema and each
Publication MUST match it. (A list of current types can be found in
[DCT] file include/dct/sigmgrs/sigmgr.hpp.) The KeyLocator
associated with the SignatureType follows then the ValidityPeriod (if
the Publication is a Certificate). Finally, SignatureValue is
determined by the SignatureType and its format is verified by the
signature manager.
Nichols, et al. Expires 24 May 2023 [Page 39]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
+=======+================+================+==================+
| Level | Level 1 | Level 2 | Comments |
| 0 | | | |
+=======+================+================+==================+
| Type | | | MUST be 6 |
+-------+----------------+----------------+------------------+
| | Name | | format specified |
| | | | by trust schema |
+-------+----------------+----------------+------------------+
| | MetaInfo | | |
+-------+----------------+----------------+------------------+
| | | ContentType | MUST be type Key |
| | | | or Blob |
+-------+----------------+----------------+------------------+
| | Content | | arbitrary byte |
| | | | sequence; MAY |
| | | | have length 0 |
+-------+----------------+----------------+------------------+
| | SignatureInfo | | |
+-------+----------------+----------------+------------------+
| | | SignatureType | Value specified |
| | | | by trust schema |
+-------+----------------+----------------+------------------+
| | | KeyLocator | MUST be a |
| | | | ThumbPrint |
+-------+----------------+----------------+------------------+
| | | ValidityPeriod | Only for |
| | | | Certificates |
+-------+----------------+----------------+------------------+
| | SignatureValue | | format |
| | | | determined by |
| | | | SignatureType |
+-------+----------------+----------------+------------------+
Table 1: Publication Format
B.2. Certificates
Certificates (certs) are Publications with the ContentType set to Key
and both a KeyLocator and a ValidityPeriod. DCT certs are compatible
with the NDN Certificate standard V2 but adhere to a stricter set of
conventions to make them resistant to substitution, work factor and
DoS attacks. The only KeyLocator type allowed in a DCT cert is a
KeyDigest type that MUST contain the 32 byte SHA256 digest of the
_entire_ signing cert (including SignatureValue). A self-signed cert
(such as a trust anchor) MUST set this digest to all zero. This
digest, a cert _thumbprint_ [IOTK], is the only locator allowed in
_any_ signed DC object (e.g., Publications, cAdd, schemas, certs) and
Nichols, et al. Expires 24 May 2023 [Page 40]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
MUST be present in every signed object. A signed object using any
other type of locator will be considered unverifiable and silently
ignored. Certificate Names use a suffix:
KEY/<keyID>/dct/<version>
where the cert's thumbprint is the keyID and its creation time is the
version.
The original publisher of any signed object MUST ensure that that
_all_ certs, schemas, etc., needed to validate the object have been
published _before_ the object is published. If a member receives a
signed object but is missing any of its signing dependencies, the
object should be considered unverifiable and silently ignored. Such
objects MUST NOT be propagated.
B.3. cState
cState and cAdds are are the PDUs exchanged with the system-level
transport in use (e.g., UDP) but are only used by syncps and Face
modules Figure 13. Syncps creates cState and cAdd PDUs while the
Face manages the protocol interaction within the trust domain. A
cState PDU (see Table 2) is used to report the state of a Collection
at its originator. A cState serves to inform all subscribing
entities of a trust domain about Publications currently in the
Collection, both so an entity can obtain Publications it is missing
and so an entity can add Publications it has that are not reflected
in the received cState.
Nichols, et al. Expires 24 May 2023 [Page 41]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
+=========+==========+=========+====================================+
| Level 0 | Level 1 | Level 2 | Comments |
+=========+==========+=========+====================================+
| Type | | | MUST be 5 |
+---------+----------+---------+------------------------------------+
| | Name | | |
+---------+----------+---------+------------------------------------+
| | | Generic | trust domain id |
+---------+----------+---------+------------------------------------+
| | | Generic | descriptive collection name |
+---------+----------+---------+------------------------------------+
| | | Generic | collection state (sender's view) |
+---------+----------+---------+------------------------------------+
| | Nonce | | uniquely distinguishes this |
| | | | cState |
+---------+----------+---------+------------------------------------+
| | Lifetime | | expiry time (ms after arrival) |
+---------+----------+---------+------------------------------------+
Table 2: cState format
A cState is valid if it starts with the correct TLV and it contains
the three required Level 1 TLVs in the right order (top-down in
Table 2) and nothing else. Its Name MUST start with the trust domain
id of the DeftT, then a descriptive Collection name (of at least one
component) and finally a representation of the the state of the
Collection at the originator. There is no signature for a cState
PDU. (The cState format is a restricted subset of an NDNv3
Interest.)
B.4. cAdd
A cAdd PDU is used to add Publications to a collection and carries
Publications as Content. A cAdd PDU is created after a cState is
received and only if the recipient has Publications that are not
reflected in the recipient's local state. A cAdd is valid if it
starts with the correct TLV, contains the five required Level 1 TLVs
in the right order (top-down in Table 3) and nothing else. A cAdd
name is identical to the cState to which it responds.
Nichols, et al. Expires 24 May 2023 [Page 42]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
+=======+================+================+=======================+
| Level | Level 1 | Level 2 | Comments |
| 0 | | | |
+=======+================+================+=======================+
| Type | | | MUST be 6 |
+-------+----------------+----------------+-----------------------+
| | Name | | MUST match Name of |
| | | | cState it's adding to |
+-------+----------------+----------------+-----------------------+
| | MetaInfo | | |
+-------+----------------+----------------+-----------------------+
| | | ContentType | MUST be type cAdd |
+-------+----------------+----------------+-----------------------+
| | Content | | |
+-------+----------------+----------------+-----------------------+
| | | Publication(s) | one or more |
| | | | Publications to add |
| | | | to the Collection |
+-------+----------------+----------------+-----------------------+
| | SignatureInfo | | |
+-------+----------------+----------------+-----------------------+
| | | SignatureType | Value indicates which |
| | | | signature manager |
+-------+----------------+----------------+-----------------------+
| | | KeyLocator | Presence depends on |
| | | | SignatureType |
+-------+----------------+----------------+-----------------------+
| | SignatureValue | | Value holds the |
| | | | signature for this |
| | | | PDU |
+-------+----------------+----------------+-----------------------+
Table 3: cAdd format
Contributors
Lixia Zhang
UCLA
Email: lixia@cs.ucla.edu
Roger Jungerman
Operant Networks Inc.
Roger contributed much to Section 3.
Nichols, et al. Expires 24 May 2023 [Page 43]
Internet-Draft Defined-Trust Transport (DeftT) November 2022
Authors' Addresses
Kathleen Nichols
Pollere LLC
Email: nichols@pollere.net
Van Jacobson
UCLA
Email: vanj@cs.ucla.edu
Randy King
Operant Networks Inc.
Email: randy.king@operantnetworks.com
Nichols, et al. Expires 24 May 2023 [Page 44]