Internet DRAFT - draft-nichols-tsv-defined-trust-transport
draft-nichols-tsv-defined-trust-transport
Network Working Group K. Nichols
Internet-Draft Pollere LLC
Intended status: Informational V. Jacobson
Expires: 12 January 2023 UCLA
R. King
Operant Networks Inc.
11 July 2022
Defined-Trust Transport (DeftT) Protocol for Limited Domains
draft-nichols-tsv-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 12 January 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 12 January 2023 [Page 1]
Internet-Draft Defined-Trust Transport (DeftT) July 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. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 9
3. DeftT and Defined-trust Communications . . . . . . . . . . . 11
3.1. DeftT role in application communications . . . . . . . . 12
3.2. Information movement is based on trust rules . . . . . . 13
3.3. Relays extend a trust domain . . . . . . . . . . . . . . 14
3.4. DeftT and congestion control . . . . . . . . . . . . . . 15
3.5. Defined-trust management . . . . . . . . . . . . . . . . 16
3.5.1. About trust schemas . . . . . . . . . . . . . . . . . 16
3.5.2. A language for DeftT trust schemas . . . . . . . . . 18
3.6. DC certificates and identity bundles . . . . . . . . . . 21
3.6.1. About DC certificates . . . . . . . . . . . . . . . . 21
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Secure Industrial IoT . . . . . . . . . . . . . . . . . . 23
4.2. Secure access to Distributed Energy Resources (DER) . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Normative References . . . . . . . . . . . . . . . . . . . . 29
8. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. DeftT run-time modules . . . . . . . . . . . . . . . 36
A.1. Syncps set reconciliation . . . . . . . . . . . . . . . . 37
A.2. SchemaLib trust management . . . . . . . . . . . . . . . 38
A.3. Signature managers . . . . . . . . . . . . . . . . . . . 38
A.4. Distributors . . . . . . . . . . . . . . . . . . . . . . 39
A.5. Faces . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.6. Shims . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Formats . . . . . . . . . . . . . . . . . . . . . . 42
B.1. Publications . . . . . . . . . . . . . . . . . . . . . . 42
B.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 44
B.3. cState . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4. cAdd . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
Nichols, et al. Expires 12 January 2023 [Page 2]
Internet-Draft Defined-Trust Transport (DeftT) July 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 IoT (IIoT) 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
data "phone calls" 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 (devices such as sensors only
exist to communicate). Since OT's function is coordination and
control, communication is many-to-many, not two-party. As
Section 1.2 notes, implementing many-many over two-party changes the
configuration burden and traffic scaling from the native media's
O(_n_) to O(_n_^2). Also, OT devices have specific, highly
prescribed roles with strict constraints on "who can say what to
which". The opacity of modern encrypted two-party connections can
make it impossible to enforce or even audit these constraints.
Nichols, et al. Expires 12 January 2023 [Page 3]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
This memo describes a new, open 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 (specifically IPv6 link-local[RFC4291]),
distributed set reconciliation PDU transport, a flexible application-
level pub/sub, and a declarative language used to define the local
context and communication constraints of a deployment. The language
is compiled into a compact, optimized _trust schema_ used by DeftT's
runtime trust management engine to enforce adherence to the
constraints. The resulting system is both efficient and scalable:
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 one
or more _identity bundles_, each containing a signing (identity)
certificate plus secret key together with all the certs in the
identity's signing chain and the trust schema that governs what the
identity can say and hear. All signing chains share a common trust
root so the bundle suffices for the device to authenticate and
authorize communication from peers and vice-versa. Thus new entities
can be added without changes to the existing members and, since an OT
system's "who says what to which" communication patterns are
constraints, the trust schema can subsume all the 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 overwhelmingly prefer radio as a communication medium.
Use of wires is impossible in many installations (untethered Things,
adding smart 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 costs $0.13 in small quantities while the estimated
cost of pulling cable to retrofit nuclear power plants is $2000/ft
[NPPI].
OT communications are frequently local with a many-to-many
communication pattern using application-specific identifiers
("topics") for rendezvous. This fits the generic Publish/Subscribe
communications model and, as table 1 in [PRAG] shows, nine of the
eleven most widely used IoT protocols use a topic-based pub/sub
transport. For example MQTT, an open standard developed in 1999 to
Nichols, et al. Expires 12 January 2023 [Page 4]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
monitor oil pipelines over satellite [MQTT][MHST], is now probably
the most widely used IoT protocol (https://mqtt.org/use-cases/
(https://mqtt.org/use-cases/)). In addition to providing local pub/
sub in buildings, factories and homes, Microsoft Azure, Amazon AWS,
Google Cloud, and Cloudflare all offer hosted MQTT brokers for
collecting and connecting sensor and control data.
Pub/sub protocols are not connection or session oriented but instead
organized around publishing and subscribing to topics. To
communicate, publishers and subscribers need to use the same topic
but need no knowledge of one another. IoT pub/sub is typically
implemented as an application layer protocol over an Internet
transport like TCP or TLS. These endpoint-based transport protocols
do require in-advance configuration of peer addresses and credentials
at each endpoint.
1.2. Transporting information
The smart lighting example of Figure 1 shows a topic-based publish/
subscribe application layer protocol and a wireless broadcast domain.
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 message published by the switch is
heard by all nine devices. IPv6 multicast provides a network layer
that can take advantage of this but current IP transport protocols
cannot. Instead, each switch needs to establish nine 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
Nichols, et al. Expires 12 January 2023 [Page 5]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
commands to topic kitchen/counter, topic kitchen or all. The kitchen
counter light uses its broker session to subscribe to those same
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. The 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.
(Artwork only available as svg: iotMQTT-rfc.svg)
Figure 2: Brokers enable Pub/Sub over connection/session protocols
A transport protocol not organized around bilateral associations
("connections") would better suit this problem. In the distributed
systems literature, communication associated with coordinating shared
objectives has long been modeled by the mathematics of distributed
set reconciliation. In this approach, the domain of discourse is
some named set, e.g., _myhouse.iot_, the event created by a button
press on a switch is added as a new object to the instance of
_myhouse.iot_ at its point of origin, then the reconciliation process
ensures that every entity holding _myhouse.iot_ has the same set of
objects by propagating this new object. Recent progress in
distributed set reconciliation via Invertible Bloom Lookup Tables
(IBLTs) [DIFF][IBLT][MPSR] enables solution of this problem by a
simple, efficient multicast transport. DeftT implements IBLT set
reconciliation and takes advantage of IPv6's ability to use link
local multicast without requiring manual configuration or a routing
agent, yielding 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.
Nichols, et al. Expires 12 January 2023 [Page 6]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
1.3. Securing information
In addition to reliability, current transport protocols provide some
security via encrypting the sessions between end points. In the
Internet, trust in the credentials of an endpoint (e.g., a website)
is usually attested by a third party certificate authority (CA) and
is bound to a DNS name. Each secure transport association requires
the exchange of these credentials. Instead of third party
certificates, OT tends to prefer locally created certificates,
configuring them into on-device trusted enclaves [TPM][HSE][ATZ] as
part of the device enrollment process. Thus, a transport for OT
should work with a local root of trust. In Figure 2 each connection
is a separate security association where each device needs to
validate the broker's credential and the broker has to validate each
device's (the validity check usually involves cryptographic
verification of a signature chain terminating on a common trust
root). This approach ensures that transport associations are between
two enrolled devices (protecting against outsider and some MITM
attacks) and allows for secure exchange of a nonce symmetric key that
can be used to ensure transport privacy. However, once transport has
been established there are no constraints whatsoever on what devices
can say. Thus this type of security does not protect against the
insider attacks that currently plague OT, e.g., [CHPT] description of
a lightbulb taking over a network. Hardening an OT system against
these attacks requires trust management operating at the individual
publication level, not the connection or session level. 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
smart light APIs. Once the session is established, its security
handles the "fwupd" publications the same way as the "on/off"
publications. Per-publication trust decisions can enable the fwupd
from the light switch to be rejected.
The requirement for per-publication trust decisions combined with
OT's preponderance of many-to-many communications over broadcast
infrastructure suggests that per-publication signing is preferable to
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
results in 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. If, as described in
[DLOG], the system's trust requirements are expressed using a
_declarative_ framework, they can be validated for consistency and
completeness then converted to a compact runtime form which can be
Nichols, et al. Expires 12 January 2023 [Page 7]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
authorized and secured via signing with the system trust anchor, then
distributed, validated and updated using the same mechanisms used for
identity certificates. This trust schema can be used both to
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.
OT communication maps well to pub/sub because it consists of
independent messages that, due to interoperability requirements,
conform to rigid standards on syntax and semantics
[IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL]. Using
conventional session-based transports combines these independent
publications under a single session key. Moving to a publication-
based transport makes it possible to embed 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 style of trust management extends LangSec's [LANG] "be definite
in what you accept" principle by using the authenticated common
ruleset for belt-and-suspenders enforcement by both ends of the
transport: If the trust schema shows the publication builder it
doesn't have the credentials needed to produce a valid publication,
an error is thrown and nothing is published. Independently, if the
publication validator doesn't have a locally validated, complete
signing chain for the credential that signed some pub, the schema
shows the signing chain isn't appropriate to the pub, or the pub's
signature doesn't validate, the pub is ignored. Since an app's
subscriptions determine the pubs it will see, only certs of chains
that sign pubs 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. And,
unlike most 'secure' systems, adding additional trust schema
constraints to reduce attack surface results in devices doing _less_
work.
Nichols, et al. Expires 12 January 2023 [Page 8]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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.
1.4. Current status
An open-source Defined-trust Communications Toolkit [DCT] with a
reference implementation of DeftT is maintained by the corresponding
author's company, Pollere. Pollere is also working on home IoT uses.
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 and Operant welcome collaborators with problems
suitable for DeftT.
[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 domains. As the needs of our use cases expand,
the Defined-trust Communications (DC) architecture will evolve.
Working implementations and performance improvements are occasionally
added to the repository. This reflects the development philosophy of
DC to start from solving useful problems with a well-defined scope
and extend from there. DeftT's reference implementation 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.
2. 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
Nichols, et al. Expires 12 January 2023 [Page 9]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
* 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: 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.
* trust anchor: 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.
* signing identity: a unique signing certificate of a particular
entity that is the leaf of a certificate chain that terminates in
the local root of trust. Certificates in the chain contain role
and capability information thus signing identities are distributed
with their chain-of-trust
* capabilities: certificates that contain attributes of a signing
identity and are part of the identity's chain-of-trust as defined
in a trust schema
* certificate thumbprint: the 32 byte SHA256 digest of the entire
signing cert 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): (following the wikiPedia definition) a
single unit of information transmitted among peer entities of a
computer network composed of protocol-specific control information
and user data
Nichols, et al. Expires 12 January 2023 [Page 10]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
* 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
* collection: a set of elements denoted by structured names
including 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
3. DeftT and Defined-trust Communications
DeftT synchronizes and secures communications between enrolled
entities 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. DeftT's set reconciliation
communication model 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 (sets) are
denoted by structured names including the identifier of a particular
trust schema. Communicating DeftTs may hold different subsets of the
collection at any time (e.g., immediately after entities add elements
to the collection) but the protocol ensures they all converge to
holding the complete set of elements within a few round-trip-times
following the changes.
Nichols, et al. Expires 12 January 2023 [Page 11]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
3.1. DeftT role in application communications
DeftT's security enforces "who can say what to which" as well as
providing required integrity, authenticity and confidentiality.
Applications use DeftT to add to and access from a distributed
collection of Publications. Transparently to applications, a DeftT
instance both constructs and validates all Publications against a set
of formal, validated rules. Each new DeftT is configured with these
rules in certificate form along with a signing chain that includes
its private signing identity and has the same root of trust as the
certificate of trust rules. A DeftT is identified by its signing
identity and the role and capabilities in that identity's signing
chain. Each DeftT must add its credentials (signing chain) to a
certificate collection prior to adding publications to the
collection. DeftT validates credentials as a chain of trust against
the shared trust rules and does not accept Publications without a
fully validated signer identity.
Communicating DeftTs must be in the same _trust domain_ (TD), i.e.,
identities derive from the same root of trust and follow an identical
trust schema. Using this shared set of rules, DeftT provides fully
distributed policy enforcement for the TD without relying on a
secured-perimeter physical network and/or extensive per-device
configuration. Trust schemas are distributed as a trust-root-signed
certificate and that certificate's thumbprint uniquely identifies a
TD in DeftT PDUs. 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 that flows in and out of a DeftT instance.
An application-specific format is used for information exchanged with
an application. DeftT uses its trust schema to turn this information
into Publications that it adds to its set (_sync_ collection). DeftT
implements two types of transport PDU, both broadcast on its subnet,
that it uses to manage the set. One represents the _collection
state_ (cState) of one or more DeftTs by an IBLT that contains all
the Publications the DeftT currently has in its collection. The
cState serves as a query for additional data that isn't reflected in
its local state. The other PDU carries the _collection additions_
(cAdds) that are sent in response to a cState. Reception of a cAdd
with new data responds to a particular cState so a receiving DeftT
removes that cState as a pending query (it will be replaced with a
new cState with the addition of the new items). DeftT requires and
implements signing and validation of publications as well as the cAdd
Nichols, et al. Expires 12 January 2023 [Page 12]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
PDUs that transport them. As these dynamics are exactly that of
Named-Data Networking's Interest (cState) and Data (cAdd) packets,
the DeftT reference implementation uses a restricted subset of that
format for its PDUs along with its own broadcast-optimized Face
protocol. (DeftT does not utilize a NDN forwarder or implement the
full NDN protocol.)
Any DeftT that is missing a Publication (due to being out-of-range or
asleep, etc.) can receive it from any other DeftT. The
reconciliation protocol 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. DeftT's reference implementation includes an efficient
multicast-optimized approach.
3.2. Information movement is based on trust rules
The Internet's transport and routing protocols emphasize universal
reachability and packet forwarding is based on destination. A
significant number of uses neither need nor desire to transit the
Internet. For a wide class of OT applications, depending on the good
sending practices of others while accepting packets has left critical
applications open to misconfiguration and attacks. DC only moves its
Publications if they follow trust rules, an approach that differs
from Internet forwarding but offers new opportunities.
DeftTs on the same subnet may not be in the same trust domain (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 certificate holding the
domain's trust rules) 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 separate sync zones while preserving a trust
domain for the publications. A relay is an application running on a
device with a network interface on each subnet that has two or more
DeftT instances. Each DeftT participates in a different sync zone
and has a signing identity valid for its sync zone. Each subnet's
DeftT uses the same trust rules to validate Publications and those
that arrive via one DeftT are added to the collections of all other
DeftTs of the relay (after validation). Only Publications are
relayed between subnets and the Publication must match a trust rule
in the DeftT's trust engine. (Note that cAdd encryption is unique
per subnet/sync collection.)
Nichols, et al. Expires 12 January 2023 [Page 13]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
3.3. Relays extend a trust domain
Relay DeftTs use a special API module (a "shim", see Appendix A.6)
that performs "pass-through" of valid Publications rather than
creating Publications. The relay of Figure 5-left has three separate
wireless subnets. If all three DeftTs use the same trust schema, a
new validated cert added to the cert store of one DeftT is passed to
the other two, which 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 by one
DeftT, it is passed to the other two DeftTs to validate against their
trust schema copies and published if it passes.
(Artwork only available as svg: relayextend-rfc.svg)
Figure 5: Relays connect subnets
Relays can also connect subsets of a TD, either proper subsets or
overlapping subsets. A relay may have different identities and trust
schemas for each of its DeftT but must have the same trust anchor.
Publications that are undefined for a particular DeftT will not pass
its validation and will be silently discarded. 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 ruleset. If the added efficiency of filtering
Publications prior to validation checks is desired, a relay can be
altered to limit subscriptions (a one-line change) on some DeftT(s)
or may add code to filter Publications before passing to other
DeftT(s). Figure 5-right shows extending a trust domain
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 networks. Everything on each local network shows
up on the other. A TD subset 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 networks 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 4.
Nichols, et al. Expires 12 January 2023 [Page 14]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
3.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 an app-level _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
(or NDN NFD forwarding mesh?) 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 described in the
previous section.
DeftT will send _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 app-level publication rate. As described in
Section 3.1, instances publish a cState specifying the set elements
they currently hold. If an instance receives a cState specifying the
same elements 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.
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 PDU but their congestion
control is handled by TCP or QUIC.
Nichols, et al. Expires 12 January 2023 [Page 15]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
3.5. Defined-trust management
OT applications are distinguished (from general digital
communications) by well-defined roles, behaviors and relationships
that constrain the information to be communicated. Structured
abstract profiles characterize the capabilities and attributes of
Things and can be machine-readable. 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]. These
structured profiles and rules strictly define permitted behaviors
including what types of messages can be issued or acted on; undefined
behaviors should not be permitted. DC can incorporate these rules
along with local configuration directly into the trust schemas used
in DeftT's integrated trust management engine. 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.
DeftT's trust engine modules use trust schemas which are compiled
into a binary format to become the content of a certificate signed by
the trust domain's root of trust. The trust schema contains the
defined rules that describe the format of PDUs and the specific roles
and credentials that must be in the signing chain of entities that
create them. Defined-trust Communications includes the use of trust
schemas, a language for expressing the trust schemas, and the use of
a compiler and other tools to create the credentials a DeftT needs at
run-time to function in a particular TD.
3.5.1. About trust schemas
Defined-trust communications formalizes the rules governing
communications in _trust schemas_. Trust schemas grew out of early
work in CCN [SNC] which in turn was partially based on the seminal
SDSI [SDSI] approach to create user-friendly namespaces creating
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. [CRTMG] proposed using
locally controlled and administered secure identities that were
verifiable at each (routing) process to provide a key management
structure for intradomain IP routing. Blaze et. al. [DTM] defined
the term _trust management_ for the study of security policies,
security credentials, and trust relationships. Li et. al. [DLOG]
later refines some trust management concepts arguing that the
expressive language for the rules should be declarative (as opposed
Nichols, et al. Expires 12 January 2023 [Page 16]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
to the original work). This body of work influences that of trust
schemas, which allow for specifying security rules based on
application name structures. 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
packet that the application produces or consumes" and gave a general
description of how trust schema rules might be used by an
authenticating interpreter finite state machine to apply the rules to
packets, only addressing validation.
A new approach to both the trust schema language and the integration
of trust schemas with applications was introduced in [NDNW], extended
in [DNMP][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 p.4, 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 Defined-trust Communications and
an implementation (VerSec) is included with the Defined-trust
Communications 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. In the reference implementation [DCT], these objects are
called "publications" and have names, content and signatures (using a
restricted subset of NDN Data packets, covered in Appendix B).
Certificates are a type of publication, allowing them to be
distributed and validated using DeftT, but they are subject to many
additional constraints (Section 3.6.1,Appendix B.2) that ensure
DeftT's security framework is well-founded.
Nichols, et al. Expires 12 January 2023 [Page 17]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
3.5.2. A language for DeftT trust schemas
The language follows LangSec [LANG] principles to minimize
misconfiguration and attack surface. It has a structure amenable to
a forms-based input or a translator from structured data
descriptions. Declarative languages are expressive and strongly
typed, so they can express the constructs in these standards in the
trust schema. Versec continues to evolve to add new features as we
expand our application domains 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.
Defined-trust Communications makes the rules of trust available to
every entity. A trust schema 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". For application domains where the
communicating entities share an administrative control, using a third
party to certify identity is unnecessary and can introduce
vulnerability. Defined-trust Communications 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 for every deployed entity.
A trust schema details the meaning and relationship of individual
components of the filename-like names (URI syntax RFC3986) of
publications and certificates. A simple trust schema (Figure 6)
defines a publication of this trust domain as #pub with a six
component name. The strings between the slashes are the tags used to
reference each component in the structure form 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." #pubPrefix is designated as this single component
(though multiple components are permitted) so that the trust schema
contains information on what part of the name is considered common
prefix. The Figure 6 trust schema puts no constraints on other name
components (not the usual case for OT applications) but does require
that Publications of template #pub are signed by ("<=") a roleCert
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. The trust domain defined by 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) but
must sign all Publication using the EdDSA algorithm and the
Nichols, et al. Expires 12 January 2023 [Page 18]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
Collection synchronization module must sign all cAdds using the EdDSA
algorithm. Entity identity comes from a roleCert (including private
key) which allows it to create legal communications. The signing
certificate MUST adhere to the trust schema and Publications or cAdds
with unknown signers are discarded. The timestamp component can be
used to prevent replay attacks. DeftT is structured to add its
identity (public) certs to a trust domain's certificate collection
(see {#certificates)) when instantiated, making its identity
available to all other entities in the trust domain. This approach
means entities 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() } <= roleCert
roleCert: _domain/_role/_roleId/_keyinfo <= netCert
netCert: _domain/_keyinfo
#pubPrefix: _domain
#pubValidator: "EdDSA"
#cAddValidator: "EdDSA"
_domain: "example"
_keyinfo: "KEY"/_/"dct"/_
Figure 6: An example trust schema
To keep the trust schema both compact and secure, it is compiled into
a binary format that is the content of a trust schema certificate.
[DCT] contains a compiler (schemaCompile) that converts the text
version (e.g. Figure 6) of the trust schema into a binary output
file as well as diagnostic output (see Figure 7) used to confirm the
intent of the trust rules (and which will flag problems). Entities
are configured with the trust domain's trust anchor, the trust schema
and their own identity in the trust domain. From these elements, any
other TD member's credentials can be verified, so no entity has
apriori knowledge of any other entity. Device configuration should
be carried out using appropriate applicable best practices
[TATT][DMR][IAWS][TPM][RFC8995].
Nichols, et al. Expires 12 January 2023 [Page 19]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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 roleCert: /"example"/_role/_roleId/"KEY"/_/"dct"/_
cert netCert: /"example"/"KEY"/_/"dct"/_
binary schema is 301 bytes
Figure 7: schemaCompile diagnostic output for example of Figure 6
This simple trust schema provides useful security, using identities
both to constrain communications actions (via strict format of
communications) and to convey membership. To increase security, more
detail can be added to the trust schema of Figure 6. For example,
different types of roles can be created, here "admin" and "sensor",
and communications privacy can added by specifying AEAD Validator to
encrypt cAdds. To make those roles meaningful, role-specific
publications can be defined such that only admins can issue commands
and only sensors can issue status. Specifying the AEAD validator
means that at least one entity in the trust domain will need the key
maker capability in its signing chain and here that capability is put
in the signing chain of all sensors. WIth AEAD specified, a key
maker is elected during instantiation of DeftT 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 application code
nor binary needs to change and 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: roleCert & { _role: "admin" } <= netCert
sensorCert: roleCert & { _role: "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"
Nichols, et al. Expires 12 January 2023 [Page 20]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
Figure 8: Enhancing security in the example trust schema
Converting desired behavioral structure into a trust schema is the
major task of implementing Defined-trust Communications for an
application domain. Once completed, all the deployment information
is contained in a trust schema, which makes an application writer's
job much easier. Although a particular trust schema cert defines a
particular trust domain, the text version of a trust schema can be
re-used for related applications. For example, a home IoT trust
schema could be edited to be specific to a particular home network or
a solar rooftop neighborhood and then signed with a chosen trust
anchor.
3.6. DC certificates and identity bundles
To participate in a trust domain, an entity needs the domain's trust
anchor, signed trust schema cert and an identity signing cert (public
key cert that includes private key) complete with its signing chain
(public certs only) terminating at the zone's trust anchor. The
public signing certs of other entities are obtained and validated
(using the common trust schema and anchor) at run-time and as
entities join. Well-formed certificates and identity bundle
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.
3.6.1. About DC certificates
As previously noted, use of third party 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 a SDSI-like architecture with a single, local, trust root
cert (trust anchor) simplifies trust management and avoids the well-
known certificate authority (CA) federation and delegation issues
(there are no CAs; just the local trust anchor) and other weaknesses
of the X.509 architecture (summarized at [W509], original references
include [RSK][NVR]). DC certs (see {#certificates)) 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 cert's one and only Subject Name is the name of the
Publication that contains the cert as its content and neither name
nor content are allowed to contain any optional information or
extensions. Signing identities are granted roles and capabilities in
a trust schema by the certs that appear in their chain of trust.
All 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
Nichols, et al. Expires 12 January 2023 [Page 21]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
attack surface associated with certificate revocation lists (CRLs) or
use of on-line certificate status protocol (OSCP). Key roles 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 entities from a trust
domain, there are a variety of options. The most expedient is via
use of the AEAD Validator by ensuring that the group key maker(s) for
a trust domain exclude that entity from subsequent symmetric key
distributions. It is also possible to distribute a new trust schema
and signing identities (without changing the trust anchor) using
remote attestation via the TPM.
3.6.1.1. Identity bundles
Identity bundles hold the certificates an entity's DeftT needs to
participate in a trust domain: trust anchor, trust schema, and certs
in the signing identity chain of trust. 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 into a network 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
[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., [CIOT]. In deployment [maybe point to Use Case?], a
small application manager is programmed for two specific purposes.
First, it is registered with a supervisor [SPRV] (or similar process
Nichols, et al. Expires 12 January 2023 [Page 22]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
control) for its own (re)start to serve as a bootstrap for the
application entity. 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 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. The entity's 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 app that's going to use them
thus can easily be refreshed at need. Trust anchors, trust schema,
and the secured signing identity are higher value and often require
gereation 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 requires
liftetimes of weeks to years. Updating trust schemas and other
certificates over the deployed network 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.
4. Use Cases
4.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
particularly an 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
Nichols, et al. Expires 12 January 2023 [Page 23]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
outages due to shielding walls and interference caused by rotating
machinery and electrical generators. Resiliency through the use of
multiple gateway devices, that can receive sensor information and
transmit to monitor/controllers and servers, can be used to create a
robust architecture. Gateways that use DeftT can form a robust
wireless mesh that is resilient against transmission outages,
facilitating reliability. DeftT forms meshes with no additional
configuration as Publications missing from one DeftT's set can be
supplied by another within range. Several gateways are typically
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
Nichols, et al. Expires 12 January 2023 [Page 24]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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
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, 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.
4.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 point-point TLS
connections 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.
Nichols, et al. Expires 12 January 2023 [Page 25]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
* 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
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.
Nichols, et al. Expires 12 January 2023 [Page 26]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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.
5. Security Considerations
Security of data in the application space is out-of-scope for this
document. This document covers a transport protocol that secures the
information it conveys (COMSEC in the language of [RFC3552]).
Security of DeftT's code is out-of-scope for this document. 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). In the event that modifications of a device's software/
firmware by unauthorized usage is of concern, a trusted execution
environment such as ARM's TrustZone should be employed. As show in
{#fig3}, DeftT has been designed to accomodate this: all of the DeftT
code and data is on the right side of the diagram and reachable
_only_ via two narrow API calls, Publish and Subscribe. The code and
data could easily be put in a secure zone reachable only via
callgates for each API call.
Providing crypto functions is out-of-scope of this document. The
reference 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. There are a range of
solutions available and selection of one can be application-
dependent. 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].
DeftT's unit of information transfer is a Publication. It is an
atomic unit sized to fit in a lower layer transport PDU
(fragmentation and reassembly are done above DeftT if necessary).
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 sync protocol identifies Publications using a hash of
the entire Publication, including its signature. A sync collection
Nichols, et al. Expires 12 January 2023 [Page 27]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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. 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.
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.
Nichols, et al. Expires 12 January 2023 [Page 28]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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 public root of trust, a certificate
of the trust schema signed by the trust root, and its own signing
identity chain with a private signing key and the chain signed at top
by trust root. This is published 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 available. Certificates are distributed
using integrity signing only since they are validated via chain of
trust. 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.
The reference encryption modules 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 entity can resend a Publication from any other entity
(without modification) so group encryption (in effect, group signing)
is no different. Some other encryption approaches are provided whose
potential vulnerabilities are described in the code headers and a
signed, encrypted approach is also available.
6. IANA Considerations
This document has no IANA actions.
7. Normative References
Nichols, et al. Expires 12 January 2023 [Page 29]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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>.
[CBIS] Jacobson, V., Braynard, R., Diebert, T., Mahadevan, P.,
Mosko, M., Briggs, N. H., Barber, S., Plass, M. F., Solis,
I., Uzun, E., Lee, B., Jang, M., Byun, D., Smetters, D.
K., and J. D. Thornton, "Custodian-based information
sharing", 2012,
<https://doi.org/10.1109/MCOM.2012.6231277>.
[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>.
[CIDS] OperantNetworks, "Cybersecurity Intrusion Detection System
for Large-Scale Solar Field Networks", 2021,
<https://www.sbir.gov/sbirsearch/detail/2104327>.
[CIOT] Lydersen, L., "Commissioning Methods for IoT", February
2019,
<https://www.silabs.com/documents/public/presentations/ew-
2019-iot-security-commissioning-methods-for-iot.pdf>.
[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>.
Nichols, et al. Expires 12 January 2023 [Page 30]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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>.
[CRTMG] Nichols, K., "Certificate-managed Secure Identity,
proposal to Department of Homeland Security for topic
H-SB010.2.003", June 2010,
<http://pollere.net/Pdfdocs/1021103-technical_only.pdf>.
[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/>.
[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>.
Nichols, et al. Expires 12 January 2023 [Page 31]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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>.
[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>.
Nichols, et al. Expires 12 January 2023 [Page 32]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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/>.
[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>.
Nichols, et al. Expires 12 January 2023 [Page 33]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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>.
[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>.
[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.
Nichols, et al. Expires 12 January 2023 [Page 34]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
[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>.
[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>.
[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>.
[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 12 January 2023 [Page 35]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
Appendix A. DeftT run-time modules
DeftT's required functionality is broken into modules that have been
implemented in libraries in the reference implementation [DCT].
Extensions and alternate module implementations are possible but the
functionality and interfaces must be preserved. 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. In
particular, 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 12 shows the DC modules which are organized in libraries in
the DCT reference implementation. 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.
Where there are alternatives, a DeftT's 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 12: Run-time 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 although new signature managers, distributors,
and Face modules may be added to the library to extend features.
Nichols, et al. Expires 12 January 2023 [Page 36]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
A.1. Syncps set reconciliation
Syncps has roots in the sync protocols developed for Information-
Centric Networking, e.g., [CBIS], over the past decade. A DC sync
protocol MUST provide mechanisms that are end-point agnostic, be
broadcast-friendly, and have an efficient implementation. Syncps has
been in development to meet these needs for some time, starting with
the first version (covered in [DNMP]). It currently appears that
syncps is the only sync protocol DC needs so discussion of the sync
protocol module is explicitly syncps. Future uses and research
developments may lead to new sync protocols suitable for DC but they
must fulfill the same role and provide the same interfaces as syncps.
The sync module performs set reconciliation over the Publications of
a Collection, providing the enabling protocol for any-to-any
communications. A single syncps instance manages a single
collection. Each syncps announces the Publications it currently has
in its Collection by sending a cState containing an IBLT [IBLT].
IBLTs 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.
Syncps manages both active and inactive Publications to know when and
if to communicate them to peers (though Face) and subscribers (via
upcalls), but it knows nothing about the format or semantics of
Publications. Upcalls from syncps to other modules provide
validation and expiration information for Publications as well as
validation and signing of cAdds. If a cAdd fails to validate, it is
silently discarded. Syncps can confirm that Publications have
reached their collection if an optional callback handler is provided.
This feature piggybacks on normal syncps dynamics, reporting when
that Publication appears in the state summary of some other entity.
As such, it should not be used as a measure of the transmission time
of a Publication.
Syncps keeps its DeftT instance synchronized with the sync zone at
the attached Face. It adds new DeftT-local Publications to the
collection and transfers validated, subscribed Publications to a shim
(or distributor). Syncps creates two PDUs to manage collections: a
cState, which summarizes the current state of its Collection and a
cAdd, used to respond to received cStates with any applicable
Publications (i.e., cAdd carry Publications). Syncps subscribes to
everything in a collection. The Publications that initiate upcalls
can be limited by the shim in setting up subscriptions with syncps.
Nichols, et al. Expires 12 January 2023 [Page 37]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
A.2. SchemaLib trust management
SchemaLib implements the trust management engine of DeftT. It
validates certificates, uses the trust schema, and instantiates the
distributors required by the trust schema.
When a DeftT is instantiated, it is handed its identity bundle which
contains the trust anchor for the trust domain, the particular
(compiled) trust schema for the domain and the signing identity chain
for the DeftT. This component performs validation of these
certificates and they are stored locally. Templates for all the
legal (according the the trust schema and the signing identity)
Publications are created and saved to use whenever a new Publication
is constructed, ensuring its structural validity.
The DeftT's certificate distributor publishes all the public certs in
its chain in order to connect to the collections used by this DeftT.
A DeftT is not connected until a delivery indication has been
received for its identity certificate chain. If information privacy
is required in the trust schema, the distributors for the required
keys are instantiated.
Signing identities published by others are received, validated,
stored and used to create templates for structural validation of
Publications that originate with those signing identities.
A.3. Signature managers
Signature Managers (sigmgrs) implement the signing and validation of
Data (which may include encryption/decryption) selected by the trust
schema for Publications and their cAdd as well as by the particular
signing and validation required by distributors. Use of an
encryption sigmgr requires a group key distributor (see A.5).
Integrity signing and null signing is not available in trust schemas
(i.e., not used to specify Publications or their cAdd) and are only
used in certificate and key distribution.
Six sigmgrs are currently implemented in DCT, supplying the following
signing and validation algorithms:
EdDSA using the DCT identity cert associated with the particular
DeftT
RFC7693 and SHA256: integrity (not available to trust schemas)
AEAD encryption/decryption for an entire sync zone where the key is
created, distributed and updated by the group key distributor. The
key distributor encrypts the group key individually for each valid
Nichols, et al. Expires 12 January 2023 [Page 38]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
signing identity that has been published in the cert Collection
(validated and stored locally). Members are added to the group as
their validated signing identities become known; no members are added
apriori.
PPAEAD is a version of AEAD encryption/decryption where the
encryption key is unique to a particular publisher and the group of
authorized subscribers. Authorized subscribers must have the
required capability in their signing chain and the subscriber group
key pair is distributed by a subscriber group key distributor which
creates (and updates) a key pair for the subscriber group, putting
the public key in the clear and encrypting the secret key for each
subscriber group member. Data can only be decrypted by authorized
subscribers (subscriber group members).
PPsigned adds EdDSA signing and validation to PPAEAD. Its use is
indicated if there is a need to protect against authorized members of
the subscriber group forging packets from Collection publishers. The
encrypted packet is also signed by the publisher. Uses the same
subscriber group key distributor as PPAEAD.
A.4. Distributors
Distributors manage certificate and key Collections transparently to
applications through their own syncps. A certificate distributor
MUST be provided in order to manage the signing certificate
collection for any application. Its Publications are signing chain
certificates and when a DeftT is first instantiated it is used to
publish the certs of its own signing chain. The cert distributor
must confirm their delivery to the cert Collection (i.e., shows up in
an IBLT summary originated by a different DeftT) before the DeftT
upcalls to the application that it can start communications. The
cert distributor passes subscribed certs to schemaLib where validated
certificates are stored; invalid certificates are silently discarded.
The use of other distributors is dependent on the signature manager
selected. AEAD, PPAEAD, and PPsigned require group key distributors
to manage a key Collection. DCT contains a group key distributor for
AEAD as well as a group key distributor for publisher privacy. These
use the capabilities contained in signing identities to determine
eligibility to be a group's key maker and eligibility to subscribe
(decrypt) Publications in a publisher privacy collection. Key maker
election, key creation (and re-creation), and key distribution are
all handled by the distributors and transparent to the application.
Nichols, et al. Expires 12 January 2023 [Page 39]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
A.5. Faces
Faces translate between the cAdd and cStates of the sync protocol and
the system packet transport used for a particular DeftT instance.
Any packet transport can be used as long as it provides:
* send packet and register callback for received packet
* connect registration callback invoked when packets can be sent or
received
* information callback - MTU is returned
DCT currently implements a broadcast Face that is used with UDP
multicast over IPv6 and a unicast face over UDP or TCP. The DCT Face
derives that of NDN, where cState are Interests and cAdds are Data,
but its structure has been optimized for use on broadcast media and
to interact directly with a sync module, not a forwarder node. The
Face keeps:
* Pending Interest Table (PIT): similar to its use in CCN and NDN,
this is a table of unsatisfied Interests. Interests are removed
when a corresponding Data arrives ("satisfies the Interest") or
the Interest times out (when its lifetime has been exceeded).
* Registered Interest Table (RIT) : this is used to hold the
Interest type that this DeftT can respond to
* Duplicate Interest Table (DIT): is used to keep Interests from
looping (without the need for a spanning tree) and tracks the
Interest plus its nonce. (A cAdd is never sent to the Interface
on which it arrived.)
A.6. Shims
A shim is application-class-specific, converting between application-
meaningful messages and DeftT's Publications. A shim is passed the
salient information about a particular communication and its
application level data unit and uses these to create trust schema
compliant Publications, using knowledge about this application class
and calls to schemaLib modules. A shim parses received Publications
for call back(s) to the application. A shim can be customized to a
particular application (the approach taken in the now-obsolete
[DNMP]) or can provide more general communication models, such as
pub/sub, streaming, request/response.
This latter approach has been used to create a DCT library shim, a
message-based publish/subscribe (MBPS) API whose semantics resemble
MQTT but the protocol is brokerless and collection-secure, unlike
MQTT. MBPS handles breaking application-level messages into trust
schema specified Publications and provides an option for delivery
confirmation to be passed to the application. MBPS has been used for
Nichols, et al. Expires 12 January 2023 [Page 40]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
multiple applications: two examples are in DCT and Operant has used
for other applications. MBPS provides a simple API that hides
network layer and security details and offers two levels of message
QoS: a default unacknowledged delivery and a confirmation that the
publication has reached at least one other member of the collection.
Applications can use the following MBPS methods:
connect(successCB, <opt>failureCB): Performs set up (if any)
necessary to allow communications to start. (e.g., signing key
distribution is carried out). Invokes appropriate callback, success
or failure.publish(msg, args, <opt>confCB): Publishes the given
message content and returns a unique message ID. If a confirmation
callback is included, mbps invokes confCB with an indicator of
success or failure of the message.
subscribe(handler): subscribes to all the topics in the pubs
Collection. A received message's underlying publication(s) is
validated before the handler is invoked. subscribe(topic, handler):
distinguishes application-level subscriptions further by topic
(component(s) of name that mbps will append to the pubPrefix of the
trust schema) and passes a handler to use for a particular topic.
run(): once application set up is finished, this turns over control
to the transport.
The API simplicity is shown in this application snippet:
void msgPubr(mbps &cm, const auto& toSnd) {
//... lines of code to prepare arguments
cm.publish(toSnd, a); //load arguments in a
}
static void msgRecv(mbps &cm, const auto& msg, const msgArgs& a) {
//... do something with msg
}
int main(int argc, char∗ argv[]) {
mbps cm(argv[optind]); // make shim using identity bundle
cm.subscribe(msgRecv);
cm.connect([&cm]() {
... // prepare toSnd
msgPubr(cm, toSnd);
});
cm.run();
}
Nichols, et al. Expires 12 January 2023 [Page 41]
Internet-Draft Defined-Trust Transport (DeftT) July 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).
A restricted version of the NDNv3 TLV encoding is used, with TLV
types from NDN's TLV Type Registry [NDNS]. Publications and cAdds
use a compatible format which allows them to use the same library
signing/validation modules (_sigmgrs_).
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 (Appendix A.3). 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 12 January 2023 [Page 42]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
+=======+================+================+======================+
| Level | Level 1 | Level 2 | Comments |
| 0 | | | |
+=======+================+================+======================+
| Type | | | MUST be Data |
+-------+----------------+----------------+----------------------+
| | Name | | |
+-------+----------------+----------------+----------------------+
| | | Generic (or | trust schema sets |
| | | other) | number of and |
| | | | constraints on these |
+-------+----------------+----------------+----------------------+
| | MetaInfo | | |
+-------+----------------+----------------+----------------------+
| | | ContentType | MUST be type Key or |
| | | | Blob |
+-------+----------------+----------------+----------------------+
| | Content | | arbitrary sequence |
| | | | of bytes including |
| | | | embedded TLVs; MAY |
| | | | have length 0 |
+-------+----------------+----------------+----------------------+
| | SignatureInfo | | |
+-------+----------------+----------------+----------------------+
| | | SignatureType | Value indicates |
| | | | which signature |
| | | | manager |
+-------+----------------+----------------+----------------------+
| | | KeyLocator | Absent for |
| | | | integrity-only |
| | | | signature types |
+-------+----------------+----------------+----------------------+
| | | ValidityPeriod | Only for |
| | | | Certificates |
+-------+----------------+----------------+----------------------+
| | SignatureValue | | Packet signature |
| | | | (format determined |
| | | | by SignatureType) |
+-------+----------------+----------------+----------------------+
| Table: Publication format |
+----------------------------------------------------------------+
Table 1
Nichols, et al. Expires 12 January 2023 [Page 43]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
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
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 an entity 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 to other entities.
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 the Sync (sec A.1)
and Face (sec A.5) modules. Sync 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 12 January 2023 [Page 44]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
+=========+==========+=========+====================================+
| Level 0 | Level 1 | Level 2 | Comments |
+=========+==========+=========+====================================+
| Type | | | MUST be Interest |
+---------+----------+---------+------------------------------------+
| | 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: cState format |
+-------------------------------------------------------------------+
Table 2
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 MUST be identical to the cState to which it responds.
Nichols, et al. Expires 12 January 2023 [Page 45]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
+=======+================+================+========================+
| Level | Level 1 | Level 2 | Comments |
| 0 | | | |
+=======+================+================+========================+
| Type | | | MUST be Data |
+-------+----------------+----------------+------------------------+
| | Name | | |
+-------+----------------+----------------+------------------------+
| | | Generic | trust domain id |
+-------+----------------+----------------+------------------------+
| | | Generic | descriptive collection |
| | | | name |
+-------+----------------+----------------+------------------------+
| | | Generic | collection state (from |
| | | | cState) to which the |
| | | | Content's Publications |
| | | | are to be added |
+-------+----------------+----------------+------------------------+
| | 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: cAdd format |
+------------------------------------------------------------------+
Table 3
Appendix C. Contributors
Roger Jungerman
Operant Networks Inc.
Nichols, et al. Expires 12 January 2023 [Page 46]
Internet-Draft Defined-Trust Transport (DeftT) July 2022
Lixia Zhang
UCLA
Email: lixia@cs.ucla.edu
Roger contributed much of Section 4.
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 12 January 2023 [Page 47]
