Defined-Trust Transport (DeftT) Protocol for Limited Domains
draft-nichols-iotops-defined-trust-transport-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Kathleen Nichols , Van Jacobson , Randy King | ||
| Last updated | 2024-08-15 | ||
| Replaces | draft-nichols-tsv-defined-trust-transport | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Reviews |
IOTDIR Early review
(of
-01)
by Suresh Krishnan
On the right track
|
||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nichols-iotops-defined-trust-transport-07
Network Working Group K. Nichols
Internet-Draft Pollere LLC
Intended status: Informational V. Jacobson
Expires: 16 February 2025 UCLA
R. King
Operant Networks Inc.
15 August 2024
Defined-Trust Transport (DeftT) Protocol for Limited Domains
draft-nichols-iotops-defined-trust-transport-07
Abstract
This document is not an Internet Standards Track specification and
does not enjoy IETF consensus. It is published for examination,
evaluation, and experimentation. The Defined-trust Transport (DeftT)
framework is designed to provide default-deny communications for
certain types of Limited Domains (RFC8799) used for Operational
Technology (OT) networks and, in particular, Critical Infrastructure
networking. DeftT is designed to express and enforce application-
and deployment-specific integrity, authentication, access control and
behavior constraints directly in its protocol modules. It enables
secure and completely self-contained (e.g., no external identity
servers or certificate authorities) overlay networks where
credentialed members can join and leave at any time. Security is not
optional and members preconfigured only with their individual
cryptographically secured identities and the secured communication
rules independently authenticate other members' identities and their
role- and attribute-specific communications.
DeftT is an integrated trust management, multi-party transport that
synchronizes collections of secured information across all members of
its domain. It uses a many-to-many synchronization primitive rather
than source-destination send-and-acknowledgement. Packets are not
routable and information only leaves its originating subnet if it is
both explicitly permitted in the secured rules and there is a member
element (relay) constructed to move validated information containers
across subnets. DeftT provides default deny networking for closed
communities with dynamic membership and a collection-based transport
that is efficient on broadcast media. DeftT is part of a Defined-
trust Communications approach with an example implementation
available. Combined with IPv6 multicast and modern hardware-based
methods for securing keys and code, it can provide a foundation for
secure and efficient communications in Limited Domains, particularaly
in Critical Infrastructure domains.
Nichols, et al. Expires 16 February 2025 [Page 1]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
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 16 February 2025.
Copyright Notice
Copyright (c) 2024 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.
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 . . . . . . . . . . . . . . . . . . . 8
1.2. Transporting information . . . . . . . . . . . . . . . . 9
1.3. Securing information . . . . . . . . . . . . . . . . . . 11
1.4. Defined-trust Communications Domains . . . . . . . . . . 14
1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1. Multicast . . . . . . . . . . . . . . . . . . . . . . 16
1.5.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . 17
1.6. Design rationale . . . . . . . . . . . . . . . . . . . . 17
1.6.1. Making DeftT "well-defined" . . . . . . . . . . . . . 17
1.6.2. Making DeftT "as simple as possible" . . . . . . . . 18
1.7. Current status . . . . . . . . . . . . . . . . . . . . . 19
1.7.1. Performance considerations . . . . . . . . . . . . . 19
1.7.2. Relationship to other approaches . . . . . . . . . . 20
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Nichols, et al. Expires 16 February 2025 [Page 2]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3. DeftT and Defined-trust Communications . . . . . . . . . . . 23
3.1. Inside DeftT . . . . . . . . . . . . . . . . . . . . . . 25
3.2. syncps: a set reconciliation protocol . . . . . . . . . . 26
3.3. DeftT formats . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. Top level container TLVs . . . . . . . . . . . . . . 29
3.3.2. Leaf TLVs . . . . . . . . . . . . . . . . . . . . . . 36
3.3.3. TLV header details . . . . . . . . . . . . . . . . . 37
3.4. Application and network interface . . . . . . . . . . . . 38
3.5. Synchronizing a collection . . . . . . . . . . . . . . . 39
3.6. Distributors . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1. Certificate distributor . . . . . . . . . . . . . . . 41
3.6.2. Group key distributors . . . . . . . . . . . . . . . 41
3.6.3. Other distributors . . . . . . . . . . . . . . . . . 42
3.7. Schema-based information movement . . . . . . . . . . . . 42
3.8. Performance . . . . . . . . . . . . . . . . . . . . . . . 45
3.9. Congestion control . . . . . . . . . . . . . . . . . . . 47
4. Schemas for the Defined-trust management engine . . . . . . . 48
4.1. Communication schemas . . . . . . . . . . . . . . . . . . 49
4.2. VerSec schema description language . . . . . . . . . . . 50
4.2.1. Lexical building blocks . . . . . . . . . . . . . . . 50
4.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 51
4.2.3. Signing Chains . . . . . . . . . . . . . . . . . . . 53
4.2.4. Syntax and Semantics . . . . . . . . . . . . . . . . 53
4.3. Schema examples . . . . . . . . . . . . . . . . . . . . . 54
5. Certificates and identity bundles . . . . . . . . . . . . . . 57
5.1. Obviate CA usage . . . . . . . . . . . . . . . . . . . . 58
5.2. Identity bundles . . . . . . . . . . . . . . . . . . . . 59
6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1. Secure Industrial IoT . . . . . . . . . . . . . . . . . . 61
6.1.1. Meshing without additional configuration . . . . . . 61
6.1.2. Mixed connectivity in a challenging environment . . . 62
6.2. Secure access to Distributed Energy Resources (DER) . . . 64
7. Security Considerations . . . . . . . . . . . . . . . . . . . 65
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.1. Normative References . . . . . . . . . . . . . . . . . . 69
9.2. Informative References . . . . . . . . . . . . . . . . . 69
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction
Decades of success in providing IP connectivity over any physical
media ("IP over everything") has commoditized IP-based
communications, making IP an attractive option for applications that
previously required proprietary or analog connectivity, e.g.,
Internet of Things (IoT), Industrial Control Systems (ICS) and such
Operational Technologies (OT) applications as building automation,
Nichols, et al. Expires 16 February 2025 [Page 3]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
embedded systems, transportation control, connecting controls and
sensors in nuclear power plants [DIGN] and carbon capture monitoring
[IIOT]. The growing use of Distributed Energy Resources (DER) (e.g.,
residential solar, wind farms) has created interest in low cost
commodity networked devices with added features for security,
robustness and low-power operation [MODOT][OPR][CIDS]. While use of
an IP network layer can be a major advance for OT, the features of
Internet transports that have enabled robust global connectivity can
be problematic for secure communications within the Critical
Infrastructure.
Current widely used IP transports create optionally secured one-to-
one sessions between communicating endpoints identified by IP
addresses that are used in their packet headers to traverse routers.
Synchronization of data across a domain is carried out through
multiple two-party transport sessions. Where IP addresses are
augmented with additional identities, they must either be validated
via external servers or _all_ necessary identities must be be
preconfigured in each member during enrollment. For many significant
OT networks, particularly in Critical Infrastructure, use of external
third party servers creates an unacceptable vulnerability. These
networks are under a single administrative authority, have a
membership that is both securely enrolled and dynamic and have a
primary function of coordination and control that is constrained.
Further, the communication patterns of this coordination and control
are frequently many-to-many. DeftT takes advantage of these
characteristics to provide secure communications with dynamic
membership and no external servers.
DeftT's intended use is for communications in constrained versions of
Limited Domains [RFC8799]. As in [RFC8366] a domain is defined as
"The set of entities or infrastructure under common administrative
control." Following RFC 8799, this memo uses the term _Limited
Domain_ to refer to a region where network and end system
requirements, behaviors, and semantics are applied only within a
single domain where membership is assumed to be cryptographically
secured. The region of applicability could be a physical locality,
e.g., within the same building, campus or immediate proximity, or
could be distributed across geographies, as an overlay on the
Internet or as a network parallel to the Internet. This memo uses
_limited_ according to its definition of "restricted" or
"characterized by enforceable limitations." (https://www.merriam-
webster.com/dictionary/limited (https://www.merriam-
webster.com/dictionary/limited)) _Trust domain_ denotes a Limited
Domain where all network communications are via DeftT. Though the
Limited Domain properties and general functional requirements
enumerated in RFC 8799 are necessary, we do not claim they are
sufficient.
Nichols, et al. Expires 16 February 2025 [Page 4]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
DeftT is a multi-party transport that synchronizes collections of
secured information across all enrolled members of a domain using
broadcast when available. This keeps domain communications
synchronized without the need to construct multiple two-party
transport sessions, either between members or with a server or
broker. DeftT relies on secure, dynamic membership where the
credentials of secured identity and communications rules are the
_only_ information needed by a member. DeftT's integrated trust
management uses these to validate other members' identities and
capabilities, to validate received communications both structurally
and cryptographically and to construct compliant outbound
communications. This means that new members can be created and join
a trust domain at any time without the use of external servers (e.g.
certificate authorities, identity servers). DeftT's use and
enforcement of its secure, dynamic _membership_ is described in
subsequent sections of this memo.
Like QUIC, DeftT is a user-space transport protocol that sits between
an application and a system-provided transport like UDP or UDP
multicast (see Figure 1). No UDP or TCP port assignment is required.
Like COAP/OSCORE nodes, DeftT members start with a pre-existing
identity obtained out-of-band, which means that existing and evolving
bootstrap and enrollment protocols and methodologies can be used.
DeftT identities are more than a single key pair signed by a trust
anchor; instead, the identities are in the form of certificate
chains, terminating at the domain's trust anchor (Section 2 and
Section 3.3.1.4) that contain all the attributes and/or the role the
identity is granted. An identity conveys membership in a _specific_
trust domain that is using a _particular_ set of rules and a
_particular_ trust anchor. As with MUD, trust domain members have
specific capabilities and permitted communications that are
explicitly specified. Unlike MUD, each member gets the domain's
rules distributed in binary form in a certificate (a _communication
schema_) signed by the same trust anchor at the root of the identity
chain. This compact and secured _schema_ specifies the format for
identity chains as well as the format of all permitted communications
and the attributes required by identities that issue them.
DeftT enrollment consists of configuring a device with _identity
bundles_ that contain the trust anchor certificate, the communication
schema, and an identity which comprises all the certs in its signing
chain terminated at the trust anchor. The private key corresponding
to the leaf certificate of the member's identity should be securely
configured (i.e., not exposed to any third party) while the security
of the identity bundle can be deployment-specific (i.e., the public
certificates it contains may optionally be protected from third
parties). DeftT's integrated trust management engine applies the
schema at run-time.
Nichols, et al. Expires 16 February 2025 [Page 5]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
An application using DeftT is configured with its credentials before
it starts communications. The SHA256 "thumbprint" Section 2 of the
schema cert is used as a compact, unique identifier for the domain
and portions of this identifier are used to generate addresses in
accordance with the Dynamic Ports of [RFC6335] to determine both the
IPv6 link-local multicast address and UDP destination port (more in
Section 1.5). (Note that UDP multicast requires different ports for
send and receive, so this use doesn't conflict with the normal use of
this range for emphemeral client src ports.) Unicast protocols
require more configuration and the protocol, role (e.g., "listen" or
"connect"), address and port information goes into the identity
chains of the two parties.
(Artwork only available as svg: ./figs/defttlayer-rfc.svg)
Figure 1: DeftT in an IP stack
DeftT's trust domains are self-contained communication domains
layered on IP via multicast UDP or unicast protocols (e.g., TCP and
UDP) and do not directly interact with IP routing protocols. DeftT
deploys on IP networks without interfering with conventional IP
protocols. In contrast with IETF standards track protocols like the
client-server COAP [RFC7252], DeftT is intended to serve the
communication needs of a closed community with common objectives, a
defined-trust Limited Domain (_trust domain_). Foremost among those
needs is the ability to enforce community-specific policy constraints
("who can say what to which"). ABAC (Attribute-Based Access Control)
[NIST] provides a model sufficient to express and enforce these
constraints but a fundamental architectural choice remains to either:
a. Start with Internet-based communication protocols then "harden
them" by layering an ABAC framework on top, or
b. Start with an ABAC framework that verifiably enforces the policy
constraints then augment it with the minimum necessary
communication primitives needed to function in a community's
deployment environment.
Existing IETF protocols use approach (a) and, given how few
enforceable security policies are possible on the open Internet, it's
a reasonable choice. For Limited Domains, approach (a) imports all
the (otherwise unneeded) Internet abstraction maintenance machinery
of DHCP, DNS, CAs (certificate authorities), PDP/PIPs (Policy
Decision Points/Policy Information Points), routing, address plans,
etc. When communication is expressed in terms of Internet
abstractions (e.g., a TLS connection between two IP endpoints), there
needs to be a translation layer to map between these abstractions and
the Domain's entities, requirements and objectives. This machinery
Nichols, et al. Expires 16 February 2025 [Page 6]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
is configuration intensive and recent history has demonstrated that
it's all prime attack surface. As DeftT is specifically aimed at OT
networks with closed membership domains desiring default deny
communications, it can exploit those characteristics and avoid the
security minefield that more general protocols must navigate.
Specifically, such transports must have headers that tell receivers
(including routers) how they should be handled. DeftT's protocol
data units (PDUs) only have meaning in the context of their specific
trust domain. DeftT has been created as a self-contained ABAC
framework where the PEP and PDP are integrated in the transport. The
PIP function is embeded in certificate signing chains, enabling DeftT
to be self-authenticating and self-distributing.
Along with bootstrapped identity bundles, DeftT makes use of both its
synchronized collections and its integrated trust management engine
to securely join a particular Trust Domain. In synchronized
collections, members communicate about their local version of the
collection state and send additions to the collection the other
members are missing. The identity bundle, DeftT's trust management
engine, and a Trust Domain's certificate collection (where members
publish their signing chains) allow new members to join and
communicate with no specific knowledge of other members, thus
obviating labor intensive and error-prone device-to-device
association configuration. The signing key pairs used for
communications are made _locally_ at each entity on whatever rotation
schedule chosen for the application. Private identity keys are not
used for signing DeftT packets, only to sign the public signing
certificate that becomes the leaf certificate of a signing chain.
The identity key can remain within protected hardware like a TPM for
signing while the signing key is used in the communications path as a
tradeoff between the possibility of more exposure vs the need for
speed. (More on certificates and identities in DeftT in Section 3.6
and Section 5.)
DeftT's collections hold Publications (information containers) that
have lifetimes set as appropriate to their use. For example,
Publications that carry application communications are normally
ephemeral, like a UDP or TCP packet, while Publications that carry
certificates have longer lifetimes, on the order of hours or even
months. Collections are synchronized; members compare their local
versions of the collection state and update the collection with
Publications they have that others are missing. On a broadcast
subnet (e.g., using IPv6 link local multicast) updates are sent to
multiple members at once. On a unicast subnet (e.g., UDP) updates
are sent to the other member of the subnet.
Nichols, et al. Expires 16 February 2025 [Page 7]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
A new DeftT joins a Trust Domain using its certificate distributor
module. Figure 2 shows a state diagram of the joining process. The
joining member creates its first signing pair, then constructs a
certificate holding the public signing key and signs it with the
member's private identity key. The joining member adds its signing
chain to its local copy of the cert collection and starts the process
of joining the Trust Domain by publishing its cert collection state
and subscribing to the domain certificate collection. The local
collection state is compared to the received collection state and any
certs that are not already in that received state will be sent on the
network to be added to the domain collection. Note that a new member
will always need to add its identity and signing certs, but other
certificates of the chain may already have been added to the
collection by previously joining members. A DeftT does not consider
itself joined (or "connected to the domain") until it receives a
collection state from the network that contains all of its certs,
indicating that at least one other member will be able to receive its
signed packets. Whether fully joined or not, the cert distributor
receives all certs published on the network, adding them to its local
collection when an entire validated signing chain is received and
updating its local collection state.
(Artwork only available as svg: ./figs/certSD-rfc.svg)
Figure 2: DeftT certificate distributor enables joining Trust Domain
1.1. Environment and use
In DeftT Domains, multipoint communications are enabled through use
of a named collection abstraction and secured by an integrated trust
management engine. DeftT employs IPv6 link-local multicast
[RFC4291], a distributed set reconciliation communications model,
flexible pub/sub APIs, chain-of-trust identities, and secured rules
that define the local context and communication constraints of a
deployment in a declarative language. The set reconciliation
protocol provides reliable communications (see Section 3.2). The
rules are used by DeftT's runtime trust management engine to enforce
adherence to the constraints; together with a shared trust anchor, a
member can validate every other member's identity at runtime. There
is no need for members to have apriori knowledge of one another. The
resulting system is efficient, secure and scalable: communication,
signing and validation costs are constant per-publication,
independent of the richness and complexity of the deployment's
constraints or the number of communicating entites deployed.
Due to physical deployment constraints and the high cost of wiring,
many OT networks preferentially use radio as their communication
medium. Use of wires is impossible in many installations (untethered
Nichols, et al. Expires 16 February 2025 [Page 8]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Things, adding connected devices to home and infrastructure networks,
vehicular uses, etc.). Wiring costs far exceed the cost of current
System-on-Chip Wi-Fi IoT devices and the cost differential is
increasing [WSEN][COST]. For example, the popular ESP32 is a
32bit/320KB SRAM RISC with 60 analog and digital I/O channels plus
complete 802.11b/g/n and bluetooth radios on a 5mm die that consumes
70uW in normal operation. It currently costs $0.13 in small
quantities while the estimated cost of pulling cable to retrofit
nuclear power plants is presently $2000/ft [NPPI].
Many OT networks have communications that are local, have a many-to-
many pattern, and use application-specific identifiers ("topics") for
rendezvous. This fits the generic Publish/Subscribe communications
model ("pub/sub") and, as table 1 in [PRAG] shows, nine of the eleven
most widely used IoT protocols use a topic-based pub/sub transport.
Pub/sub protocols communicate by using the same topic but need no
knowledge of one another. Today, these protocols are typically
_implemented_ as an application layer protocol over a two-party
Internet transports like TCP or TLS which require in-advance
configuration of peer addresses and credentials at each endpoint and
incur unnecessary communications overhead Section 1.2. For example
MQTT, an open standard developed in 1999 to monitor oil pipelines
over satellite [MQTT][MHST], is now likely the most widely used
application communication protocol in IoT (https://mqtt.org/use-
cases/ (https://mqtt.org/use-cases/)). Microsoft Azure, Amazon AWS,
Google Cloud, and Cloudflare all offer hosted MQTT brokers for
collecting and connecting sensor and control data in addition to
providing local pub/sub in buildings, factories and homes.
Implementing many-to-many applications over two-party transport
sessions changes the configuration burden and traffic scaling from
the native media's O(_n_) to O(_n_^2) (see Section 1.2). Further,
the opacity of modern encrypted two-party sessions can make it
impossible to enforce or audit communication policy constraints on OT
devices with specific, highly proscribed roles and strict constraints
on who can say what to which.
1.2. Transporting information
Figure 3 shows a smart lighting example with a topic-based pub/sub
application layer protocol in a wireless broadcast subnet. Each
switch is set up to do triple-duty: one click of its on/off paddle
controls some particular light(s), two clicks control all the lights
in the room, and three clicks control all available lights (five
kitchen plus the four den ceiling). Thus a switch button push may
require a message to as many as nine light devices. On a broadcast
transmission medium each packet sent by the switch is heard by all
nine devices. IPv6 link-level multicast provides a network layer
Nichols, et al. Expires 16 February 2025 [Page 9]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
that can take advantage of this but current IP transport protocols
cannot. Instead, each light switch needs to establish nine bilateral
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: ./figs/iotDeftt-rfc.svg)
Figure 3: Smart lighting use of Pub/Sub
MQTT and other broker-based pub/sub approaches mitigate this by
adding a _broker_ (Figure 4). Each entity makes a single TCP
transport connection with the broker and tells the broker to
subscribe it to topics. Then the kitchen switch uses its single
transport session to publish commands to topic kitchen/counter, topic
kitchen or all. The kitchen counter light uses its broker session to
subscribe to those same three topics. The kitchen ceiling lights
subscribe to topics kitchen ceiling, kitchen and all while den
ceiling lights subscribe to topics den ceiling, den and all. Use of
a broker reduces the configuration burden from O(_n_^2) to O(_n_): 18
transport sessions to 11 for this simple example but for realistic
deployments the reduction is often greater.
There are other advantages: besides their own IP addresses and
identities, devices only need to be configured with those of the
broker. Further, the broker can store messages for temporarily
unavailable devices and use the transport session to confirm the
reception of messages. This approach is popular because the pub/sub
application layer protocol provides an easy-to-use API and the broker
reduces configuration burden while maintaining secure, reliable
delivery and providing short-term in-network storage of messages.
Still the broker implementation doubles the per-device configuration
burden by adding an entity that exists only to implement transport
and traffic still scales as O(_n^2_), e.g., any switch publishing to
all lights results in ten (unicast) message transfers over the wifi
network. Further, the broker introduces a single point of failure
into a network that is richly connected physically.
(Artwork only available as svg: ./figs/iotMQTT-rfc.svg)
Figure 4: Brokers enable Pub/Sub over connection/session protocols
Nichols, et al. Expires 16 February 2025 [Page 10]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Clearly, a transport protocol able to exploit a physical network's
broadcast capabilities would better suit this problem. (Since
unicast is just multicast restricted to peer sets of size 2, a
multicast transport handles all unicast use cases but the converse is
not true.)
More general solutions for this communications paradigm are possible
by moving the view of the problem from message exchange to the
concept of coordinating shared objectives. In the distributed
systems literature, communication associated with coordinating shared
objectives has long been modeled as _distributed set reconciliation_
[WegmanC81][Demers87]. In this approach, each domain of discourse is
a named set, e.g., _myhouse.iot_. Each event or action, e.g., a
switch button press, is added as a new element to the instance of
_myhouse.iot_ at its point of origin then the reconciliation process
ensures that every instance of _myhouse.iot_ has this element. In
2000, [MINSKY03] developed a broadcast-capable set reconciliation
algorithm whose communication cost equaled the set instance
_differences_ (which is optimal) but its polynomial computational
cost impeded adoption. In 2011, [DIFF] used Invertible Bloom Lookup
Tables (IBLTs) [IBLT][MPSR] to create a simple distributed set
reconciliation algorithm providing optimal in both communication and
computational cost. DeftT uses this algorithm (see Section 3.2) and
takes advantage of IPv6's self-configuring link local multicast to
avoid all manual configuration and external dependencies. This
restores the system design to Figure 3 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. (See Section 3.5 to see how members fill in
missing elements.)
1.3. Securing information
When pub/sub is implemented using conventional session-based
transports multiple publications with independent topics and purposes
are combined under a single session key, providing privacy by
encrypting the sessions between endpoints. Credentials of Internet
endpoints (e.g., a website) are usually attested by a third party
certificate authority (CA) and bound to a DNS name. Endpoint
credentials may also be bound to a device by using BRSKI [RFC8995] to
obtain the (local) domain's root certificate then using a TLS
connection to obtain the end-entity (EE) certificate. Each secure
transport association requires the exchange of these credentials
which allows for secure exchange of a nonce symmetric key. For
example, in Figure 4 each transport session is a separate security
association where each device validates the broker's credential and
the broker has to validate each device's. Secured transport
Nichols, et al. Expires 16 February 2025 [Page 11]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
associations are between two enrolled devices (protecting against
outsider and some MITM attacks) but, once the transport session has
been established there are no constraints whatsoever on what devices
can say. Clearly, this does not protect against the insider attacks
that currently plague OT, e.g., [CHPT] description of a lightbulb
taking over a network. For example, the basic function of a light
switch requires that it be allowed to tell a light to turn on or off
but it almost certainly shouldn't be allowed to tell the light to
overwrite its firmware (fwupd), even though "on/off" and "fwupd" are
both standard capabilities of most smart light APIs. Once a TLS
session is established, the transport handles "fwupd" publications
_the same way_ as "on/off" publications. Such attacks can be
prevented using trust management that operates per-publication, using
rules that enable the "fwupd" from the light switch to be rejected.
Combining per-publication trust decisions with many-to-many
communications over broadcast infrastructure requires per-publication
signing rather than session-based signing. More on how DeftT
addresses past and current threats is in Section 1.6 and Section 7.
Securing each publication rather than the session it arrives on deals
with a wider spectrum of threats while avoiding the quadratic session
state and traffic burden. In OT, valid messages conform to rigid
standards on syntax and semantics
[IEC61850][ISO9506MMS][ONE][MATR][OSCAL][NMUD][ST][ZCL] that can be
combined with site-specific requirements on identities and
capabilities to create a system's communication rules. These rules
can be employed to secure publications 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.
Instead of vulnerable third-party CAs [W509], domains employ a
*local* root of trust and _locally_ created certificates.
Communication rules are expressed in a _declarative_ language that
can be validated for consistency and completeness then converted to a
compact runtime form which is authorized and secured via signing with
the system trust anchor. This _communication schema_ is distributed
as a certificate that can be validated using on-device trusted
enclaves [TPM][HSE][ATZ] as part of the device enrollment process.
See Section 5 and Section 7.
Figure 5 shows a simplified version of a communication schema for
Figure 3. These member identities are simple two-level signing
chains, the domain trust anchor signs the identities (device certs).
The notation "<=" should be read as "is signed by" and the "& {}"
notation indicates particular constraints. We give switches and
lights different attributes in their identities ("switch" or "light")
and then require that publications that send commands to turn on or
Nichols, et al. Expires 16 February 2025 [Page 12]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
off must be signed by switch identities. We limit light identities
to signing publications that indicate their on or off status. When a
light constructs a publication, the "room" and "loc" fields will be
set to its identity's "_myroom" and "_myloc" attributes. When
validating a light publication, "room" and "loc" must equal the pub
signer's "_myroom" and "_myloc" and the "arg" must equal either "on"
or "off". These rules specify that all certificates have three final
components, the first of which is always "KEY"; the other two follow
requirements within the trust engine (DeftT's approach is detailed in
Section 3.3).
_domain: "myLights" // trust domain name
domainCert: _domain/_certSuffix // domain trust anchor
// publication format
#lsPub: _domain/room/loc/arg/_ts & {_ts: timestamp()}
// what switches and lights can say
rooms: "kitchen"|"den"
switch: #lsPub & {room: rooms|"all", arg: "turnOn"|"turnOff"} <= switchCert
light: #lsPub & {room: _myroom, loc: _myloc, arg: "on"|"off"} <= lightCert
// device certificate formats
deviceCert: _domain/_type/_myroom/_myloc/_certSuffix <= domainCert
switchCert: deviceCert & {_type: "switch"}
lightCert: deviceCert & {_type: "light"}
// fields added to all cert names by cert builder
_certSuffix: "KEY"/_/_
Figure 5: Example communication schema for Figure 3's lighting system
The administrator of the "myLights" domain compiles the text version
of the schema into binary and makes a schema cert, then makes a trust
anchor, kitchen and den switch identities, four kitchen ceiling light
identities, one kitchen counter light identity, and four den ceiling
light identities. (Utilities for this are provided at [DCT].) The
trust anchor private key is used to sign all of these and each device
is preconfigured with the trust anchor cert, the schema cert, and its
device cert (along with the device cert private key).
In DeftT's publication-based transport, the schema is used to both
construct and validate publications, guaranteeing that _all_ parts of
the system _always_ conform to and enforce the same rules, even as
those rules evolve to meet new threats (more in Section 4.1). DeftT
embeds the trust management mechanism described above directly in the
publish and subscribe data paths as shown below:
Nichols, et al. Expires 16 February 2025 [Page 13]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
(Artwork only available as svg: ./figs/trustElements-rfc.svg)
Figure 6: Trust management elements of DeftT
This approach extends LangSec's [LANGSEC] "be definite in what you
accept" principle by using the authenticated common rules of the
schema for belt-and-suspenders enforcement at both publication and
subscription functions of the transport. If an application asks the
Publication Builder to publish something and the schema shows it
lacks credentials, an error is thrown and nothing is published.
Independently, the Publication Validator ignores publications that:
* don't have a locally validated, complete signing chain for the
credential that signed it
* the schema shows its signing chain isn't appropriate for this
publication
* have a publication signature that doesn't validate
Since an application's subscriptions determine which publications it
wants, only certificates from chains that can sign publications
matching the subscriptions need to be validated or retained. Thus a
device's communication state burden and computation costs are a
function of how many different things are allowed to talk to it but
_not_ how many things it talks to or the total number of devices in
the system. In particular, event driven, publish-only devices like
sensors will spend no time or space on validation. Unlike most
'secure' systems, adding additional constraints to schemas to reduce
attack surface results in devices doing _less_ work.
1.4. Defined-trust Communications Domains
A Defined-trust Communications Limited Domain (or simply, _trust
domain_) is a Limited Domain where communications are via DeftT
(Figure 7) and all members are configured with the same trust anchor
and schema (or some subset of the domain schema) as well as an
individual schema-conformant DeftT identity cert chain that
terminates at the trust anchor and the private key corresponding to
the identity chain's leaf cert. 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 (schema) particular to a deployment. We
anticipate that efforts to create common data models (e.g., [ONE])
for specific sectors will lead to easier and more forms-based
configuration of DeftT deployments.
Nichols, et al. Expires 16 February 2025 [Page 14]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
A trust domain is perimeterless and may operate over one or more
subnets, sharing physical media with non-members. Domain members use
DeftT to publish and subscribe using Publication Builders and
Validators as shown in Figure 6. Publications become the elements of
a set, or named collection, that is synchronized across each subnet
of a trust domain that is using the same schema or schema subset.
DeftT uses a distributed set reconciliation protocol on _each_
collection and _each_ subnet independently. A DeftT's set
reconciliation protocol operates in a _sync zone_ which is defined on
a single subnet where members use the same communication schema or
communication schema subset. Every DeftT maintains at least two
collections: *msgs* for Publications constructed from application
messages and *cert* where member signing chains are published.
(Artwork only available as svg: ./figs/trustdomain-rfc.svg)
Figure 7: Trust domain
Trust domains are extended across physically separated subnets,
subnets using different media and/or groups of members using distinct
subsets of the domain schema by *relays*. (see Section 3.7) Relays
have a DeftT in each sync zone and pass Publications between them as
long as the Publications are valid at both the receiving and sending
DeftTs. Since set reconciliation does not accept duplicates, relays
are powerful elements in creating efficient configuration-free
meshes. In Figure 8, different sync zones are denoted by shape and
could represent different colocated media (e.g. bluetooth, wifi,
ethernet) or physically distant sync zones. The shaded triangles
represent DeftTs in a sync zone with only relay members, as for a
unicast link between two relays. The set reconciliation protocol
ensures that items only transit a sync zone once; an item must be
specifically requested in order to be transmitted.
Any part of a verifiable defined-trust identity can be used in the
delineation of sync zones, e.g. specific component(s) of identity
names allowed to sign Publications can be constrained to be identical
so that Publications are effectively only relayed to a particular
"group" as identified by those components. This is enforced via the
secured schema, i.e., non-"group" Publications will not validate.
Relay identities have a relay _capability_ (an attribute with a
special meaning within DeftT) in their signing chain so that they can
use specialized certificate and Publication movement while being
prohibted from obtaining Publication encryption/decryption keys.
There are four subnets in Figure 8, represented as different shapes.
The subnets could be using different media, different group
addresses, or be physically remote. A relay has a DeftT in two or
more subnets of the Domain, e.g. one of these covers subnets 1, 3,
and 4. Conceptually, relay DeftTs maintain a collection in their
Nichols, et al. Expires 16 February 2025 [Page 15]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
subnet, e.g. subnet1, on behalf of the members in its other subnets,
e.g., subnets 3 and 4. Relay internals copy Publications to the
other DeftTs but only after validating them using the (sub)schema in
use on the destination DeftT. Relay discussion is in Section 3.7 and
Section 6.
(Artwork only available as svg: ./figs/relayedtrustdomain-rfc.svg)
Figure 8: Relayed trust domain
1.5. Discovery
Conventional IP services are discovered via well-known IP ports that
are registered with IANA [RFC6335]. DeftT is not a service, so it
doesn't require a port allocation. Instead, DeftT does peer
discovery using shared security information. In particular, each
DeftT is a member of a trust domain and communicates within a single
sync zone where all members use the same schema cert, which is signed
by the common trust anchor (see Section 1.4). The SHA256 thumbprint
Section 2 of the schema cert for a sync zone is a compact, unique
identifier.
1.5.1. Multicast
The first 8 bytes of the schema cert thumbprint are used as the first
component in all DeftT PDUs (see Section 3.3.1.1) and the lower 14
bytes are used for DeftT's link-local IPv6 addresses.
IPv6 mutlicast addresses have format [RFC4292]:
8| 4 | 4 | 112 |
--+-----+-----+--------+
FF|flags|scope|group ID|
--+-----+-----+--------+
and DeftT sets these as:
FF|01|02|<lower 112 bits of schema cert thumbprint>
where flags=01 indicates a dynamically assigned address and scope=02
indicates link-local scope. The UDP dest port is set using the upper
byte of the id to pick a random value in the [RFC6335] Dynamic Ports
range 49152-65535. As UDP multicast requires different ports for
send and receive, this use doesn't conflict at all with the normal
use of this range for emphemeral client source ports.
Nichols, et al. Expires 16 February 2025 [Page 16]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
1.5.2. Unicast
Unicast protocols require more configuration than multicast, partly
because they're inherently asymetric so each end has to know in
advance whether to 'listen' or 'connect', partly because there are
firewall and NAT implications, and partly due to DeftT wanting good
peer authentication and privacy. Since unicast is between particular
DeftT peers, the protocol, role, address and port information goes
into the identity chains (Section 5.2) of those peers as an
attribute. This allows them to connect, zero-RTT mutually
authenticate, and establish a TLS-1.3-like EC Diffie-Hellman secure
tunnel as needed.
1.6. Design rationale
DeftT's Publication, PDU and serialization formats were strongly
influenced by the LangSec observation that most security issues are
due to improper input handling. For example, [LangSecErr] (section
II) found that this class of errors accounted for 75% of the 47
OpenSSL security vulnerabilities reported in the 18 months following
2015-1-1. Also, as of 2023-7-5, _all_ 25 of the protobuf CVEs listed
in the NIST National Vulnerability Database (https://nvd.nist.gov/)
are of this class.
[LangSecErr] suggests these vulnerabilities could have been avoided
by designing the protocol following three rules:
| The acceptable input to a program should be:
|
| 1. _well-defined_ (i.e., via a grammar)
| 2. _as simple as possible_ (on the Chomsky scale of syntactic
| complexity)
| 3. _fully validated before use_ (no "shotgun parsing")
1.6.1. Making DeftT "well-defined"
A DeftT domain's "acceptable inputs" are specified using its
_communication rules_ declarative language (Section 4.1) then
compiled by an LALR parser into a compact binary "schema" that avoids
any need for runtime parsing. Given the schema, the DeftT runtime
can construct or validate any conformant domain input in constant
time. The compiler will fail to construct a schema if the domain
communication rules are ambiguous, incomplete or inconsistent.
After successful compilation the schema is authorized, authenticated
and integrity protected by cryptographic signing using the domain's
trust anchor. This signed schema is supplied to every member as part
of their identity bundle (Section 5.2) and the SHA-256 thumbprint
Nichols, et al. Expires 16 February 2025 [Page 17]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
(see Section 3.3.1.4) of the schema is the first component of every
PDU's topic name. This ensures not only that the rules are well
defined but also that all publishers and subscribers are playing by
the _same_ rules.
1.6.2. Making DeftT "as simple as possible"
All DeftT Information is represented using TLV (Type, Length, Value)
tuples for the reasons noted by Dan Berstein
[netstrings][tnetstrings]:
* Unlike delimitter-based approaches like XML or JSON, TLVs are
resistant to buffer overflow and false pairing attacks.
* TLVs are self-describing and trivial to parse or validate.
* They can be used recursively -- containers can contain other
containers.
* TLVs are fast, cache friendly and not resource intensive.
* TLVs make no assumptions about contents and can store binary data
without escaping or encoding.
* TLVs are transport agnostic.
Attackers regard the 'seams' between protocol layers as prime attack
surface since a lower layer can pass up partial information that it
later finds to be inconsistent or invalid (an anti-pattern known as
_shotgun parsing_ [LangSecErr]). DeftT deliberately reuses a small
set of formatting conventions to construct its TLV containers in
contrast to the Internet convention of constructing its PDUs in
separate layers with rules chosen by different committees. For
example, DeftT PDUs, Publications and Certs have essentially the same
format (Section 3.3) so they can _all_ be structurally validated
(e.g., the contents of a container are the type expected in the order
expected and exactly fill their container) by _one_ simple, generic,
recursive descent validation pass over each arriving PDU performed at
the point where it arrives.
As described in Section 1.3, DeftT validates every Publication and
PDU both cryptographically and syntactically using the domain's
_communication rules_ to enforce who-can-say-what-to-which-where-
when. DeftT does both serialization and validation using rules bound
at runtime (Figure 6) not compile time. It can do this at rates
competitive with protobufs by taking advantage of the "definiteness"
of local-domain communication:
* Since the same rules are used both to produce and validate
Publications/PDUs, encoding order is fixed and known in advance.
Thus every top-level object can be validated by a single
sequential pass through it.
Nichols, et al. Expires 16 February 2025 [Page 18]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
* Every party to the communication is guaranteed to be using the
same rules so there are no options and no negotiation thus no
combinatorial explosion of variants to check.
* Communication rules can be extended and amended at any time and
the resultant binary schema published to members with no changes
to their code. Thus the current ruleset should always be the
_minimum_ necessary to support existing applications and policies,
not the open-ended monster needed to support any possible future.
1.7. Current status
An open-source Defined-trust Communications Toolkit [DCT] with an
example implementation of DeftT is maintained by the corresponding
author's company. [DCT] currently has examples of using DeftT to
implement secure brokerless message-based pub/sub using multicast
UDP/IPv6 and unicast {UDP/TCP}/IPv6 and includes extending a trust
domain via a unicast connection or between two broadcast network
segments.
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
underway. Pollere is also working on home IoT uses. The development
philosophy for DeftT is to start from solving useful problems with a
well-defined scope and extend from there. As the needs of our use
cases expand, the Defined-trust communications framework will evolve
with increased efficiencies. DeftT's code is open source, as befits
any communications protocol, but even more critical for one
attempting to offer security. DCT itself makes use of the open
source cryptographic library libsodium [SOD] and the project is open
to feedback on potential security issues as well as hearing from
potential collaborators.
1.7.1. Performance considerations
The well-known issues with 802.11 multicast [RFC9119] can make DeftT
less efficient than it should be. Target OT deployments primarily
use smaller packet sizes and DeftT's set reconciliation provides
robust delivery that currently mitigates these concerns. DeftT use
may become another force for improved multicast on 802.11, joining
the critical network infrastructure applications of neighbor
discovery, address resolution, DHCP, etc.
Nichols, et al. Expires 16 February 2025 [Page 19]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Cryptographic signing takes most of the application-to-network time
in DeftT. Though not prohibitively costly (e.g., under 20
microseconds on a Mac Studio), increased use of signing in transports
may incentivize creation of more efficient signing algorithms.
DeftT is intended for the kinds of devices available today. The
minimum expected capability is that of an ESP32 as noted in
Section 1.1. Experience thus far on a number of platforms has not
shown DeftT to be unduly burdensome. Section 3.8 reports measurement
results for time to process application messages as well as memory
burden.
Note that DeftT incurs some memory overhead that may not be
immediately apparent. It keeps a copy of the current identity
information for all members that can produce Publications to which it
can subscribe (as per schema). This requires ~300 bytes per
certificate. Collections hold Publications for their lifetime plus a
skew time in order to prevent replay attacks.
1.7.2. Relationship to other approaches
OSCORE [RFC8613] adds object security to COAP specifically to get
around the vulnerability of using only DTLS/TLS with proxies. OSCORE
uses pre-shared keys, acquired out-of-band or via a key establishment
protocol, to encrypt/sign COAP messages which are carried as payload
in a COAP message with the OSCORE option. Its Security Context is
between two endpoints and specific to sender ID and recipient ID
where sender IDs may be established out-of-band. As Internet
compatible protocols, COAP/OSCORE/ACE[RFC9200] use 1) cleartext
options in their headers and 2) trusted third parties or resource
servers, both of which can be exploited.
A DeftT PDU uses a hash of its compiled rules cert to identify its
trust domain (Section 2) and uses *no* header options. In the
Internet, PDU headers tell nodes how the packet should be handled; in
a DeftT trust domain, the trust domain identifier indicates the
packet is part of the domain whose rules will be enforced by any
receiver. These are very different architectures both for
communicating and for securing communications and are expected to
serve different roles although the application spaces may overlap.
Further, DeftT and Defined-trust Communications are early-stage work
compared to COAP/OSCORE and other IETF work, but deployments are
underway by Operant and Pollere.
Out-of-band configuration techniques developed for COAP and OSCORE
should be adaptable for configuration of DeftT members.
Nichols, et al. Expires 16 February 2025 [Page 20]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
2. Terms
* capability certificate: certificates with a specially formated
name that has special meaning to DeftT modules. Capability
certificates are a way to add attributes to a signing chain that
have special meaning to DeftT (e.g., to designate relays and key
makers).
* collection: a set of elements denoted by a structured name that
includes the sync zone identifier.
* communication schema: (in context, just schema) defined set of
rules that cover the communications for a particular trust domain.
Where it is necessary to distinguish between the human readable
version and the compiled binary version, the modifiers "text" or
"binary" will be used. The binary version is placed in a
certificate signed by the domain trust anchor.
* DCT: Defined-trust Communications Toolkit. Running code, examples
and documentation for defined-trust communications tools, a schema
language and compiler, a DeftT implementation, and illustrative
examples.
* face: maintains tables of DeftT's cState PDUs to manage efficient
communications with the system transport in use (UDP multicast,
TCP, etc.).
* Limited Domain: as introduced in [RFC8799], refers to a region
where network and end system requirements, behaviors, and
semantics are applied only within a single region where membership
is assumed to be cryptographically secured. The region might be
physically local or it could be distributed across geographies,
e.g., as an overlay on the Internet. Limited in this context can
be understood as its dictionary (https://www.merriam-webster.com
(https://www.merriam-webster.com)) definition of _restricted_ or
_characterized by enforceable limitations_.
* identity: a certificate signing chain with a particular domain's
trust anchor at its root and a unique member certificate as the
leaf. The public certificates in the chain contain attributes and
capabilities for the leaf cert. Configured identities will
include the private key associated with the public key of the
member cert.
* identity bundle - entities in a trust domain are commissioned with
an identity bundle containing domain trust anchor, communication
schema cert, and the signing chain associated with a particular
identity. Identity private keys may be part of the bundle if
securely configured.
* identity cert: the leaf certificate of an identity. The holder of
the corresponding private key is considered to have that identity.
Nichols, et al. Expires 16 February 2025 [Page 21]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
* Publication: a named information object used by DeftT whose name
structure and signing requirements are specified by the schema.
Publications are the elements of the 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.)
* protocol data unit (PDU): a single unit of information composed of
protocol-specific control information and user data. DeftT uses
two types: cState: (from "collection state") and cAdd: (from
"collection additions").
* signing cert - the certificate holding the public key
corresponding to the private key a member uses to sign
Publications it originates. The signing cert is a leaf cert that
has its identity in its chain-of-trust. Normally directly signed
by an identity cert's private key.
* subschema - a shorthand way of referring to a subset of a domain
schema that is itself a complete schema, i.e., it can be packaged
in a schema cert and used by a DeftT to communicate. A
(sub)schema cert in use in a trust domain must be signed by the
domain trust anchor.
* sync protocol: a synchronization protocol that implements set
reconciliation of Publications between members in a sync zone
making use of cState and cAdd PDUs.
* sync zone: a single subnet where members use the same
communication schema or communication schema subset. PDUs never
leave a sync zone, the Publications they carry may be relayed.
* sync zone identifier: the thumbprint of the communication
(sub)schema used for a particular sync zone. It will be the same
as the trust domain identifier if the communication schema in use
is the domain communication schema.
* Things: as per [RFC8520], networked digital devices specifically
not intended to be used for general purpose computing.
* thumbprint: the 32 byte SHA256 digest of an _entire_ certificate
including its signature ensuring that each thumbprint resolves to
one and only one cert and signing chain.
Nichols, et al. Expires 16 February 2025 [Page 22]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
* 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 defined-trust
communications, a trust anchor is a self-signed certificate which
is the ultimate signer of all certificates in use in a trust
domain, including the communication schema. From [RFC4949]: trust
anchor definition: An established point of trust (usually based on
the authority of some person, office, or organization) which
allows the validation of a certification chain.
* trust domain: (or just domain, in context) denotes a Limited
Domain where all network communication are via DeftT, a zero trust
domain governed by a single trust anchor and communication schema
which is enforced at run-time by a library (e.g., DCT) using a
signed binary copy of the schema at each member. Nothing is
accepted without validation; non-conforming communications are
silently discarded.
* trust domain identifier: (or just domain id) the thumbprint of the
trust domain's communication schema certificate. As the schema
cert is signed by the trust anchor, a trust domain is uniquely
identified by its communication schema cert's thumbprint.
* trust-based relay: (or just relay) a special-purpose entity that
connects a trust domain between two or more sync zones. A relay
has two or more DeftT instances and moves Publications between the
instances according to the schema in use at each DeftT but does
not orginate any application Publications and is not given
Publication decryption keys when they are in use. The DeftT
instances may be using different physical subnets and/or different
subsets of the domain's communication schema. Relays can extend a
trust domain across physical subnets and geographic distance.
3. DeftT and Defined-trust Communications
DeftT synchronizes and secures communications between its enrolled
members. DeftT's multi-party synchronized collections of named,
schema-conformant Publications contrast with the bilateral session of
TCP or QUIC where a source and a destination coordinate with one
another to transport undifferentiated streams of information. At any
specific time, the DeftTs in a trust domain may hold different
subsets of a collection (e.g., immediately after entities add
elements to the collection) but the synchronization protocol ensures
all converge to the complete set of elements within a few round-trip-
times following the changes.
Nichols, et al. Expires 16 February 2025 [Page 23]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Applications use DeftT to add to and access from a collection of
Publications. DeftT enforces "who can say what to which" as well as
providing required integrity, authenticity and confidentiality.
Transparently to applications, a DeftT both constructs and validates
all Publications against its schema's formal, validated rules. The
compiled binary communication schema is distributed as a trust-root-
signed certificate and that certificate's thumbprint (see
Section 3.3.1.4 and Section 2) _uniquely_ identifies each trust
domain. Each DeftT is configured with the trust anchor used in the
domain, the schema cert, and its own credentials for membership in
the domain. DeftTs must be in the same domain to communicate.
Identity credentials comprise a unique private identity key along
with a public certificate chain rooted at the domain's trust anchor.
Identity chain certificate specifications are in the schema and some
of these certs contain the attributes granted to the identity. Thus,
attributes are stored in the identity *not* on an external server.
As illustrated in Figure 2, each member publishes its credentials to
the certificate collection in order to join the domain. DeftT
validates credentials as a certificate chain against the schema and
does not accept Publications without a fully validated signer. This
unique approach enables fully distributed policy enforcement without
a secured-perimeter physical network and/or extensive per-device
configuration. DeftT can share an IP network with non-DeftT traffic
as well as DeftT traffic of a different Domain. Privacy via AEAD
(Authenticated Encryption with Associated Data) is automatically
handled within DeftT if selected in the schema.
(Artwork only available as svg: ./figs/transportBD0v2-rfc.svg)
Figure 9: DeftT's interaction in a network stack
Figure 9 shows the data flow in and out of a DeftT. DeftT uses its
schema to package application information into Publications that are
added to its local view of the collection. Application information
is packaged in Publications which are carried in collection addition
(cAdd) PDUs that are used along with collection state (cState) PDUs
to communicate about and synchronize Collections. cStates report the
state of the local collection; cAdds carry Publications to other
members that need them. These PDUs are broadcast on their subnet
(e.g., UDP multicast).
Nichols, et al. Expires 16 February 2025 [Page 24]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3.1. Inside DeftT
DeftT's example implementation [DCT] is organized in functional
library modules that interact to prepare application-level
information for transport and to extract application-level
information from packets, see Figure 10. Extensions and alternate
module implementations are possible but the functionality and
interfaces must be preserved. Internals of DeftT are completely
transparent to an application and the example implementation is
efficient in both lines of code and performance (see Section 3.8).
The schema determines which modules are used (Figure 11). A DeftT
participates in two required collections and _may_ participate in
others if required by the schema-designated cryptographic methods
(see #distributors).. One of the required collections, *msgs*,
contains Publications constructed from application messages. The
other required collection, *cert*, contains the certificates of the
trust domain. Specific cryptographic methods _may_ require group key
distribution in descriptively named collection *keys*.
(Artwork only available as svg: ./figs/DeftTmodules-rfc.svg)
Figure 10: Run-time library modules
A _shim_ serves as the translator between application semantics and
the named information objects (Publications) whose format is defined
by the schema. The *syncps* module is the set reconciliation
protocol used by DeftT (see Section 3.2). New signature managers,
distributors, and face modules may be added to the library to extend
features. More detail on each module can be found at [DCT] in both
code files and documents.
The signing/validation modules (_signature managers_) are used for
both Publications and cAdds. Figure 11 shows validator
specifications for the two required Publication collections, one for
Publications carrying application messages and one for Publications
carrying certificates. The "#pduValidator" specifies AEAD, which
requires a symmetric key, an example of a sigmgr that requires
another distributor module (see #(group-key-distributors)) that is
automatically instantiated at run-time. Changing a pduValidator from
"EdDSA" to "AEAD" in a domain's communication schema is all that
needs to be done to change from signed, cleartext PDUs to PDUs
encrypted with a periodically regenerated shared key where only the
minimal information of trust domain identifier and collection type is
exposed.
#msgsValidator: "EdDSA"
#certValidator: "EdDSA"
#pduValidator: "AEAD" //for cAdds
Nichols, et al. Expires 16 February 2025 [Page 25]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Figure 11: Schema portion specifying the sigmgr to be used for
signing and validation
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 _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.
3.2. syncps: a set reconciliation protocol
DeftT requires a method or protocol that keeps collections of
Publications synchronized. Required functionality for such a
protocol can be understood through the example of the *syncps*
protocol included in the example implementation. The *syncps*
protocol uses IBLTs to 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. The state of a local collection is encoded in an IBLT.
IBLTs have been used for set reconciliation in blockchain systems,
specifically in Bitcoin Cash, contributing optimizations available as
open-source code [Graphene19] that syncps can utilize.
A syncps announces its local _collection state_ (set of currently
known Publications) by sending a cState (Section 3.3.1.1) that also
serves as a query for additional data not reflected in its local
state. Receipt of a cState performs three simultaneous functions:
(1) announces new Publications, (2) notifies of Publications that
member(s) are missing and (3) acknowledges Publication receipt. The
first may prompt the recipient to share its cState to get the new
Publication(s). The second results in the recipient sending a cAdd
(Section 3.3.1.2) containing all the locally available missing
Publications that fit. The third is used optionally and may result
in a progress notification sent to other local modules so anything
waiting for delivery confirmation can proceed.
On broadcast media, syncps uses any cStates it hears to reduce
(suppress) sending excess cStates and listens for cAdds that may add
to its collection. This means that one-to-many Publications cause
sending a single cState and a single cAdd independently of the number
of members desiring the Publication (the theoretical minimum possible
for reliable delivery). The digest size of a cState can be
controlled by Publication lifetime, dynamically constructing the
digest to maximize communication progress and, if necessary for a
large network, dynamically adapting topic specificity.
Nichols, et al. Expires 16 February 2025 [Page 26]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
A cAdd with new Publication(s) responds to a particular cState as per
(Section 3.3.1.2 item 1). Any DeftT that is missing a Publication
(due to being out-of-range, asleep, channel errors, etc.) can receive
it from any other DeftT. A syncps will continue to send cAdds as
long as cStates are received that are missing any of its active
Publications. This results in reliability that is subscriber-
oriented, not publisher-oriented, kept efficient with protocol
features that prevent multiple redundant broadcasts. The example
implementation of syncps prevents redundant broadcasts by having
originating publishers send their responding Publications immediately
while others delay before supplying missing Publications, canceling
if a responding cAdd is overheard. Other approaches are possible.
The collection synchronization work of a syncps module is shown as a
state diagram in Figure 12. When a new syncps is started, it always
sends its local cState (starts unsuppressed) on the network and sets
an expiration timer for the cState. If this timer expires, the "new
local cState" actions are repeated and the cState may be suppressed
(thus not sent). For most collections, the initial cState will show
an empty collection (certificate collections will have the local
identity chain). The events that can move the collection forward are
(1) the arrival of a cState from the network, (2) the arrival of a
cAdd from the network whose csID matches a hash value stored from a
previously received or sent cState, or (3) arrival of a new
Publication from its shim. For an arriving cAdd, each Publication is
extracted, validated, and passed to any registered subscriber
callback(s). Non-validating packets are silently discarded (may
optionally set alerts or count discards). Reception of new Pub(s)
may cause an application process to create and add new Publications
to the local collection. Sending of new Pubs is deferred until the
entire cAdd has been processed. If there are no new Pubs to send,
syncps moves to its "set sendCStateTimer" state where a cancelable
sendCState timer is set to the estimated dispersion delay of this
local subnet. (Dispersion should be << cState lifetime. More on
dispersion delay in Section 3.5.)
(Artwork only available as svg: ./figs/syncpsSD-rfc.svg)
Figure 12: State diagram of a syncps module
Since new Publications are always eligible to send, if any were
created while in "process cAdd", the next state is "process Pubs to
send" with csID set to the csID field of the cAdd on entry to
"process cAdd". In "process Pubs to send" any pending sendCState
will be canceled and eligible Pubs are packaged as content for a new
cAdd. Packaged Publications are subject to a hold time (during which
they are ineligible to send) of twice the dispersion delay to avoid
responding to cStates sent before reception of a cAdd containing the
Nichols, et al. Expires 16 February 2025 [Page 27]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Pub. If there are Pubs to send, a cAdd with that content and the
passed in csID is sent, then the set sendCStateTimer state is
entered; when there are no Pubs to send, the action moves there
directly.
Another path to exit the "wait for event" state is reception of a
cState which moves to "process cState" where incoming cStates are
recorded, If this cState matches the local cState, the syncps returns
to the wait state. Otherwise, the IBLT is extracted from the cState,
an IBLT is computed on the local Pub collection, and they are peeled
to find the ones the received cState has that are not in the local
collection ("needs") and the ones that are in the local collection
and not in the received cState ("haves"). Syncps enters the "process
Pubs to send" state with csID set to the hash of the cState's name.
Eligible Pubs are "haves" that do not have a hold time set and
locally generated Publications are sent preferentially. Publications
obtained from others are not immediately eligible to send; members
delay to give the originator time to respond, sending these when
further cStates indicate a member continues to need them.
A syncps also exits the wait state when the attached shim has a
Publication to send. Since a new Pub will not appear in any
previously issued cState, any one can be used, including one issued
locally. In "get stored cState", the best one (the most recent
cState from the network if available) is retrieved and passed to the
"peel IBLT values" state where its cState.csID is used for the csID
value. There will always be at least the one new Publication to send
in this case.
This state diagram is intended to capture the major functionality of
a syncps module while excluding excessive detail. In particular,
Figure 12 does not show "housekeeping" tasks on the collection, e.g.,
removal of expired Publications.
3.3. DeftT formats
All DeftT Information is represented using TLV (Type, Length, Value)
tuples. Types can either be containers (they contain a concatenated
sequence of TLVs) or leaves (they contain a single non-TLV value with
well-defined semantics and serialization). All TLVs have a boolean
'valid()' method that returns 'true' if and only if their content
satisfies all the constraints associated with the TLV's type. For
container types this means, at minimum, that the sum of all the
enclosed TLV Lengths and header sizes exactly equals the Length of
the container and that the valid() method of each of the enclosed
TLVs returns true. Most container types have additional constraints
on the type, ordering and value of the enclosed TLVs that are
described below.
Nichols, et al. Expires 16 February 2025 [Page 28]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3.3.1. Top level container TLVs
As shown in Figure 10 there are two kinds of top level containers:
PDUs which are exchanged with the system-provided network transport
and carry Pubs, the other top level container, which are the elements
of the set synchronization protocol. PDUS and Pubs have similar
structure and share most of their code but are designed to be
unambiguously distinguishable. As indicated in Figure 9 and
Figure 10, syncps uses a pub/sub model for both its shim facing and
network facing interfaces. Thus the first TLV in any top level
container is a Name container comprising the topic name used to
mediate the pub/sub rendezvous. The other TLVs in the top level
container depend on the kind of container.
There are two kinds of PDU containers: cState and cAdd and two kinds
of of Publications, publications and certs. All four are described
in the following section.
3.3.1.1. cState PDUs
A cState PDU (TLV type 5) announces the items a member holds in a
specific collection of a specific trust domain subnet. It must
contain the following three TLVs and they must be in this order:
1. Name TLV containing exactly three type Generic (aka, byte array
or binary blob) components:
C1: Sync zone id consisting of the first 8 bytes of the SHA-256
thumbprint of the communication schema cert in use for this
domain (may be the same as the trust domain id).
C2: Collection name
C3: Run-length compressed IBLT of the items in the publisher's
instance of the collection (see Section 3.2 for more
information on IBLTs).
2. Nonce (TLV type 10, leaf) whose value must be 4 random bytes
chosen by the publisher at the time the cState is built.
Duplicate cStates can arise from multiple members announcing the
same Name because they hold the same items or because the network
doesn't handle multicast well and lets PDUs loop. The nonce
allows these two cases to be distinguished so looping cStates can
be dropped.
3. Lifetime (TLV type 12, leaf) whose value is the lifetime
(measured in milliseconds since this PDU's arrival) serialized as
an unsigned big-endian integer with all leading zero bytes
suppressed. A member receiving the cState and capable of
publishing into the collection can hold onto the cState for this
Nichols, et al. Expires 16 February 2025 [Page 29]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
lifetime. If the member has an item to publish before the end of
the cState's lifetime, the Publication can be sent immediately in
a responding cAdd.
For example, the initial PDU sent by the home IoT "gate controller"
sample app (in examples/hmIot of [DCT]) will be a cState in the
*cert* collection and looks like:
5 (cState) size 128:
| 7 (Name) size 116:
| | 8 (Generic) size 8: 55d5 7f99 7d8d ba91
| | 8 (Generic) size 4: cert
| | 8 (Generic) size 98: 8201 dd76 eb0f 46ed 89a8 8101 dd76 eb0f 46..
| | beb5 9922 fdd6 7401 cbbe 5bc1 5b57 1c63 84..
| | 79aa ca17 8501 cbbe 5bc1 5b57 1c63 8801 ce..
| | 92f8
| 10 (Nonce) size 4: 8b9f 8134
| 12 (Lifetime) size 2: 4789
Note that the format inspections of this section are produced by
using the dctwatch tool from [DCT] with the -f option.
3.3.1.2. cAdd PDUs
Note: cAdds, Publications and Certificates all share the same Data
(TLV type 6) container format but are distinguished by its Metainfo
TLV. They all contain the same five TLVs in the same order but each
has different constraints on the value of those TLVs.
A cAdd PDU (TLV type 6) supplies one or more Pubs in response to some
cState. It must contain the following five TLVs and they must be in
this order:
1. Name TLV derived from the cState's Name: the first two
components, sync zone id and collection name, are the same but
the IBLT component is replaced by a csID (TLV type 35, leaf)
whose value must be the 32 bit big-endian Murmurhash of the
cState's entire Name TLV. (This is done because "Repeat the
question and append the answer" is the common strategy for
matching responses to requests in multicast protocols but an IBLT
can be hundreds of bytes which would drastically reduce the
cAdd's payload space so "the question" is replaced with a compact
hash proxy.)
2. Metainfo (TLV type 20) saying the PDU's ContentType is cAdd (42),
i.e., contains one or more Pubs and nothing else so it must be
'structurally validated' on arrival.
Nichols, et al. Expires 16 February 2025 [Page 30]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3. Content container (TLV type 21) which must contain one or more
complete, valid Pubs. The Pubs must NOT already be in the
cState's IBLT. I.e., the Pubs must be newly created on the cAdd
publisher or in the 'need' set when the difference between the
publisher's IBLT and the cState's IBLT is 'peeled' (see [DIFF]
and the DeftT example implementation's handleCState code
(https://github.com/pollere/DCT/blob/main/include/dct/syncps/
syncps.hpp#L460) for details).
4. SigInfo container (TLV type 22) which must contain a SigType (TLV
27, leaf) containing a valid keyed or unkeyed signature type from
the types listed in Section 3.3.2. If and only if the signature
type is keyed (i.e., validation requires the public key cert of a
public/private keypair), the SigInfo must contain KeyLocator (TLV
28) containing a KeyDigest (TLV 29, leaf) of length 32 bytes
containing the thumbprint of the cert needed for validation. The
SigType must match the type of the PDU signature validator
associated with the collection.
5. SigValue (TLV type 23, leaf) containing the result of signing the
cAdd PDU with using the algorithm and key, if any, specified by
the SigInfo. The Length of the TLV must match the length used by
the signature type as per Section 3.3.2. The PDU signature
validator must successfully validate the signature.
For example, the following is the frontdoor's cAdd responding to the
cState, shown above, for the *cert* collection. The *cert*
collection is synced by the certificate distributor which can't use
any signature types that depend on keys since it's responsible for
obtaining the certificates containing the keys that would be needed
to validate a PDU's signature. Thus, it is the _only_ collection
allowed to use an unkeyed [RFC7693] BLAKE2 MAC to integrity check its
PDUs (this is why Figure 11 does not specify a separate validator for
cert PDUs). Since the content is self-authenticating public key
certs, this doesn't cause security issues.
6 (Data) size 561:
| 7 (Name) size 22:
| | 8 (Generic) size 8: 55d5 7f99 7d8d ba91
| | 8 (Generic) size 4: cert
| | 35 (csID) size 4: f6d7 3d84
| 20 (MetaInfo) size 3:
| | 24 (ContentType) size 1: 42 (CAdd)
| 21 (Content) size 489:
... (489 bytes of Content elided)
| 22 (SigInfo) size 3:
| | 27 (SigType) size 1: 9 (RFC7693)
| 23 (SigValue) size 32: af8e 1412 e659 103f 5237 f1e1 0e7b 0af8 9c..
Nichols, et al. Expires 16 February 2025 [Page 31]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Except for this collection, PDU and Publication signature types are
specified in the schema. PDUs typically use AEAD with a locally
elected cover key distributor to protect the content privacy.
Publications typically use EdDSA to provide provenance and ABAC
attributes via the signing chain or a combined AEAD and EdDSA
signature type (AEADSGN) to constrain content disclosure to some
limited group. All encrypted content must remain encrypted, in
motion or at rest, from point of origin to point(s) of use. The
syncps subscribe upcall may decrypt a piece of content for
_ephemeral_ use but the callee must NOT retain the plaintext form.
3.3.1.3. Publications
As noted above, a Publication must be in a Data TLV containing the
same five TLVs in the same order as cAdds and Certificates.
Publications are distinguished by having a Metainfo ContentType of
Blob (0).
DeftT communicates via Publications which are currently organized
into collections of _msgs_ and _keys_.
A Publication (TLV type 6) must contain the following five TLVs and
they must be in this order:
1. Name TLV which must contain at least three components and the
first component's length must be non-zero. The schema specifies
the format of the Name including number and type of components,
allowed values, allowed signers, etc. Implementations must
construct and sign Pubs so that they are consistent with the
schema. (The example implementation's applications show that
this can be done automatically with minimal application
involvement, e.g., see the phone app
(https://github.com/pollere/DCT/blob/main/examples/office/
phone.cpp) in the office control example.) Implementations must
fully validate Publications both cryptographically and against
the schema before adding them to the collection. Implementations
must NOT add a Publication to a collection that already contains
it.
2. Metainfo (TLV type 20) saying the Publication's ContentType is
Blob (0), i.e., contains arbitrary bytes that can't be
'structurally' validated (but are always cryptographically
validated for integrity and authorization by the signature
check)..
3. Content container (TLV type 21) containing _Length_ bytes.
_Length_ may be zero.
Nichols, et al. Expires 16 February 2025 [Page 32]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
4. SigInfo container (TLV type 22) which must contain exactly two
TLVs: a SigType (TLV type 27, leaf) containing a valid keyed
signature type from the types listed in Section 3.3.2 followed by
a KeyLocator (TLV type 28) containing a KeyDigest (TLV type 29,
leaf) of length 32 bytes containing the thumbprint of the cert
needed to validate the signature. The SigType in the Publication
must match the collection's Publication validator which must
match the #pubValidator specified in the schema.
5. SigValue (TLV type 23, leaf) containing the result of signing the
Publication using the algorithm and key specified by the SigInfo.
The Length of the TLV must match the length used by the signature
type as per Section 3.3.2. The collection's publication
signature validator must successfully validate the signature.
For example, what follows are two consecutive Publications made to
the msgs collection. First, operator alice publishes a command for
all lock devices to lock themselves (similar to the multiple
subscriptions per-light shown in Figure 3, the schema requires that
all lockable devices subscribe to the iot1/lock/command/all prefix in
msgs):
6 (Data) size 216:
| 7 (Name) size 68:
| | 8 (Generic) size 4: iot1
| | 8 (Generic) size 4: lock
| | 8 (Generic) size 7: command
| | 8 (Generic) size 3: all
| | 8 (Generic) size 4: lock
| | 8 (Generic) size 17: p38863@aphone.local
| | 37 (SequenceNum) size 4: b4a1 ea2a
| | 37 (SequenceNum) size 0:
| | 36 (Timestamp) size 7: 23-09-18@19:40:45.591793
| 20 (MetaInfo) size 3:
| | 24 (ContentType) size 1: 0 (Blob)
| 21 (Content) size 32: Msg #3 from operator:alice-38863
| 22 (SigInfo) size 39:
| | 27 (SigType) size 1: 8 (EdDSA)
| | 28 (KeyLocator) size 34:
| | | 29 (KeyDigest) size 32: 7096 5de9 6848 7543 d2c8 e459 24fb 7b0..
| 23 (SigValue) size 64: 61b3 fc3c 03df 2c89 7a0c ddae 27a2 f883 dd..
| 2699 899f 1c91 46c1 3127 9da8 8948 e783 68..
Three milliseconds later, the gate publishes that it has locked
itself:
Nichols, et al. Expires 16 February 2025 [Page 33]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
6 (Data) size 214:
| 7 (Name) size 69:
| | 8 (Generic) size 4: iot1
| | 8 (Generic) size 4: lock
| | 8 (Generic) size 5: event
| | 8 (Generic) size 4: gate
| | 8 (Generic) size 6: locked
| | 8 (Generic) size 17: p59280@rpi2.local
| | 37 (SequenceNum) size 4: e131 5a4b
| | 37 (SequenceNum) size 0:
| | 36 (Timestamp) size 7: 23-09-18@19:40:45.594867
| 20 (MetaInfo) size 3:
| | 24 (ContentType) size 1: 0 (Blob)
| 21 (Content) size 29: Msg #3 from device:gate-59280
| 22 (SigInfo) size 39:
| | 27 (SigType) size 1: 8 (EdDSA)
| | 28 (KeyLocator) size 34:
| | | 29 (KeyDigest) size 32: 3dde 0f21 beae 2c20 3ea3 5c2e 77ca 9d4..
| 23 (SigValue) size 64: 3913 011d 7e74 807c 94b5 e725 a8e7 5b2f 09..
| bc99 9c8b fa9f f929 4722 f23a 1fbe cd84 b6..
As described in Section 7, the schema is designed for spoofing and
replay protection of Publications. Section 3.2 notes that the per-
publication EdDSA signature prevents spoofing or modification. Since
all collections ignore duplicates of an existing publication, replays
of anything in the collection will be ignored. Publications have a
collection-dependent lifetime that is generally ephemeral. To keep
collections from growing without bound, Publications are removed once
their arrival time plus lifetime exceeds the node's local time.
Arriving Publications are ignored if their timestamp (name component
9) plus a collection-dependent "expiry time" is after the node's
local time. "lifetime" is substantially larger then "expiry time" to
account for clock skew so the combination of these two mechanisms
prevents all replay.
3.3.1.4. Certificates
As noted above, a Certificate must be in a Data TLV containing the
same five TLVs in the same order as cAdds and Publications.
Certificates are distinguished by having a Metainfo ContentType of
Key (2) and by having a Validity Period specified according to a more
rigorous subset of the rules in [RFC1422] section 3.3.6 as described
in item 5 below.
A Certificate (TLV type 6) must contain the following five TLVs and
they must be in this order:
Nichols, et al. Expires 16 February 2025 [Page 34]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
1. Name TLV which must contain at least five components and the
first component's length must be non-zero. The schema specifies
the format of the Name including number and type of components,
allowed values, allowed signers, etc. Implementations must
construct and sign certs so that they are consistent with the
schema. (Tools to do this are supplied with the example
implementation.) Implementations must fully validate certs both
cryptographically and against the schema before adding accepting
them. "Fully validating" requires that the cert's signer has
been accepted thus a cert cannot be accepted until its entire
signing chain has been accepted.
2. Metainfo (TLV type 20) saying the Cert's ContentType is Key (2),
This means the container has no TLV structure to validate.
3. Content container (TLV type 21) containing _Length_ bytes.
_Length_ must equal the size of the public key associated with
the cert's SigInfo SigType
4. SigInfo container (TLV type 22) which must contain exactly two
TLVs: a SigType (TLV type 27, leaf) containing a valid keyed
signature type from the types listed in Section 3.3.2 followed by
a KeyLocator (TLV type 28) containing a KeyDigest (TLV type 29,
leaf) of length 32 bytes containing the thumbprint of the cert
needed to validate the signature. The KeyDigest must be followed
by a Validity Period (TLV 253) containing a NotBefore (TLV 254,
leaf) containing a valid 15 character ISO 8601-1:2019 format GMT
timepoint followed by a NotAfter (TLV 255, leaf) containing a
valid 15 character ISO 8601-1:2019 format GMT timepoint. The
cert must be ignored if the NotBefore value is >= the NotAfter
value, if the NotAfter value is < the current time or if the
validity period is not completely contained within its signing
cert's validity period. The SigType in the Cert must match the
#certValidator type specified in the schema.
5. SigValue (TLV type 23, leaf) containing the result of signing the
Cert using the algorithm and key specified by the SigInfo. The
Length of the TLV must match the length used by the signature
type as per Section 3.3.2.
For example, what follows is the frontdoor's identity cert used in
the home IoT example which gets added to the "cert" collection:
Nichols, et al. Expires 16 February 2025 [Page 35]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
6 (Data) size 240:
| 7 (Name) size 50:
| | 8 (Generic) size 4: iot2
| | 8 (Generic) size 6: device
| | 8 (Generic) size 9: frontdoor
| | 8 (Generic) size 3: KEY
| | 8 (Generic) size 4: 0eaf f793
| | 8 (Generic) size 3: dct
| | 36 (Timestamp) size 7: 23-02-18@18:17:46.088971
| 20 (MetaInfo) size 3:
| | 24 (ContentType) size 1: 2 (Key)
| 21 (Content) size 32: de19 4605 7f77 a7bd 1317 de41 002c fe15 1bc..
| 22 (SigInfo) size 81:
| | 27 (SigType) size 1: 8 (EdDSA)
| | 28 (KeyLocator) size 34:
| | | 29 (KeyDigest) size 32: 8c7f 1de9 ebc9 17b6 a8e9 dce9 056a 74c..
| | 253 (Validity) size 38:
| | | 254 (NotBefore) size 15: 20230219T021746
| | | 255 (NotAfter) size 15: 20240219T021746
| 23 (SigValue) size 64: c8b9 5883 4b9a 8aac 9ad0 e5e4 5eef 0a18 4b..
| 1b3a 1574 58d4 0528 1740 883e d90c 836f ed..
3.3.2. Leaf TLVs
Most of DeftT's leaf TLVs were described above but there are two
important enumeration types, name components and signature types,
with particular constraints and implications.
There are four types of components allowed in a Name (TLV 7):
+=============+=====+===========================================+
| Type | TLV | Description |
+=============+=====+===========================================+
| Generic | 8 | Arbitrary blob of bytes |
+-------------+-----+-------------------------------------------+
| csID | 35 | 32-bit murmurhash of cState name (number) |
+-------------+-----+-------------------------------------------+
| Timestamp | 36 | GMT time point in microseconds (number) |
+-------------+-----+-------------------------------------------+
| SequenceNum | 37 | unsigned 64-bit integer (number) |
+-------------+-----+-------------------------------------------+
Table 1: Name Component Types
"Number" types are encoded in big-endian order (MSB first) with all
leading zero bytes suppressed. Thus their length can be zero to
eight bytes. For example, a SequenceNum of 0 would be [37, 0], 100
would be [37, 1, 100] and 1,000,000 would be [37, 3, 15, 66, 64].
Nichols, et al. Expires 16 February 2025 [Page 36]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
There are five types of signature allowed in a SigType (TLV 27) and
each requires the SigValue (TLV 23) in a Data with that SigType have
a particular size:
+===========+=======+==========+===========================+
| Type | Value | SigValue | Description |
| | | length | |
+===========+=======+==========+===========================+
| stSHA256 | 0 | 32 | SHA256 data integrity |
+-----------+-------+----------+---------------------------+
| stAEAD | 7 | 40 | [RFC8103] content privacy |
| | | | plus full data integrity |
+-----------+-------+----------+---------------------------+
| stEdDSA | 8 | 64 | Ed25519 provenance and |
| | | | full data integrity |
+-----------+-------+----------+---------------------------+
| stRFC7693 | 9 | 64 | [RFC7693] full data |
| | | | integrity |
+-----------+-------+----------+---------------------------+
| stAEADSGN | 13 | 104 | [RFC8103] content privacy |
| | | | with Ed25519 provenance |
| | | | and data integrity |
+-----------+-------+----------+---------------------------+
Table 2: Signature Types
3.3.3. TLV header details
All TLV headers use the same format. They occupy either 2 or 4
bytes, depending on the value of _L_. _L_ specifies the length in
bytes of _V_. Lengths in the range 0 to 252 occupy one byte. A
length of zero is allowed and indicates there are no _V_ bytes.
Lengths in the range 253 to 65535 occupy three bytes: a 'flag byte'
of 253 followed by the two bytes of the 16 bit length in big endian
order. Lengths greater than 65535 (deliberately) can not be
represented so a DeftT object can be no larger than 65535+4 = 65539
bytes. (Objects of arbitrary size can be handled by a segmentation/
reassembly layer above DeftT such as dct/shims/mbps.hpp in the
example implementation.)
_L_ must use the minimum description length coding. For example, a
length of 0 must be encoded as the single byte [0], not as the 3
bytes [253, 0, 0], 252 is encoded as [252], 253 as [253, 0, 253], 256
as [253, 1, 0] and 65535 as [253, 255, 255].
_T_ specifies the type of data in the container. It occupies one
byte, must be an element of the valid types set defined below, and
must conform to that element's rules.
Nichols, et al. Expires 16 February 2025 [Page 37]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3.4. Application and network interface
Figure 9 and Figure 10 show the blocks and modules application
information passes through in DeftT and may be useful references for
this subsection. In a trust domain, applications pass information to
be communicated to their DeftT, which packages it into Publication(s)
that are added to the local collection copy. These Publications are
also sent in a PDU via the system network interface to be received by
other members of the domain which add the Publications to their local
collections. If a received Publication matches a subscription, the
information it contains is passed to the application. (For more
detail, see the library at [DCT].) DeftT is organized into modules
that perform its tasks. A DeftT *shim* exchanges information with
applications. The example implementation [DCT] provides a message-
based publish/subscribe (_mbps_) API that exchanges messages with the
application and Publications with the sync protocol. (Other APIs are
possible.) DeftT startup begins when a shim object is instantiated
by the application and given its identity bundle. Startup includes
creating a certificate distributor and, optionally, group key
distributors, depending on schema-specified signing. After startup,
the *msgs* syncps of each member will maintain a cState containing
the IBLT of its view of the collection. (In the stable, synchronized
state, all members of a collection will have the same IBLT.)
Applications subscribe to all messages, or to a subset by topic, by
passing a callback function to the mbps _subscribe_ method.
Application subscriptions are turned into syncps subscriptions via
mbps. An application with new information to communicate passes the
formatted topic items as parameters and the other content in a
message via a _publish_ call. Only the topic components and the
message, if any, are passed between the application and mbps. Mbps
adds mbps-specific components to the parameter list and invokes a
*schemaLib* method that builds a valid (according to the schema)
Publication and can be passed to *syncps* to publish. Messages that
exceed the content size limits of a single Publication are segmented
by mbps and carried in multiple Publications. If a member's identity
chain lacks the attributes required for a specific Publication, no
Publication is built. The Publication is signed using the _sign_
method of the appropriate *sigmgr* and passed to *syncps*.
*syncps* adds this Publication to its collection and updates its IBLT
to contain the new Publication. Since its application just created
it, the Publication is a new addition and thus is always a response
to the current cState. The Publication is packaged into a cAdd and
signed using the _sign_ method of the designated *sigmgr* and passed
to the face. The updated IBLT is packaged into a new cState that is
handed to the face.
Nichols, et al. Expires 16 February 2025 [Page 38]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Trust domain members only process cAdds that share their trust domain
identifier (Section 3.3.1.1 and Section 3.3.1.2). When a new cAdd is
received at a member, the face ensures it matches an outstanding
cState and, if so, passes it on to its matching syncps(es). Syncps
validates (both structurally and cryptographically) the cAdd using
the appropriate sigmgr's _validate_ and continues, removing
Publications, if valid. Each Publication is structurally validated
via a sigmgr and valid Publications are added to the local collection
and IBLT. syncps passes this updated cState to the local face. If
this Publication matches a subscription it is passed to mbps,
invoking the sigmgr's decrypt if the Publication is encrypted.
(Publication decryption is _not_ available at relays.) *mbps*
receives the Publication and passes any topic components of interest
to the application along with the content (if any) via the callback
registered when it subscribed. (If the original content was spread
across Publications, mbps will wait until all of the content is
received. The _sCnt_ component of a mbps Publication Name is used
for this.)
3.5. Synchronizing a collection
DeftT works on unicast (as a special case of multicast) links, but is
designed to take full advantage of a multicast subnet (e.g., link-
level IPv6 multicast on broadcast media) with syncps orchestrating
collection-based communications. Members' syncps modules interact on
a multicast subnet to keep their collections synchronized. The
following example illustrates member actions and communications to
synchronize a collection (see also the sequence diagram in
Figure 13).
Starting with all members _connected_ to the collection (having
confirmed publication of their identity credentials) and with an
empty *msgs* collection (i.e., no applications have active
Publications), member2's application passes content to its DeftT via
an mbps.publish(). The content is packaged into a Publication (p1)
and passed to syncps which creates and sends a cAdd PDU. The cAdd
uses a hash of the shared (empty) cState as its cState identifier
(third component of the Name -- see Section 3.3.1.2 item 1) to
indicate the Publication(s) it carries are additions to the
collection in that state. Member2's new local cState (containing p1)
is scheduled to be sent at a delay of the subnet's dispersion time
(_d)_ plus a small random value (_r_). Dispersion time is an
estimate of the expected time for a cAdd to reach every member's
collection. It may be a fixed or adaptive estimate and syncps is
robust to inaccuracies: an overestimate may lead to longer delays and
an underestimate may lead to more cState traffic on the channel.
Members receive and validate the cAdd, then extract and validate p1,
passing it to subscriptions. Each member schedules a sendCState
Nichols, et al. Expires 16 February 2025 [Page 39]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
after a small random delay _r_. (Scheduling a new sendCState cancels
any pending sendCState.) When the sendCState timer expires, a new
local cState is created with the IBLT of the collection (which will
contain p1). This cState's expiration time is scheduled (value
significantly longer than _d_) and the member sends the cState unless
it is _suppressed_. DeftT suppresses cStates that are identical to
one that has already been heard twice. If member2 is waiting to
confirm p1, it can do so with the first of these cStates it receives.
In Figure 13, member6 did not receive the cAdd but reception of one
of the new cStates shows the presence of p1 so member6 immediately
sends its own local cState (which has an empty collection, lacking
member2's Publication). In this example, all members receive
member6's cState, but member2, as p1's originator, responds
preferentially and sends p1 in a new cAdd immediately. All other
members set a timer (to _d+r_) to send p1. That timer is cancelled
if the member receives a cAdd responding to member6's cState that
contains p1. Meanwhile, member6 receives the new cAdd, adds p1 to
its collection and schedules a new cState for delay _r_. That cState
will be suppressed as it matches those already sent by the other
members. Now the distributed collection is synchronized with a state
of one Publication (p1). If no other application content is created,
cStates will be sent at ~cStateLifetime. On the channel, we will see
one cState per ~cStateLifetime since each overlaps enough to suppress
others. When p1 expires, it will be removed at each local collection
and the subsequent cState will show an empty collection.
(Artwork only available as svg: ./figs/syncseq-rfc.svg)
Figure 13: Seven members using DeftT on a multicast subnet
Although Figure 13 shows one Publication at a time for clarity, the
logic applies if multiple members are publishing simultaneously or at
close intervals (less than _d_ or the cStateLifeTime). Distributed
collections are always _moving_ toward synchronization but during
periods of intense interaction, times when all members are
synchronized may be infrequent; this is not problematic.
3.6. Distributors
Distributors implement services a Deft requires for its operation.
Distributors optional to general operation are specified in the
communication schema.
Nichols, et al. Expires 16 February 2025 [Page 40]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3.6.1. Certificate distributor
DeftT's certificate distributor is a required module. It implements
a collection of all the signing chain certificates in the Domain.
When a new DeftT is instantiated, it must publish all the
certificates from its identity bundle as well as its locally created
signing certificate. This joining process was shown in Figure 2.
Since many certificates in a member's chain are shared, that will be
reflected in each cState and those certs will not be sent on the
subnet. A member DeftT must receive a cState showing its signing
chain in another member's local collection before a DeftT can be
considered "connected" to the trust domain. This ensures there is at
least one other member that can receive the PDUs it sends.
3.6.2. Group key distributors
Group key distributors are optional in DeftT but required, and
automatically supplied, if encryption is specified in the schema.
When present, they are instantiated after their local certificate
distributor has "connected." The example implementation contains two
types of group key distributors. A group key distributor handles
creation and distribution of a single symmetric key to all members of
the Domain to use to encrypt either Publications or PDUs (if both are
encrypted, there is a group key distribuor for each). A subscriber
group key distributor distinguishes subscribers that can decrypt PDUs
and/or Publication and publishers that encrypt PDUs and/or
Publications (a member can be both subscriber and publisher). The
group key distributor is briefly described here.
A trust domain using group key encryption must have at least one
member with the attribute or capability of "keymaker" in its identity
chain. Keymaker-capable members of a Domain elect a keymaker that
makes a new symmetric encryption key upon winning the election. The
non-keymakers publish key requests that the keymaker uses to create a
list of current members. Requests and the symmetric key both have
limited lifetimes. The keymaker uses each member's signing cert to
encrypt a copy of the current key and creates and publishes as many
Publications as needed to carry all the encrypted keys. In these
Publications, entries are indexed by the thumbprint of the associated
signing cert and the range of thumbprints is used in the Publication
name. Members only accept such Publications from keymaker-capable
signers and, in case of conflict, use the key sent by a member whose
signing cert thumbprint is the smallest.
Nichols, et al. Expires 16 February 2025 [Page 41]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
If the keymaker receives a new key request in between making new
keys, a copy of the key will be encrypted for it and published.
There is no explicit revocation but a blacklist can be implemented
and either published or passed from an application and a new group
key can be made and distributed to non-blacklisted members ahead of
the normal schedule.
3.6.3. Other distributors
Distributors may be used for other types of key distribution and for
distributing other types of information, e.g. blacklisted members or
domain statistics.
3.7. Schema-based information movement
Although the Internet's transport and routing protocols emphasize
universal reachability with packet forwarding based on destination, a
significant number of applications neither need nor desire to transit
the Internet (e.g., see [RFC8799]). This is true for a wide class of
OT applications. Further, liberal acceptance of packets while
depending on the good sending practices of others leaves critical
applications open to misconfiguration and attacks. Internet
protocols use header information to tell them how to forward packets;
A DeftT PDU's header only contains a sync zone id and a collection
name. Each DeftT has a trust management engine with a copy of rules
(a schema or subschema). DeftT *only* creates and moves its
Publications in accordance with the fully specified communication
schemas and never moves a PDU between sync zones. This approach
differs in both intent and execution from Internet forwarding. It
may not be appropriate for all use cases but offers new opportunities
to address the specific security requirements of many Limited Domain
use cases.
DeftT PDUs on the same subnet may be in different sync zones or trust
domains and DeftT sync zones in the same trust domain may be on
different subnets. In some cases, it is useful to define sync zones
whose DeftTs have a compatible, but more limited, version of the
trust domain's communication schema which is itself complete as a
communication schema. This subschema concept was introduced in
Section 1.3 and further discussed in Section 4. "Compatible" means
there is at least one Publication type and associated signer
specification in common or one schema may be a subset of the other.
Different subschemas may be deployed for sync zones on the same
subnet or on different subnets. A subschema cert will have a
different thumbprint from that of the full trust domain and different
sync zones can be identified by the thumbprint of the (sub)schema in
use.
Nichols, et al. Expires 16 February 2025 [Page 42]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
For example, a unicast link may be used to connect two remotely
located subnets of the same trust domain and only certain types of
Publications should pass through the unicast link. Relays can be
used where the DeftTs on the unicast link have a restricted subschema
(e.g. Figure 14-right). Further, different sync zones on the same
subnet might be used where certain members have more limited access,
either due to the technology of their devices or to restrict their
access (e.g., guests of a network). Relays could limit Publications
simply by filtering Publications or subscribing to subsets of
Publications but use of a subschema in different sync zones provides
_enforcement_ of Publication movement.
Both cStates and cAdds contain their sync zone id and are not moved
between subnets while Publications are defined in the trust domain's
communication schema and can move to any DeftT that can validate
them. In the case of DeftTs on the same subnet but in with different
(sub)schema certs, the cState and cAdd PDUs are differentiated by the
sync zone id (thumbprint of the (sub)schema certificate as in
Section 3.3.1.1 item C1). The sync zone id is used at the face
module to determine whether or not to process a PDU. A DeftT's
*syncps* manages a particular collection on a single subnet. _Relays_
move Publications between separate sync zones of the same trust
domain by moving Publications between the relay's multiple DeftT
instances.
A _relay_ is implemented [DCT] as an application running on a device
with a DeftT interface in each sync zone (two or more) Figure 14.
Each DeftT participates using a communication identity valid for the
schema used by the DeftT. Only Publications (including certs) are
relayed between DeftTs and the Publication must validate (to the
extent possible) against the schema of each DeftT. Consequently cAdd
encryption is unique per sync zone while Publication encryption holds
across the domain.
Since relay applications merely pass Publications in the msgs
collection, their DeftT API module (a "shim", see Section 3.1)
performs _pass-through_ of valid Publications. As a consequence and
a further security measure for boundary devices, relays have no need
for Publication encryption keys; this is enforced by use of a
capability cert in relay identity chains. (The group symmetric key
is *never* given to an identity with the relay capability in its
chain.) For example, if we added a relay definition to the example
of Figure 5:
rlyCert: _domain/"relay"/_myid/_certFormat <= rlyCap
capCert: _domain/"CAP"/capId/capArg/_certFormat
rlyCap: capCert & {capId: "RLY", capArg: _} <= domainCert
Nichols, et al. Expires 16 February 2025 [Page 43]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
The relay of Figure 14-left is on three separate wireless subnets.
If all three DeftTs are using an identical schema, a new validated
cert added to the cert store of an incoming DeftT is then passed to
the other two, which each validate the cert before adding to their
own cert stores (superfluous in this case, but not a lot of overhead
for additional security). When a valid Publication is received at
one DeftT, it is passed to the other two DeftTs to validate against
their schemas and published if it passes.
(Artwork only available as svg: ./figs/relayextend-rfc.svg)
Figure 14: Relays connect subnets
A relay may have different identities and schemas for each DeftT, but
its DeftTs _must_ have the same trust anchor and schemas that are
identical copies, proper subsets or overlapping subsets of the domain
schema. Publications that are undefined for a particular DeftT are
silently discarded if they do not validate upon relay, just as they
are when received from a face. This means the relay application of
Figure 14-left can remain the same but Publications will only be
published to a different subnet if its DeftT has that specification
in its schema. In addition, relays may filter Publications at the
application level or restrict subscriptions on some of their DeftT
interfaces. Figure 14-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 subnets. Everything on each local subnet shows up
on the other. A communication schema 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 14-right, local
communication for subnet 1 can be kept local while subnet 2 might
send commands and/or collect log files from subnet 1.
More generally, relays can form a mesh of broadcast subnets with no
additional configuration (i.e., relays on a broadcast network do not
need to be configured with others' identities and can join at any
time). The mesh is efficient: Publications are only added to an
individual DeftT's collection once regardless of how it is received.
Relays with overlapping broadcast physical media will only add a
Publication to any of its DeftTs *once*; syncps ensures there are no
duplicates. More on the applicability of DeftT meshes is in
Section 6.
Nichols, et al. Expires 16 February 2025 [Page 44]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
3.8. Performance
Measurements and profiling have been performed using examples from
the open source [DCT] proof-of-concept codebase (v11.2) running on an
Apple M1-max and an x86 linux-based machine. On both machines the
code was compiled with clang-16 at optimization level -O3 but no
additional or platform-dependent flags. An application
examples/hmIoT/app2.cpp [DCT] with an operator role issue commands to
app2.cpp's with device roles which are expected to perform the
operation (e.g., lock the door) and report their subsequent status
(e.g., locked). The schema used calls for EdDSA signing of
Publications and AEAD encryption of cAdds. Measuring the time from
the appearance of the cAdd carrying the command publication until the
appearance of the cAdd carrying the status publication captures the
time to receive a cAdd, process its Publication, convert the
resulting application message into a Publication and then add the
Publication to its local collection and package it and send it in a
cAdd. On ethernet with negligible transmission delay, the Apple
platform takes ~200us and the linux x86 ~300us.
Memory use is dominated by the certificate store (the cert
collection) and the msgs collection of Publications carrying
application content. In the former case, each certificate is ~300
bytes and a member only stores its own signing chain as well as those
of members that create Publications the communication schema says
they can accept. Measurement has shown memory use to be consistently
less than 2 Mbytes.
The home IoT example was profiled on an M1-max using Apple's
_instruments_ tool. The time spent was classified both by the DeftT
action it was invoked in and the codebase it was part of (DeftT, the
libsodium cryptographic library, or the Boost async I/O library
interface the to system's UDP/IP networking and scheduling). For
each action, times were normalized by the total time spent on the
action. The numbers in the table below are percentages of the total
time taken for the action in the first column. For each codebase,
the number given is the percentage time taken by its busiest
function. The name of the action's largest item, irrespective of
codebase, shown in the final column.
Nichols, et al. Expires 16 February 2025 [Page 45]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
+===================+========+=========+=========+==================+
| action | DeftT% | crypto% | system% | largest item |
+===================+========+=========+=========+==================+
| make msg-to-Pub | 32 | *68* | 0 | EdDSA signing |
+-------------------+--------+---------+---------+------------------+
| send cAdd | 3 | 4 | *84* | sendTo syscall |
+-------------------+--------+---------+---------+------------------+
| send cState | 10 | 0 | *80* | sendTo syscall |
+-------------------+--------+---------+---------+------------------+
| handle cAdd | 1 | 6 | *81* | recvFrom syscall |
+-------------------+--------+---------+---------+------------------+
| handle Pub-to- | 4 | *94* | 0 | EdDSA validation |
| msg | | | | |
+-------------------+--------+---------+---------+------------------+
| handle cState | 3 | 0 | *73* | recvFrom syscall |
+-------------------+--------+---------+---------+------------------+
Table 3: Profiling Results from an Apple M1-max
Note that none of the absolute times are large. For example, the
EdDSA validation that accounts for 94% of incoming Pub-to-msg
handling takes 22 microseconds and the corresponding signature that's
68% of make msg-to-Pub takes 16 microseconds. In general, send and
receive syscall handling dominates and these delays are experienced
by any transport protocol. Roughly half of this appears to be due to
Boost's lock-heavy "executor" model which might be fixed by switching
to c++20 co-routines. A real-time OS like Zephyr would be expected
to remove much of the remaining system cost.
Thanks to the availability of hardware AES accelaration on both Arm
and Intel platforms, the time to perform the cAdd AEGIS crypto is
quite small: 300ns to simultaneously validate and decrypt on either
platform. These measurements convince us that users and industries
promoting the use of signing in networking would do well to focus on
accelerating asymmetric key functions.
Table 4 shows the fixed and per-byte signing and validation costs for
the current reference implementation [DCT] as measured by its
time_signing.cpp tool. Hardware accelerated AEGIS-128L and AEGIS-
256, were added in Sep 13, 2023 libsodium 1.0.19 release. AEAD-AEGIS
is 4.5x faster than AEAD-IETF on the Intel platform and 7.8x faster
on the Arm platform. Given the rapid evolution of high quality
crypto algorithms and implementations, it's important that
infrastructure and application code that relies on crypto be able to
keep up. It took less than a day to add an AEGIS sigmgr to [DCT] and
a one line change to the home IoT schema to switch the home IoT apps
to use it. Since the sigmgr API is generic, _no_ app or DeftT code
changed.
Nichols, et al. Expires 16 February 2025 [Page 46]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
+==================+==================+===================+
| operation | Intel | Arm M1-max |
+==================+==================+===================+
| EdDSA signing | 21us + 5.3us/KB | 15us + 3.8us/KB |
+------------------+------------------+-------------------+
| EdDSA validation | 58us + 2.6us/KB | 41us + 1.9us/KB |
+------------------+------------------+-------------------+
| AEAD encryption | 735ns + 885ns/KB | 437ns + 2430ns/KB |
+------------------+------------------+-------------------+
| AEAD decryption | 719ns + 853ns/KB | 433ns + 2420ns/KB |
+------------------+------------------+-------------------+
| AEGIS encryption | 209ns + 211ns/KB | 176ns + 147ns/KB |
+------------------+------------------+-------------------+
| AEGIS decryption | 173ns + 192ns/KB | 205ns + 141ns/KB |
+------------------+------------------+-------------------+
Table 4: Measured Sigmgr per-operation times
3.9. Congestion control
Each DeftT 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 it 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 DeftTs having
the same collection name on each subnet with a *Publication* Relay
between them but DeftT _never_ forwards *PDUs* between subnets. It
is, of course, possible to run DeftT over an extended broadcast
network like a PIM multicast group but the result will generally
require more configuration and be less reliable, efficient and secure
than DeftT's self-configuring peer-to-peer Relay mesh.
DeftT sends _at most one_ copy of any Publication over any fully
connected subnet, _independent_ of the number of publishers and
subscribers on the subnet. Thus the total DeftT traffic on a subnet
is strictly upper bounded by the application-level publication rate.
As described in Section 3.2, DeftTs publish a cState specifying the
set elements they currently hold. If a DeftT receives a cState
specifying the same elements (Publications) it holds, it doesn't send
its cState. Thus the upper bound on cState publication rate is the
number of members 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 member 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 members - 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.
Nichols, et al. Expires 16 February 2025 [Page 47]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
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 trust domain over a path whose
bandwidth delay product is many times larger than typical subnet MTUs
(1.5-9KB), the one-outstanding-PDU per member constraint can result
in poor performance (1500 bytes per 100ms transcontinental RTT is
only 120Kbps). DeftT can run over any lower layer transport and
stream-oriented transports like TCP or QUIC allow for a 'virtual MTU'
that can be set large enough for DeftT to relay at or above the
average publication rate (the default is 64KB which can relay up to
5Mbps of Publications into a 100ms RTT). In this case there can be
many lower layer packets in flight for each DeftT cAdd PDU but their
congestion control is handled by TCP or QUIC.
4. Schemas for the Defined-trust management engine
OT applications are distinguished (from general digital
communications) by well-defined roles, behaviors and relationships
that constrain the information to be communicated (e.g., as noted in
[RFC8520]). The capabilities and attributes of Things can be
characterized in structured abstract profiles that can be machine-
readable (e.g., [ONE][RFC8520][ZCL]). Energy applications in
particular have defined strict attribute- and role-based access
controls [IEC] but currently proposed enforcement requires the
interaction of a number of mechanisms across the communications stack
[NERC]. In Defined-trust Communications, structured profiles and
rules strictly define permitted behaviors including what types of
messages can be issued or acted on; undefined behaviors are not
permitted. These rules, along with local configuration, are
incorporated directly into the schemas used by DeftT's integrated
trust management engine both to prohibit undefined behaviors and to
construct compliant Publications. This not only provides a fine-
grained security but a highly _usable_ security, an approach that can
make an application writer's job easier since applications do not
need to contain local configuration and security considerations.
DCT [DCT] includes a language (_VerSec_) for expressing the rules of
communication, its compiler, and other tools to create the
credentials a DeftT needs at run-time. DCT is example code that is
provided as open source that is frequently updated to improve
features and performance but may have bugs or unoptimized features in
any particular release.
Nichols, et al. Expires 16 February 2025 [Page 48]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
4.1. Communication schemas
Defined-trust's use of communication schemas is influenced by
[SNC][SDSI] and the field of _trust management_ defined by Blaze et.
al. [DTM] as the study of security policies, security credentials,
and trust relationships. and refined by Li et. al. [DLOG].
Communications schemas also have roots in the _trust schemas_ for
Named-Data Networking, described in [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." DeftT's
use is based on an approach introduced in [NDNW] and extended with
introduction of the declarative VerSec schema language in
[DNMP][IOTK][DCT]. Here a 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" to do, not "how" to do it. As noted on paragraph 4
of [DLOG]:
| a _declarative trust management specification_ based on a formal
| foundation guarantees all parties to a communication have the same
| notion of what constitutes compliance.
The schema is critical to Defined-trust Communications, adopting the
more descriptive term _communication schema_ (or just _schema_ where
its usage is clear) for the rules that define the communications of a
trust domain. The schema details the meaning and relationship of
individual components of the filename-like names (URI syntax
[RFC3986]) of Publications and certificates. The intent for a
domain's communications is expressed in fine-grained rules: "who can
say what." Credentials that define "who" are specified along with
complete definitions of "what". Defined-trust communications has
been targeted at OT networking where administrative control is
explicit and it is not unreasonable to assume that identities and
communication rules can be securely configured at every device. A
single schema, securely provided to all members, provides the same
protection as dozens of manually configured, per-node ACL rules.
A VerSec compiler, _schemaCompile_, and examples are included with
the Defined-trust Communications Toolkit [DCT]. The compiler checks
the formal soundness of the VerSec text specification (case 1 above)
then converts it to a signed, compact, binary form. The compiler
Nichols, et al. Expires 16 February 2025 [Page 49]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
also reports diagnostics and includes a digraph listing that can be
used to confirm that the intent of the schema has been implemented
(and to flag problems). The binary form is used by DeftT to build
(case 2) or validate (case 3) the Publications (format covered in
Section 3.3.1.3). As certificates are a type of Publication, they
are distributed and validated using DeftT, though they are subject to
additional constraints (Section 3.3.1.4).
4.2. VerSec schema description language
VerSec follows LangSec principles to minimize misconfiguration and
attack surface. Its structure is amenable to a forms-based input or
a translator from the structured data profiles often used by
standards [ONE][RFC8520][ZCL]. As declarative languages are
expressive and strongly typed, they can express the constructs of
these standards in their rules. VerSec continues to evolve and add
new features as its application domain is expanded; 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.
VerSec describes _constraints_ on both the layout and components of
names and on the structural and signing relationships between names;
its statements simply state facts that can be given in any order.
The language can only produce entities (Publications, certificates,
signing chains, etc.) with a fixed layout so the run-time
validatation is loop- and recursion-free. All alternatives (e.g.,
different signing chains for the same Publication) must be explicitly
enumerated so validation and construction are constant time and
space. The language is intended for trust domains with a common,
local trust anchor. This means the set of signing chains for any
schema must be a directed acyclic grap (DAG). This property is
verified at compile time and exploited to make the runtime testing
for signing-loops stateless and O(1).
4.2.1. Lexical building blocks
_Names_ consist of a sequence of _components_ separated by slashes /
Each _component_ is an _expression_ that can be:
* a literal string enclosed in quotes "
* an _identifier_
* an internal function _call_
* an _expression_ enclosed in parens
* two expressions separated by a vertical bar |.
Nichols, et al. Expires 16 February 2025 [Page 50]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
_Identifiers_ are a sequence of letters, digits and underscores
starting with a letter, underscore or sharp sign. A leading
underscore indicates that the component's value will be derived from
schema rules and it _must_ resolve to a concrete value (literal
string, function call or signing chain component name) for the schema
to be correct. Component identifiers that don't start with "_" are
_parameters_ that must be supplied at run time.
_Comments_ start with "//" and terminate at the end-of-line.
Comments, blank lines and whitespace are ignored.
A schema consists of a series of _statements_. A statement can
describe either a _definition_ or a _signing chain_. Statements must
be terminated by a comma or newline.
| Actually, all statements must be terminated by a comma but, as
| in javascript, the scanner will automatically insert a line
| terminator before a newline if the statement is complete
| (doesn't end with a binary operator, "{" or "(").
4.2.2. Definitions
A _definition_ consists of an _identifier_ followed by a colon
followed by an _expression_. Semantically it means that replacing the
identifier with the expression, or vice-versa, doesn't change the
meaning of the schema.
The _expression_ must be a _Name_ (sequence of components separated
by slashes) or another definition's identifier. It can be followed
by (optional) _component constraints_ and/or _signing constraints_.
For example,
#mypub: /_domain/_topic/param
req: #mypub & {_topic: "request"}
defines #mypub as a three component name whose components can be
referenced as '_domain', '_topic' and 'param' and req as a
specialization of it whose __topic_ component is constrained to be
the literal string "request".
In _Publication definitions_, like #mypub above, the expression must
be a _Name_ which is used to define the Publication's _component tag
identifiers._ Publication variant definitions, like req above, start
with the parent Publication's identifier followed by constraints to
specialize it.
Nichols, et al. Expires 16 February 2025 [Page 51]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Publication identifiers that start with a sharp sign (#) are
"exported": they appear in the binary schema together with their tags
plus the parameters and optimized, compiled form of component
constraints and signing constraints of all their variants. The
current convention is that the first such definition describes
publications in the *msgs* collection and the remainder specify
runtime constraints such as signing algorithms (e.g., Figure 11). We
plan to add _collections_ as first-class entities in the VerSec
language which will remove the need for this hack.
4.2.2.1. Component Constraints
A _component constraint_ is an open brace followed by one or more
constraint terms followed by a closing brace. Each constraint term
consists of a _tag identifier_ followed by a colon followed by an
expression followed by a comma or newline. The semantics of a
component constraint is that _all_ its terms must hold, e.g.,
#mypub & {_topic: "req", param: "status"} | {_topic: "cmd", param: "start"}
resolves to /_domain/"req"/"status" and /_domain/"cmd"/"start" while
#mypub & {_topic: "req"|"cmd", param: "status"|"start"}
resolves to the full cross product {req,cmd} x {status,start}.
An ampersand (&) must separate the component constraints from the
definition's initial _Name_ or _identifier_. As the examples show,
multiple component constraints can be given, separated by | or &. The
two operators have equal precedence so if a mixture of | and & is
used, parens are needed to ensure the intended evaluation order.
4.2.2.2. Signing Constraints
A _signing constraint_ consists of a <= (signed-by operator) followed
by one or more _definition identifiers_ separated by | operators,
e.g.,
cmd: #mypub & {_topic: "cmd"} <= opCert
req: #mypub & {_topic: "req"} <= opCert | userCert
says that cmd Publications must be signed by an opCert while req
Publications can be signed by either an opCert or a userCert. If the
domain signing authority only signs an opCert for designated
operators, the semantic enforced here by the run-time library is
"operators can issue requests and commands but normal users can only
issue requests". This is enforced _at the subscriber(s)_ via their
validating that cmds are signed by an opcert, so a compromised
Nichols, et al. Expires 16 February 2025 [Page 52]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
publisher forging a cmd or signing one with a userCert produces at
most an "attempted security breach" log message. (A compromised
publisher with access to a valid opcert is still a threat but that
needs to be addressed by key hygiene measures like secure signing
enclaves and limited key lifetimes.)
4.2.3. Signing Chains
A _signing chain_ is a sequence of _identifiers_ separated by <=
operators. All of the identifiers must be defined as Publications or
certs somewhere in the schema. The chain doesn't have to include all
the certs on the path from the Publication to the trust root as
_signing chain_ and _signing constraint_ information is interpreted
as edges in a _signing DAG_ that defines all the legal chains for the
schema. (For diagnostic purposes the compiler debug option adds the
DAG in graphviz dot format to its output.) The DAG is checked to
insure:
* all nodes in the graph have been defined
* the cert graph is a DAG (there are no cycles)
* there is only one trust anchor (the DAG has a single sink)
* all signed Publications have path(s) to the trust anchor
A Publication's entire signing chain, not just its immediate signing
cert, is used to establish provenance, authorizations, capabilities
and trust. If a chain has variants that are not distinguished by the
immediate signer, enough of the chain should be specified to
disambiguate.
4.2.4. Syntax and Semantics
Either a _Publication_ or a _certificate_ is the first element of
each signing chain. The remaining elements must all be
_certificates_, each of which cryptographically signs the element
preceding it. The final element must be a self-signed _Trust Anchor_
so it signs both the preceding element and itself. This validation
structure allows not just the publication's components but all the
components in the chain to be used to enforce policy when building
and validating publications. This is normally done implicitly via
signing rules as above, but it can also be done explicitly by
mirroring components within a cert chain. For example, for forensic
logging it could be useful to know who issued the cmd and req
publications of the previous example. Say opCert and userCert are
defined as roleCert instances and roleCert is defined with a _role
component containing the type of role and a _roleID component
containing a person identifier like an employee number or name:
Nichols, et al. Expires 16 February 2025 [Page 53]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
roleCert: /_domain/_role/_roleID
opCert: roleCert & {_role: "operator"}
userCert: roleCert & {_role: "user"}
then adding a roleID component to #mypub:
#mypub: /_domain/_topic/_roleID/param
will cause the runtime to set that component to the value of _roleID
in the signing cert when the publication is built and verify the
component matches the signing cert's when the publication is
received. For non-parameter identifiers like _roleID, the compiler
creates runtime schema _component correspondence_ information that
allows both the builder and verifier to ensure that _all_ signing
chain components with that identifier contain the same value.
_Parameters_ and _correspondences_ are essentially schema 'variables'
that are bound to concrete values by the runtime to create a
_logically grounded_ (fully specified and verifiable) Publication.
To ensure that all generated Publications are grounded, the runtime
schema describes all the _parameters_ needed and the publication
builder method throws an error if any of them are not supplied. For
_correspondences,_ the compiler checks that all non-parameter
identifiers in a Publications also appear in at least one cert of the
Publication's signing chain(s) and terminates with an error if not.
(If no cert in the chain contains the identifier, that component
can't be filled in with a concrete value at runtime so the schema
doesn't produce grounded Publications and is in error.) Certs don't
need this check because, at runtime, certs are pre-built, grounded
objects and the runtime only has to check, once, that they meet the
constraints of the schema.
4.3. Schema examples
(Figure 15) shows a simple communication schema that defines the
format of all Publications in this domain's *msgs* collection to be
an "#mpub", a six component name. The strings between the slashes
define the tags used to reference components in the VerSec rules and
in the run-time schema library. For example, the tag of the final
component is __ts_ and the & {_ts: timestamp()} constraint on the
name makes the component's TLV type a _Timestamp_ (Section 3.3.2)
which will be set to the current time when an #mpub is built and be
validated as a timepoint when received.
The first component gets its value from the variable "_domain" and
#pubPrefix is set as this value so that the schema contains
information on what part of the name is considered common prefix.
(This is a common prefix for _all_ Publications in this domain, not
Nichols, et al. Expires 16 February 2025 [Page 54]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
just those in *msgs*.) The schema puts no constraints on other name
components of an #mpub but requires that #mpub Publications be signed
by (<=) a mbrCert. Thus the schema enforces that only enrolled
domain members can publish.
The Validator lines specify cryptographic signing/validation methods
for an #mpub, the domain certs, and the PDU that carries
Publications. Here all use EdDSA signing.
In operation, this schema puts no constraints on #mpubs inner four
name components (additional constraints could be imposed by the
application but they won't be enforced by DeftT). When it starts, a
DeftT adds its signing certificate chain to the domain certificate
collection (see Section 5.2), thus announcing its identity to all
other members. Using the preconfigured trust anchor and schema, any
member can verify the identity of any other member. This approach
means members are not preconfigured with identities of other members
and new entities can join at any time. Member signing certificates
must adhere to the schema; Publications or PDUs with unknown signers
are discarded. The timestamp component is used to prevent replay
attacks.
#mpub: /_domain/trgt/topic/loc/arg/_ts & { _ts: timestamp() } <= mbrCert
#pubPrefix: _domain
mbrCert: _domain/_mbrType/_mbrId/_certinfo <= netCert
netCert: _domain/_certinfo
#msgsValidator: "EdDSA"
#certValidator: "EdDSA"
#pduValidator: "EdDSA"
_domain: "example"
_certinfo: "KEY"/_/"dct"/_
Figure 15: An example communication schema in VerSec [DCT]
This schema cryptographically identifies the source of every
publication and ensures that only enrolled members can publish but
offers no privacy beyond that supplied by the lower level
communications media. DeftT includes an AEGIS AEAD validator
subsystem that leverages each subnet's certificate collection to
securely distribute symmetric-encryption nonce cover keys to all
members on the subnet. This results in PDU privacy and integrity
equivalent to TLS-1.3 at zero-cost (Table 4 measurements show that
AEGIS encrypts/decrypts at memory speed).
Nichols, et al. Expires 16 February 2025 [Page 55]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Two changes are required to the above schema to enable this. First,
#pduValidator should be changed to "AEAD" instead of "EdDSA".
Second, the definition for a _keymaker capability_ cert should be
added and made an alternative signer of mbrCerts:
kmCap: _domain/"CAP"/"KM"/_capArg/_certinfo <= netCert
mbrCert: _domain/_mbrType/_mbrId/_certinfo <= kmCap | netCert
If a schema requires that *msgs* PDUs be encrypted, all subnet
members need to use the _same_ randomly-generated encrypt/decrypt
cover key to communicate so DeftT automatically creates a local
_group key distributor_ (Section 3.6.2) to obtain it. When each
member starts, this distributor checks its group-key collection to
see if a _keymaker_ has been elected. If not and if the member's
signing chain contains a KM capability, it will start/join a Paxos-
like election by publishing a candidate message to the group-key
collection. When a keymaker has been elected, members publish
requests for the current cover key and the keymaker publishes replies
that contain the group key encrypted using the requesting member's
public signing key. The keymaker retrieves the member's public
signing key from its local store of validated certificates by using
the key locator of that member's signed request.
In addition to certificate capabilities like KM, VerSec and DeftT
allow for Attribute-Based Access Control (ABAC) [NIST] using
attributes of the subject, object, action and environment to
determine authorization. ABAC takes advantage of the system's
context to offer the fine-grained control of capability enumeration
but with much less configuration and DeftT uses the schema to manage
the ABAC _locally_ at each member. For example, returning to the
Figure 15 schema, define the members as either _sensors_ (whose job
is to report measurements), _loggers_ (whose job is to solicit then
archive _sensor_ reports) or _admins_ (whose job is to configure
_sensors_ and _loggers_). This has the communication pattern that
_loggers_ publish request messages to solicit _sensor_ status
messages and _admins_ publish config messages to _sensors_ and
_loggers_ who reply with state messages. Six rules have to be added
to the example to express and enforce this communication pattern:
three to distinguish the three member types and three to describe
what they can say.
sensorCert: mbrCert & { _mbrType: "sensor" } <= netCert
loggerCert: mbrCert & { _mbrType: "logger" } <= kmCap | netCert
adminCert: mbrCert & { _mbrType: "admin" } <= netCert
sensorMsg: #mpub & {topic:"status"|"state"} <= sensorCert
loggerMsg: #mpub & {topic:"request"|"state"} <= loggerCert
adminMsg: #mpub & {topic:"config"} <= adminCert
Nichols, et al. Expires 16 February 2025 [Page 56]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
An AEAD kmCap was included in the above to show that ABAC and
capabilities are not antagonists. In this case, _sensors_ have
limited processors and are often battery powered and _admins_ are
people who come and go. Since _keymaker_ is a critical, always on
infrastructure service, _loggers_ are the only members qualified to
be keymakers but whether any particular _logger_ gets a kmCap is the
system administrator's decision which is what the <=kmCap|netCert
signing constraint says.
Communication schema changes are the _only_ changes required in order
to increase security and add privacy: neither code nor binary needs
to change and DeftT handles all aspects of validators. This unique
approach of integrating identity and communication rules into the
transport makes it relatively to produce and evolve secure systems.
Converting desired behavioral structure into a schema is the major
task of applying Defined-trust Communications to an application
domain. Once completed, all the deployment information is contained
in the schema. Although a particular schema cert defines a
particular trust domain, the text version of a schema can be re-used
for related applications. For example, a home IoT 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.
5. Certificates and identity bundles
Defined-trust's approach is partially based on the seminal SDSI
[SDSI] approach to create user-friendly namespaces that establish
transitive trust through a certificate (cert) chain that validates
locally controlled and managed keys, rather than requiring a global
Public Key Infrastructure (PKI). When certificates are created, they
have a particular context in which they should be utilized and
trusted rather than conferring total authority. This is particularly
useful in OT where communicating entities share an administrative
control and using a third party to certify identity is both
unnecessary and a potential security vulnerability. Well-formed
certificates and identity deployment are critical elements of this
framework. This section describes certificate requirements and the
identity _bundles_ that are securely distributed to trust domain
members. (DCT includes utilities to create certs and bundles.)
Nichols, et al. Expires 16 February 2025 [Page 57]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
5.1. Obviate CA usage
Use of third party certificate authorities (CAs) is often
antithetical to OT security needs. Any use of a CA (remote or local)
results in a single point of failure that greatly reduces system
reliability. An architecture with a single, local, trust root cert
(trust anchor) and no CAs simplifies trust management and avoids the
well-known CA federation and delegation issues and other weaknesses
of the X.509 architecture (summarized at [W509], original references
include [RSK][NVR]). DCT certificates (see Section 3.3.1.4) can be
generated and signed locally (using supplied utilities) so there is
no reason to aggregate a plethora of unrelated claims into one cert
(avoiding the Aggregation problem [W509]).
A DCT cert's one and only Subject Name is the Name of the Publication
that contains the public key as its content and neither name nor
content are allowed to contain any optional information or
extensions. Certificates are created with a lifetime; local
production means cert lifetimes can be just as long as necessary (as
recommended in [RFC2693]) so there's no need for the code burden and
increased attack surface associated with certificate revocation lists
(CRLs) or use of on-line certificate status protocol (OSCP). Keys
that require longer lifetimes, like device keys, get new certs before
the current ones expire and may be distributed through DeftT (e.g.,
using a variant of the group key distributors in DCT). If there is a
need to exclude previously authorized identities from a domain, there
are a variety of options. The most expedient is via use of an AEAD
cAdd or Publication validator by ensuring that the group key maker(s)
of a domain exclude that entity from subsequent symmetric key
distributions until its identity cert expires (and it is not issued
an update). Another option is to publish an identity that supplants
that of the excluded member. A new schema can be distributed at any
time but the receiving application will need to start a new DeftT
using that schema though it can run in parallel with the old DeftT
for some period of time. Though more complex, it is also possible to
distribute a new schema and identities (without changing the trust
anchor), e.g., using remote attestation via the TPM.
From Section 4, a member is granted attributes in the schema via the
certs that appear in its identity chain. Identity certs are _always_
accompanied by their full chain-of-trust, both when installed and
when the member publishes its identity to the cert collection. Every
signing chain in the domain has the same trust anchor at its root and
its compliant format specified in the schema. Without the entire
chain, a signer's right to issue Publications cannot be validated.
Cert validation is according to the schema which may specify
attributes and capabilities for Publication signing from any
certificate in the chain. For this model to be well founded, each
Nichols, et al. Expires 16 February 2025 [Page 58]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
cert's *key locator* must _uniquely_ identify the cert that actually
signed it. This property ensures that each locator resolves to one
and only one signing chain. A cert's key locator is a *thumbprint*,
a SHA256 hash of the _entire_ signer's Publication (name, content,
key locator, and signature), ensuring that each locator resolves to
one and only one cert and signing chain. Use of the thumbprint
locator ensures that certs are not open to the substitution attacks
of name-based locators like X.509's "Authority Key Identifier" and
"Issuer" [ConfusedDep][CAvuln][TLSvuln].
5.2. Identity bundles
Identity bundles comprise the certificates needed to participate in a
trust domain: trust anchor, schema, and an identity chain. The
private key corresponding to the leaf certificate of the identity
chain should be installed securely when a device is first
commissioned (e.g., out-of-band) for a network while the public certs
of the bundle may be placed in a file in a well-known location or
may, in addition, have their integrity attested or even be encrypted.
Figure 16 shows the steps involved in creating identity bundles and
their 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: ./figs/tools.config-rfc.svg)
Figure 16: Creating identity bundles
The process in Figure 16 can be used to construct an identity bundle
using the example schema from Section 4.2 for a sensor with mbrId =
1. Then the bundle can be inspected using the _ls_bundle_ utility at
[DCT] showing the certs it contains. Left hand notations designate
the certs by their position in the bundle and show which cert
precedes it ("<=") in the chain. The private key for cert 3 is also
in this bundle, indicated by "key" at the first bytes of the key
value.
0 root: /example/KEY/^4c29d555/dct/23-09-20@16:36
1 <= 0: /example/schema/#mpub/KEY/^545b55ff/dct/23-09-20@16:36
2 <= 0: /example/CAP/KM/1/KEY/^77fe722e/dct/23-09-20@16:36
3 <= 2: /example/sensor/1/KEY/^d0660cc1/dct/23-09-20@16:36 key '6ca45831...
In the examples at [DCT], an identity bundle (with private key) is
given directly to an application via the command line, useful for
development, and the application passes callbacks to utility
functions that supply the certs and a signing pair separately. For
Nichols, et al. Expires 16 February 2025 [Page 59]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
deployment, good key hygiene using best current practices must be
followed e.g., [COMIS]. [DCT] examples use configured member
identities to sign locally created signing certs (with associated
private keys) and the example schemas give the format for these
signing cert names. A DeftT will request a new signing cert shortly
before expiration of the one in use. Upon each signing cert update,
only this new cert needs to be published via DeftT's cert
distributor.
In deployment, a small application manager may be programmed for two
specific purposes. First, it is registered with a supervisor [SPRV]
(or similar process control) for its own (re)start to serve as a
bootstrap for the application. Second, it can have access to the TPM
functions and the ability to create "short-lived" (hours to several
days) public/private key pair(s) that are signed by the installed
(commissioned) private identity key using the TPM. This signing key
pair is created at (re)start and recreated at the periodicity of the
signing cert lifetime. Figure 17 outlines a representative
procedure. Since the signing of the public cert happens via requests
to the TPM, the _identity_ key (used to sign the cert) cannot be
exfiltrated. The locally created _signing_ key is used in the
communications path where TPM signing overhead is prohibitive.
(Artwork only available as svg: ./figs/InstallIdbundle-rfc.svg)
Figure 17: Representative commissioning and signing key maintenance
All DCT certs have a validity period. Publication signing key pairs
(with public signing certs) are generated locally so they can easily
be refreshed as needed. Trust anchors, schemas, and the member
identity chain are higher value and often require generation under
hermetic conditions by some authority central to the organization.
Their lifetime should be application- and deployment-specific, but
the higher difficulty of cert production and distribution often
necessitates liftetimes of weeks to years.
Secure device configuration and on-boarding should be carried out
using the best practices most applicable to a particular deployment.
The process of enrolling a device by provisioning an initial secret
and identity in the form of public-private key pair and using this
information to securely onboard a device to a network has a long
history. Current and emergent industry best practices provide a
range of approaches for both 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][RFC8995], or
secure enclave or trusted execution environment (TEE) [ATZ] where
available. In that case, an authorized configurer adding a new
Nichols, et al. Expires 16 February 2025 [Page 60]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
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. Where entities have public-
private key pair identities of _any_ (e.g., non-DCT) type, these can
be leveraged for DeftT identity installation.
Updating schemas and other certificates over the deployed network
(OTA) is application-domain specific and can either make use of
domain best practices or develop custom DeftT-based distribution.
Changing the trust anchor is considered a re-commissioning. The
example here is merely illustrative; with pre-established secure
identities and well-founded approaches to secure on-line
communications, a trust domain could be created OTA using secure
identities established through some other system of identity.
6. Use cases
6.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]. 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 and
where IIoT sensors require tight security. 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
efficiently encrypted making it ideal for this use.
6.1.1. Meshing without additional configuration
IIoT sensors may be fixed or mobile (including drone-based); mobility
and envirnomental factors may cause different sensor gateways to
receive measurements from a particular sensor over time. A DeftT
mesh captures Publications _anywhere_ within its combined network
coverage area and ensures it efficiently reaches all members as long
as they are in range of at least one member that has received the
information. An out-of-service or out-of-range member can receive
all active subscribed Publications once it is in range and/or able to
communicate. DeftT forms meshes with no additional configuration
Nichols, et al. Expires 16 February 2025 [Page 61]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
(beyond DeftT's usual identity bundle and private identity key)
needed to make devices recognize one another in the trust domain. To
see how DeftT propagates information throughout a partially connected
mesh, consider Figure 18 where sensor S1's signal can reach devices
D1-D4 but not D5 and D6. (Refer to Section 3.2 and Section 3.5.)
(Artwork only available as svg: ./figs/robust-rfc.svg)
Figure 18: Members out-of-range of a Publication's originator can
receive from non-originating members
1. S1 sends a cAdd with its latest measurement Publication that is
received by D1-D4 and added to their collections after which they
synchronize their cStates which now contain this Publication
2. Either a device in range of D5 and/or D6 sends a cState that
shows the new Publication which results in a cState that lacks
the new Publication being set from D5 and/or D6. This cState
serves as a request for the new Publication. *Or* D5 and/or D6
send a periodic cState update that lacks the new Publication and
it is received by at least one of D1-D4.
3. When devices that have received the new Publication hear those
cStates without it, they wait a _dispersion delay_ (plus a small
random value) so that the originator or some other device might
respond, after which they send the Publication in a cAdd unless a
cAdd responding to the specific lacking cState is overheard
first.
6.1.2. Mixed connectivity in a challenging environment
The large physical scale of many industrial processes necessitates
that expensive cabling costs be avoided through wireless transport
and battery power. Wireless sensor deployments in an industrial
environment can suffer from signal outages due to shielding walls and
interference caused by rotating machinery and electrical generators.
In particular, nuclear power plant applications have radioactive
shielding walls of very thick concrete and security regulations make
any plant modifications to add cabling subject to expensive and time-
consuming reviews and permitting.
Consider an industrial setting where LoRa sensors collect a wide
range of information (e.g., temperature, movement/vibration, light
levels, etc.) that is broadcast in layer 2 LoRaWAN messages (see
Figure 19). The site's WiFi network includes fixed displays, mobile
tablets, and devices with both a LoRaWAN gateway interface and a WiFi
interface (Gateways). The WiFi-enabled devices can subscribe to
subsets of the information available through DeftT. Data privacy is
ensured by encrypting cAdd PDUs. Deploying several Gateways within a
single sensor's broadcast range reduces the number of lost sensor
Nichols, et al. Expires 16 February 2025 [Page 62]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
LoRa packets and the DeftT WiFi mesh is resilient against
transmission outages. DeftT Publications are sent once and heard by
all in-range members while Publications missing from one DeftT's set
can be supplied by another within range. In Figure 19 Gateways are
deployed in fixed locations near the doorways in shielded walls to
ensure connectivity of the WiFi mesh. A Controller with long-term
data storage is sited in a control room and connected via an Ethernet
cable to a Gateway that also has an Ethernet interface and runs a
DeftT relay. Mobile WiFi devices can move throughout the site and
maintain connection to both the sensors and the Controller (through
the Gateways).
As in many existing MQTT-based deployments, LoRaWAN server components
are assumed to be integrated with the Gateway devices but these
devices communicate via DeftT over adhoc WiFi. All Gateways
participate in a collection for join messages but only the join
server originates LoRaWAN join-accept Publications. Only one Gateway
has the join server _capability_ (defined in the schema and conferred
via identity chain). The join server may distribute the (encrypted)
application key to Gateways that display sensor information or to
WiFi devices that may perform more sophisticated tasks e.g., a tablet
that analyzes and displays historical sensor input.
Multiple Gateways can receive sensor messages which they package as
Publications using the device identifier (DevAddr) and unique count
(uplink FCnt) as components of the name and publish in a collection
of sensor measurements. If Publications are encrypted with a group
key, the full name will be unique and only those Gateways that did
not receive the broadcast directly from a sensor will obtain it via
the DeftT WiFi interface. (Collection synchronization discards
duplicates.) Otherwise, if Publications are signed with the identity
of the originating Gateway, the shim can discard duplicates before
passing to the subscribing application. The Controller receives
Publications of sensor data via a TCP connection to the TCP face of
the DeftT relay and receives a copy of the application key.
(Artwork only available as svg: ./figs/meshEx-rfc.svg)
Figure 19: IIOT Gateways and relay extend a trust domain
In addition to specifying encryption and signing types, schema 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, relayed through
the Internet, while only plant Security can see images from on-site
cameras.
Nichols, et al. Expires 16 February 2025 [Page 63]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
6.2. Secure access to Distributed Energy Resources (DER)
The electrical power grid is evolving to encompass many smaller
generators with complex interconnections. Renewable energy systems
such as smaller-scale wind and solar generator sites must be
economically accessed by multiple users such as building owners,
renewable asset aggregators, utilities, and maintenance personnel
with varying levels of access rights. North American Electric
Reliability Corporation Critical Infrastructure Protection (NERC CIP)
regulations specify requirements for communications security and
reliability to guard against grid outages [DER]. Legacy NERC CIP
compliant utility communications approaches, using dedicated
physically secured links to a few large generators, are no longer
practical. DeftT offers multiple advantages over bilateral TLS
sessions for this use case:
* Security. Encryption, authentication, and authorization of all
information objects. Secure brokerless pub/sub avoids single-
point broker vulnerabilities. Large generation assets of hundreds
of megawatts to more than 1 gigawatt, particularly nuclear power
plants must be controlled securely or risk large-scale loss of
life accidents. Hence, they are attractive targets for
sophisticated nation-state cyber attackers seeking damage with
national security implications. Even small-scale DER generators
are susceptible to a coordinated attack which could still bring
down the electric grid.
* Scalability. Provisioning, maintaining, and distributing multiple
keys with descriptive, institutionalized, hierarchical names.
DeftT allows keys to be published and securely updated on-line.
Where historically a few hundred large-scale generators could
supply all of the energy needs for a wide geographic area, now
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
Nichols, et al. Expires 16 February 2025 [Page 64]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
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 DeftT 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 communication
rules and then secured by DeftT's use of compiled schemas.
The specificity of the requirements of NERC CIP can be used to create
communication schemas that contain site-specifics, allowing
applications to be streamlined and generic for their functionality,
rather than containing security and site-specifics.
7. Security Considerations
This document presents a transport protocol that secures the
information it conveys (COMSEC in the language of [RFC3552]).
Security of data in the application space is out-of-scope for this
document, but use of a trusted execution environment (TEE), e.g.,
ARM's TrustZone, is recommended where this is of concern. There is
significant industry awareness of the ubiquitous need for trust of
computing devices. To the extent that they have sponsored Caliptra
[caliptra], the RTL (registered transfer language) for a root of
trust element that can be included without cost in any design.
Unauthorized changes to DeftT code could bypass validation of
received PDUs or modify the content of outgoing PDUs prior to signing
(but only valid PDUs are accepted at receiver; invalid PDUs are
dropped by uncompromised member). Although securing DeftT's code is
out-of-scope for this document, DeftT has been designed to be easily
deployed with a TEE. Revisiting Figure 6, Figure 20 highlights how
Nichols, et al. Expires 16 February 2025 [Page 65]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
all of the DeftT code and data can be placed in the secure zone
(long-dashed line), reachable _only_ via callgates for the Publish
and Subscribe API calls.
(Artwork only available as svg: ./figs/hwtrust-rfc.svg)
Figure 20: DeftT secured with a Trusted Execution Environment
Providing crypto functions is out-of-scope of this document. The
example implementation uses *libsodium*, an open source library
maintained by experts in the field [SOD]. Crypto functions used in
any alternative implementation should be of similar high quality.
Enrollment of devices is out-of-scope. A range of solutions, from
preconfiguration to over-the-air, are available and selection of one
is dependent on specifics of a deployment. Example approaches
include the Open Connectivity Foundation (OCF) onboarding and BRSKI
[RFC8995]. NIST NCCOE network layer onboarding might be adapted,
treating a communication schema like a MUD URL.
Protecting private identity and 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]. As signing key pairs are updated locally and
the private key is used for every Publication, TPM storage for that
key is not practical but other trusted memory and execution could be
used for the key and its signing functions. These key pairs can be
updated frequently. DeftT does not contain any specific remediation
if a signing or identity key is exfiltrated; additional monitoring
may be implemented where the threat level is high.
DeftT's unit of information transfer is a Publication. It is an
atomic unit sized to fit in a lower layer transport PDU (if needed,
fragmentation and reassembly are done in shim or application). All
Publications must be signed and the signature must be validated. All
Publications start with a Name (Section 3.3.1.3). Publications are
used both for ephemeral communication, like commands and status
reports, and long-lived information like certs. The set
reconciliation-based syncps protocol identifies Publications using a
hash of the _entire_ Publication, including its signature. A sync
collection can contain at most one instance of any Publication so
replays of Publications in the collection are discarded as duplicates
on arrival. The current DeftT implementation requires weakly
synchronized clocks with a known maximum skew. Publications have a
lifetime enforced by their sync collection; 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
Nichols, et al. Expires 16 February 2025 [Page 66]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
passed. (Lifetimes in current applications range from days or years
for certs to milliseconds for status and command communications).
Publications arriving a skew time before their timestamp or a skew
time plus lifetime after their timestamp are discarded.
An attacker can modify, drop, spoof, or replay any DeftT PDU or
Publication but DeftT is designed for this to have minimal effect:
1. modification - all DeftT cAdd PDUs must be either signed or AEAD
encrypted with a securely distributed nonce group key. This
choice is specified in the schema and each DeftT checks at
startup that one of these two properties holds for the 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 PDU's
signature or the PDU is dropped.
* for encrypted PDUs (and Publications) 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 and Publications 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 publishes
cStates regardless of whether the collection has changed,
resulting in (re)sending dropped cAdds (if any). Unlike
connection-oriented transports, DeftT can and will obtain any
Publications missing from its collection from any member that has
a valid copy.
3. spoofing - DeftT uses a trust management engine that validates
the signing. Malformed Publications and PDUs are dropped as
early as possible.
4. replay - A cAdd is sent in response to a specific cState, so a
replayed cAdd must match a current cState and, if so, the cAdd's
Publication(s) will be filtered for duplicates and obsolescence
as described above. A cAdd that doesn't match a current cState
will be dropped on arrival.
Nichols, et al. Expires 16 February 2025 [Page 67]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
Peer member authentication in DeftT comes through the integrated
trust management engine. Every DeftT instance is started with an
identity bundle that includes the domain trust anchor, the schema in
certificate format signed by this trust anchor, and its own member
identity chain with a private identity key and the chain signed at
the root by trust anchor. Members publish their identity chains
before any Publications are sent. The trust management engine
unconditionally drops any Publication or PDU that does not have a
valid signer or whose signer lacks the role or capabilities required
for that particular Publication or PDU.
DeftT takes a modular approach to signing/validation of its PDUs and
Publications, so a number of approaches to integrity, authenticity,
and confidentiality are possible (and several are available at
[DCT]). Security features that are found to have vulnerabilities
will be removed or updated and new features are easily added.
A compromised member of a trust domain can only build messages that
match the role and attributes 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.
DeftT's modular structure allows for any cryptographic methods to be
used as sigmgrs. New methods can easily be added to the transport as
long as they present the same API.
The example implementation's encryption modules provide for
encryption on both cAdd PDUs and Publications. The latter _must_ be
signed by the originator in addition to being encrypted. This is not
required for cAdd PDUs, so the specific entity that sent the cAdd
cannot be determined but the Publications it carries _must_ be
signed, even if not encrypted. In DeftT, any member can resend a
Publication from any other member (without modification) so group
encryption (in effect, group signing) is no different. Some other
encryption approaches are provided whose potential vulnerabilities
are described with their implementations and a signed, encrypted
approach is also available [DCT]. [DCT] relies on the crypto library
libsodium and on linux random implementations with respect to entropy
issues. In general, these are quite application-dependent and should
be further addressed for particular deployments.
Nichols, et al. Expires 16 February 2025 [Page 68]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management",
RFC 1422, DOI 10.17487/RFC1422, February 1993,
<https://www.rfc-editor.org/info/rfc1422>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[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>.
[RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
Zúñiga, "Multicast Considerations over IEEE 802 Wireless
Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
<https://www.rfc-editor.org/info/rfc9119>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
9.2. Informative References
[ATZ] Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and S.
Martin, "TrustZone Explained: Architectural Features and
Use Cases", 2016, <https://doi.org/10.1109/CIC.2016.065>.
[CAvuln] Marlinspike, M., "More Tricks for Defeating SSL in
Practice", 2009, <http://2015.hack.lu/archive/2009/moxie-
marlinspike-
some_tricks_for_defeating_ssl_in_practice.pdf>.
Nichols, et al. Expires 16 February 2025 [Page 69]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[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>.
[COMIS] Lydersen, L., "Commissioning Methods for IoT", February
2019,
<https://www.silabs.com/documents/public/presentations/ew-
2019-iot-security-commissioning-methods-for-iot.pdf>.
[COST] Guy, W., "Wireless Industrial Networking Alliance, Wired
vs. Wireless: Cost and Reliability", October 2005,
<https://www.fierceelectronics.com/embedded/wired-vs-
wireless-cost-and-reliability>.
[ConfusedDep]
Support, G. C., "Additional authenticated data guide",
July 2021, <https://cloud.google.com/kms/docs/additional-
authenticated-data#confused_deputy_attack_example>.
[DCT] Pollere, "Defined-trust Communications Toolkit", 2022,
<https://github.com/pollere/DCT>.
[DER] NERC, "North American Electric Reliability Corporation:
Distributed Energy Resources: Connection, Modeling, and
Reliability Considerations", February 2017,
<https://www.nerc.com/pa/RAPA/ra/
Reliability%20Assessments%20DL/
Distributed_Energy_Resources_Report.pdf>.
[DIFF] Eppstein, D., Goodrich, M. T., Uyeda, F., and G. Varghese,
"What's the difference?: efficient set reconciliation
without prior context", 2011.
[DIGN] Bandyk, M., "As Dominion, others target 80-year nuclear
plants, cybersecurity concerns complicate digital
upgrades", November 2019,
<https://www.utilitydive.com/news/as-nuclear-plants-look-
to-digitize-controls-and-enhance-performance-
cyber/566478/>.
Nichols, et al. Expires 16 February 2025 [Page 70]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[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>.
[Demers87] Demers, A. J., Greene, D. H., Hauser, C., Irish, W.,
Larson, J., Shenker, S., Sturgis, H. E., Swinehart, D. C.,
and D. B. Terry, "Epidemic Algorithms for Replicated
Database Maintenance", 1987,
<https://doi.org/10.1145/41840.41841>.
[Graphene19]
Ozisik, A. P., Andresen, G., Levine, B. N., Tapp, D.,
Bissias, G., and S. Katkuri, "Graphene: efficient
interactive set reconciliation applied to blockchain
propagation", 2019,
<https://doi.org/10.1145/3341302.3342082>.
[HSE] Kapersky, "Secure Element", 2022,
<https://encyclopedia.kaspersky.com/glossary/secure-
element/>.
[IAWS] Ganapathy, K., "Using a Trusted Platform Module for
endpoint device security in AWS IoT Greengrass", November
2019, <Using a Trusted Platform Module for endpoint device
security in AWS IoT Greengrass>.
[IBLT] Goodrich, M. T. and M. Mitzenmacher, "Invertible bloom
lookup tables", 2011,
<https://doi.org/10.1109/Allerton.2011.6120248>.
[IEC] IEC, "Power systems management and associated information
exchange - Data and communications security - Part 8:
Role-based access control for power system management",
2022, <https://webstore.iec.ch/publication/61822>.
Nichols, et al. Expires 16 February 2025 [Page 71]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[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>.
[LANGSEC] LANGSEC, "LANGSEC: Language-theoretic Security "The View
from the Tower of Babel"", 2021, <http://langsec.org>.
[LangSecErr]
Momot, F., Bratus, S., Hallberg, S. M., and M. L.
Patterson, "The Seven Turrets of Babel: {A} Taxonomy of
LangSec Errors and How to Expunge Them", 2016,
<https://langsec.org/papers/langsec-cwes-secdev2016.pdf>.
[MATR] Alliance, C. S., "Matter is the foundation for connected
things", 2021, <https://buildwithmatter.com/>.
[MHST] Wikipedia, "MQTT", 2022,
<https://en.wikipedia.org/wiki/MQTT>.
[MINSKY03] Minsky, Y., Trachtenberg, A., and R. Zippel, "Set
reconciliation with nearly optimal communication
complexity", 2003,
<https://doi.org/10.1109/TIT.2003.815784>.
[MODOT] Saleem, D., Granda, S., Touhiduzzaman, M., Hasandka, A.,
Hupp, W., Martin, M., Hossain-McKenzie, S., Cordeiro, P.,
Onunkwo, I., and D. Jose, "Modular Security Apparatus for
Managing Distributed Cryptography for Command and Control
Messages on Operational Technology Networks (Module-OT)",
January 2022,
<https://www.nrel.gov/docs/fy22osti/79974.pdf>.
[MPSR] Mitzenmacher, M. and R. Pagh, "Simple multi-party set
reconciliation", 2018.
Nichols, et al. Expires 16 February 2025 [Page 72]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[MQTT] OASIS, "MQTT: The Standard for IoT Messaging", 2022,
<mqtt.org>.
[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>.
[NIST] Hu, C., Ferraiolo, D., Kuhn, D., Schnitzer, A., Sandlin,
K., Miller, R., and K. Scarfone, "Guide to Attribute Based
Access Control (ABAC) Definition and Considerations",
August 2019, <https://www.nist.gov/publications/guide-
attribute-based-access-control-abac-definition-and-
considerations-0>.
[NMUD] al, D. D. E., "Securing Small-Business and Home Internet
of Things (IoT) Devices: Mitigating Network-Based Attacks
Using Manufacturer Usage Description (MUD)", May 2021,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.1800-15.pdf>.
[NPPI] Hashemian, H. M., "Nuclear Power Plant Instrumentation and
Control", 2011, <https://cdn.intechopen.com/pdfs/21051/InT
echNuclear_power_plant_instrumentation_and_control.pdf>.
[NVR] Gutmann, P., "Everything you Never Wanted to Know about
PKI but were Forced to Find Out", 2002,
<https://www.cs.auckland.ac.nz/~pgut001/pubs/
pkitutorial.pdf>.
[ONE] OneDM, "One Data Model", 2022, <https://onedm.org/>.
[OPR] King, R., "Commercialization of NDN in Cybersecure Energy
System Communications video", 2019, <https://www.nist.gov/
news-events/events/2019/09/ndn-community-meeting>.
[OSCAL] NIST, "OSCAL: the Open Security Controls Assessment
Language", 2022, <https://pages.nist.gov/OSCAL/>.
[OTPM] Hinds, L., "Keylime - An Open Source TPM Project for
Remote Trust", November 2019,
<https://www.youtube.com/watch?v=YtPsruEqGeY>.
Nichols, et al. Expires 16 February 2025 [Page 73]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[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>.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292,
DOI 10.17487/RFC4292, April 2006,
<https://www.rfc-editor.org/info/rfc4292>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
Nichols, et al. Expires 16 February 2025 [Page 74]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7693] Saarinen, M., Ed. and J. Aumasson, "The BLAKE2
Cryptographic Hash and Message Authentication Code (MAC)",
RFC 7693, DOI 10.17487/RFC7693, November 2015,
<https://www.rfc-editor.org/info/rfc7693>.
[RFC8103] Housley, R., "Using ChaCha20-Poly1305 Authenticated
Encryption in the Cryptographic Message Syntax (CMS)",
RFC 8103, DOI 10.17487/RFC8103, February 2017,
<https://www.rfc-editor.org/info/rfc8103>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RSK] Ellison, C. and B. Schneier, "Ten Risks of PKI: What
You're Not Being Told About Public Key Infrastructure",
2000.
[SDSI] Rivest, R. L. and B. W. Lampson, "SDSI - A Simple
Distributed Security Infrastructure", April 1996.
[SIOT] Truong, T., "How to Use the TPM to Secure Your IoT/Device
Data", January 2017, <https://tonytruong.net/how-to-use-
the-tpm-to-secure-your-iot-device-data/>.
[SKH] Yates, T., "Secure key handling using the TPM", October
2018, <https://lwn.net/Articles/768419/>.
[SNC] Smetters, D. K. and V. Jacobson, "Securing Network
Content", October 2009, <https://named-data.net/wp-
content/uploads/securing-network-content-tr.pdf>.
[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/>.
Nichols, et al. Expires 16 February 2025 [Page 75]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[ST] Samsung, "SmartThings API (v1.0-PREVIEW)", 2020,
<https://smartthings.developer.samsung.com/docs/api-ref/
st-api.html##operation/listCapabilities>.
[STNDN] Yu, Y., Afanasyev, A., Clark, D. D., claffy, K., Jacobson,
V., and L. Zhang, "Schematizing Trust in Named Data
Networking", 2015.
[TATT] Microsoft, "TPM attestation", June 2021,
<https://docs.microsoft.com/en-us/azure/iot-dps/concepts-
tpm-attestation>.
[TLSvuln] al., C. B. E., "Using Frankencerts for Automated
Adversarial Testing of Certificate Validation in SSL/TLS
Implementations", November 2014,
<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4232952/>.
[TPM] Griffiths, P., "TPM 2.0 and Certificate-Based IoT Device
Authentication", September 2020,
<https://www.globalsign.com/en/resources/white-papers-
ebooks/white-paper-tpm-20-and-certificate-based-iot-
device-authentication>.
[W509] Wikipedia, "X.509: Security", October 2021,
<https://en.wikipedia.org/wiki/X.509#Security>.
[WSEN] Kintner-Meyer, M., Brambley, M., Carlon, T., and N.
Bauman, "Wireless Sensors: Technology and Cost-Savings for
Commercial Buildings", 2002,
<https://www.aceee.org/files/proceedings/2002/data/papers/
SS02_Panel7_Paper10.pdf>.
[WegmanC81]
Wegman, M. N. and L. Carter, "New Hash Functions and Their
Use in Authentication and Set Equality", 1981,
<https://doi.org/10.1016/0022-0000(81)90033-7>.
[ZCL] zigbeealliance, "Zigbee Cluster Library Specification
Revision 6", 2019, <https://zigbeealliance.org/wp-content/
uploads/2019/12/07-5123-06-zigbee-cluster-library-
specification.pdf>.
[caliptra] Project, O. C., "Caliptra -- Silicon RoT Services", July
2022, <https://www.opencompute.org/documents/caliptra-
silicon-rot-services-09012022-pdf>.
Nichols, et al. Expires 16 February 2025 [Page 76]
Internet-Draft Defined-Trust Transport (DeftT) August 2024
[netstrings]
Bernstein, D. J., "Netstrings", February 1997,
<https://cr.yp.to/proto/netstrings.txt>.
[tnetstrings]
tnetstrings, "About Tagged Netstrings", August 2011,
<https://web.archive.org/web/20140210012056/
http://tnetstrings.org/>.
Contributors
Lixia Zhang
UCLA
Email: lixia@cs.ucla.edu
Roger Jungerman
Operant Networks Inc.
Roger contributed significantly to Section 6.
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 16 February 2025 [Page 77]