Architecture for Delay-Tolerant Key
AdministrationJPL, Calif. Inst. Of Technology4800 Oak Grove Dr.PasadenaCA91109-8099USAScott.Burleigh@jpl.nasa.govJPL, Calif. Inst. Of Technology4800 Oak Grove Dr.PasadenaCA91109-8099USADavid.C.Horres@jpl.nasa.govBoeing Research & TechnologyBoeing International Corporation India Private
LimitedA Block, 4th Floor, Lake View BuildingBagmane Tech Park, C.V. Raman NagarBangaloreKA560093INkapaleeswaran.viswanathan@boeing.comBoeing Research & TechnologyThe Boeing Company499 Boeing BoulevardHuntsvilleAL35824USAmichael.w.benson@boeing.comBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftDelay-Tolerant Key Administration (DTKA) is a system of public-key
management protocols intended for use in Delay Tolerant Networking
(DTN). This document outlines a DTKA proposal for space-based
communications, which are characterized by long communication delays and
planned communication contacts.Delay-Tolerant Key Administration (DTKA) is a system of public-key
management protocols intended for use in Delay
Tolerant Networking (DTN). This document outlines a DTKA proposal
for space-based communications, which are characterized by long
communication delays and planned communication contacts. The proposal
satisfies the requirements for DTN
Security Key Management.In general, on-demand interactive communications, like
client-server interactions, are not feasible in DTN's network model.
Terrestrial public-key management protocols require on-demand
interactions with remote computing nodes to distribute and validate
public-keys. For example, terrestrial public-key management protocols
require on-demand interactions with a remote trusted authority
(Certificate Revocation List (CRL)) to determine if a given public-key
certificate has been revoked or not. Therefore, such terrestrial
public-key management protocols cannot be used in DTN.Periodic and planned communications are an inherent property of
space-based communication systems. Thus, the core principle of DTKA is
to exploit this property of space-based communication systems in order
to avoid the need for on-demand interactive communications for key
management. Therefore, the design strategy for DTKA is to pro-actively
distribute authenticated public-keys to all nodes in a given DTN
instance in advance to ensure that keys will be available when needed
even if there may be significant delays or disruptions. This design
strategy is to be contrasted with protocols for terrestrial Public-Key
Infrastructures, in which authenticated public-keys are exchanged
interactively, just-in-time and on demand.DTKA was originally designed for space-based DTN environments, but
it could potentially be used in terrestrial DTN environments as
well.This document describes the high-level architecture of DTKA and
lists the architectural entities, their interactions, and system
assumptions.The following documents provide the necessary context for the
high-level design described in this document. RFC 4838 describes the
architecture for DTN and is titled, "Delay-Tolerant Networking
Architecture." That document provides a high-level overview of DTN
architecture and the decisions that underpin the DTN
architecture.RFC 5050 describes the protocol
and message formats for DTN and is titled, "Bundle Protocol
Specification." That document provides the format of the network
protocol message for DTN, called a Bundle, along with descriptions
of processes for generating, sending, forwarding, and receiving
Bundles. It also specifies an encoding format called SDNV
(Self-Delimiting Numeric Values) for use in DTN. Each bundle
comprises a primary block, a payload block, and zero or more
additional extension blocks. A node may receive and process a
bundle even when the bundle contains one or more extension blocks
that the node is not equipped to process.RFC 6257 is titled, "Bundle
Security Protocol Specification." It specifies the message formats
and processing rules for providing three types of security
services to bundles, namely: confidentiality, integrity, and
authentication. It does not specify mechanisms for key management.
Rather, it assumes that cryptographic keys are somehow in place
and then specifies how the keys shall be used to provide the
security services. Additionally, it attempts to standardize a
default cipher suite for DTN. The revised Internet Draft
for DTN communication security is titled, "Bundle Security
Protocol Specification (bpsec)." When compared with RFC 6257, it
is silent on concepts such as Security Regions,
at-most-once-delivery option, and cipher suite specification. It
deletes the Bundle Authentication Block and generalized the
Payload Integrity and Payload Confidentiality Blocks to Block
Integrity Block and Block Confidentiality Block. It provides more
detailed specification for bundle canonicalization and rules for
processing bundles received from other nodes. Like RFC 6257, the
draft does not describe any key management mechanisms for DTN but
assumes that a suitable key management mechanism shall be in
place.5050bis is an Internet
Draft on standards track that intends to update RFC 5050. It
introduces a new concept called "node ID" as distinguished from
the existing concept of "endpoint ID": a single DTN endpoint may
contain one or more nodes. It also migrates some primary block
fields into extension blocks, making the primary block immutable.
In the Security Considerations section, 5050bis explicitly
describes end-to-end security using Block-Integrity-Block (BIB)
and Block-Confidentiality-Block (BCB). It does not specify
link-by-link security considerations to be part of the bundle
protocol level using the Bundle-Authenticity-Block (BAB), which
was described in RFC 6257. The convergence layers may provide
link-by-link authentication instead of bundle protocol agent. The Internet Draft for
specifying requirements for DTN Key Management is titled,
"DTN Security Key Management - Requirements and Design." It
sketches nine requirements and four design criteria for DTN Key
Management system. The last two requirements are the need to
support revocation in a delay tolerant manner. It also specifies
the requirements for avoiding single points of failure and
opportunities for the presence of multiple key management
authorities.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in . Lower case uses of these words are not to be
interpreted as carrying RFC2119 significance.The DTKA system includes Key Owners, Key Agents (which, in aggregate,
constitute the Key Authority), and Key Users. For the sake of simplicity
and to promote conceptual clarity, shows
a single Key Agent. In order to avoid a single point-of-trust, DTKA
provides mechanisms to distribute the Key Authority function among one
or more DTKA Key Agents using an erasure-coding technique. This
trust-distributing mechanism is discussed later in this document.Each Key Owner has a unique DTN Node ID and chooses its own
public-private key pair. In order to associate a public-key (Key) with
its Node ID, a Key Owner sends an assertion of the form: (Node ID, Key)
to the Key Authority. Key Owners need to authenticate their respective
keys in one of two ways:in the case of out-of-band bootstrapping, Key Authority shall
rely on the physical security of the out-of-band channel to validate
the integrity of the received message and the Key Owner needs to
sign the association (Node ID, Key) using the private key
corresponding to the Key. Association realized using such an
interaction will be called Out-of-band-authentication (OOBAuth);
or,in the case of in-band authentication, the Key Owner or a trusted
third-party needs to sign the association (Node ID, Key) using the
private key corresponding to the previously authenticated and
currently effective public-key for that NodeID. If the Key Owner
signs the association, there will be roll-over association. If a
trusted third-party signs the association, the association will have
the type endorse so as to indicate an endorsement.Each Key User periodically receives a list of authenticated
public-keys from the Key Authority and uses the authenticated
public-keys as needed.DTN can be used in various theatres such as space, airspace, on
earth and at sea. There can be more than one installation of DTN in
each of these theatres administered by different administrative
entities, which may represent countries, companies and institutions. A
particular installation of DTN with a single aggregate key authority
is called an Application Domain.The architectural elements of DTKA, which shall henceforth be
called DTKA Entities, are listed below. DTKA-KA is part
of the root of trust for authenticated distribution of public-keys
for a given application domain. All DTKA Entities must have
physically authenticated public-keys of all DTKA Key Agents
(DTKA-KAs), which together constitute the DTKA Key Authority for a
given application domain.
DTKA-KO[Node ID] is a computing node that has possession of the
private key corresponding to the public-key authenticated for a
given Node Identity (Node ID) by the DTKA-KAs for the Key Owner's
application domain. DTKA-KU is a
computing node that receives authenticated public-keys from
DTKA-KAs and distributes the same within a single computing
machine through a suitable Interprocess Communication mechanism,
which is outside the scope of this document.
DTKA-KM is a DTKA Key User that receives authenticated public-keys
from DTKA-KAs and distributes the same over a communication
network to DTKA-KMCs, which are not DTKA Entities. DTKA-KMC can be
a DTN node that can receive key distributions from DTKA KMs. The
communication and security protocols for the interactions between
DTKA-KMs and DTKA-KMCs are outside the scope of this document. depicts the system level
interconnections that are assumed for the design of DTKA. An
application domain can have one or more DTKA-KAs, all of which must be
interconnected using a sub-second One-Way-Light-Time (OWLT) and rarely
disrupted link. Such communication link can be realized using
terrestrial Internet or specialized point-to-point space communication
techniques. This link shall be used by the DTKA-KAs to synchronize
between themselves. The DTKA-KAs shall run a reliable Time
Synchronization Mechanism (TSM), like the Network Time Protocol (NTP)
service. TSM shall ensure that time is synchronized between the
DTKA-KAs that realize the DTKA Key Authority for a given application
domain.A potentially delayed and frequently disrupted communication link
is assumed to interconnect DTKA-KAs, DTKA-KOs and DTKA-KUs. This
delayed-and-disrupted communication link is used by the DTKA-KAs to
multicast authenticated public-key associations to DTKA-KUs. The
DTKA-KUs are assumed to have access to autonomous clocks. Autonomous
clocks keep time without external correction signals and with an
allowed drift in the order of a few seconds. But, delay-tolerant
mechanisms for clock agreement such as issuance of UTC offsets in
network management messages may be present.In the subsequent sections, it shall be seen that DTKA-KAs shall
dispatch updates to the list of authenticated public-keys in the
system using erasure coding techniques. It is evident that at least a
sub-set of such communications updates must reach each DTKA-KU.
Therefore, the DTN upon which the DTKA operates must satisfy the
following communication assumption before DTKA can function along
expected lines: all addressed receivers MUST receive sufficient number
of bundles from the DTKA-KAs before the earliest effective time among
the effective times of all public-key associations in the payloads of
the bundles. Note that the underlying DTN will not be aware of the
effective times of the public-key associations in the payloads of the
bundles.The above assumption can be restated using DTKA protocol
terminologies, which shall be seen in the subsequent sections, as
follows: All addressed receivers MUST receive enough of the code
blocks for a given bulletin to enable reassembly of that bulletin
before the earliest effective-time among all associations in the
bulletin.The current public-keys of all designated DTKA-KAs for a given
application domain must be securely configured into every DTKA-KA and
DTKA-KU that needs to participate in that application domain; this is
a pre-condition for initializing those DTKA-Entities. This process
will ensure that the DTKA Agents are established as the root of trust
for that application domain.Every DTKA-KA in an application domain will receive requests for
associating public-keys with Node IDs from the respective DTKA-KOs.
After authenticating the requests and any pending revocations (as
described in below), every DTKA-KA
reaches consensus with all other DTKA-KAs, which constitute the Key
Authority in its application domain, on some subset of the
authenticated requests and revocations. The protocols and algorithms
for DTKA-KA consensus is an implementation aspect and out-of-scope of
this document. After each successful consensus, each DTKA-KA must
increment its local value called Bulletin Serial Number (BSN) and
agree on the Trust Model Number (TMN) for the bulletin. Thereafter,
each DTKA-KA must independently multicast to all participating DTKA
Entities the subset of authenticated list of address-and-key
associations on which consensus was reached along with the new BSN
value. The message format for this multicast, which is called a
Bulletin, supports message authentication and redundancy. The goal of
message authentication is to prevent DTKA Entities' acceptance of
malicious multicast messages issued by hostile nodes. The goal of
message redundancy is to ensure that a minimal set of collaborating
DTKA-KAs in the application domain will be able to successfully send
out-of-band-authentication (OOBAuth) or revocations for
address-and-key associations to all DTKA Entities -- the DTKA Entities
need not know which DTKA-KAs are not collaborating.As mentioned previously, bulletin is a collection of association
blocks (or Key Information Message [KIM] data structure) such that
each association block represents a single association of a Node ID
with a public-key as depicted in .
Each block issues either an out-of-band-authentication (OOBAuth) or
endorse or revoke or roll-over instruction to the receiving DTKA
Entities, which use the key information message to execute the
instruction locally. The semantics for each of the instruction shall
be described in subsequent sections. The block labelled "Bulletin
Hash" contains the cryptographic hash computed over all association
blocks (key information messages), the Bulletin Serial Number (BSN)
and the Trust Model Number (TMN) in that bulletin. The BSN is a unique
and sequential bulletin identifier. The TMN is a unique identifier to
indicate the trust model configuration that is to be used to validate
this bulletin. The trust model configuration can be seen as a list of
DTKA-KAs (Key Agents), who are trusted to authenticate this bulletin
to all DTKA Users in the system. The trust model configuration is also
used to indicate the t-out-of-n threshold configuration that shall be
described in the next paragraph. The precise syntax for the trust
model configuration is a DTKA-KA implementation aspect and, is
therefore, out-of-scope of this document.After forming a bulletin, a (Q+k)-erasure code algorithm is used to
create an erasure code for the bulletin. Thus, receipt of any Q
distinct code blocks will be sufficient to decode the bulletin. To
ensure that the incapacity or compromise -- or veto (disagreement on
bulletin content) -- of any single DTKA-KA will not result in
malfunction of the key authority mechanism, each DTKA-KA is assigned
primary responsibility for transmission of some limited subset of the
bulletin's code blocks and backup responsibility for some other
limited subset. The assigned code block subsets for the various
DTKA-KAs are selected in such a way that every code block is to be
transmitted by two different DTKA-KAs. The combination of these two
transmission redundancy mechanisms (parity code blocks and duplicate
transmissions), together with reliable bundle transmission at the
convergence layer under bundle multicast, minimizes the likelihood of
any client node being unable to reconstruct the bulletin from the code
blocks it receives.During system initialization, the code-block assignments for each
DTKA-KA need to be configured into every DTKA Entity. The code-block
assignment for the example considered in this section is shown below
in the table, in which an x-mark depicts the assignment of a code
block to a DTKA-KA. It can be seen in the table that, in this example,
code-blocks from at least five (t=5) DTKA-KAs must be received before
the bulletin blocks can be decoded. Also, when all DTKA-KAs multicast
their pre-defined code blocks, n * m (8*3 = 24) code blocks are sent
to all DTKA Entities. To further defend against a compromised DTKA-KA
node introducing error into the key distribution system:All nodes are informed of the code block subsets for which all
DTKA-KA nodes are responsible. Any received code block that was
transmitted by a DTKA-KA node which was not responsible for
transmission of that code block is discarded by the receiving
node.Each code block issued by the each KA is signed under that KA's
private key. The bulletin hash in the code block uniquely
identifies the bulletin that will be reconstructed using this code
block. Every transmitted code block is accompanied by the bulletin
hash. All - and only - code blocks tagged with the unique bulletin
hash are reassembled into the bulletin identified by that
hash.If the hash of a bulletin reassembled from a set of received
code blocks is not verified then, for each the DTKA-KA node that
transmitted one or more of the constituent code blocks, all code
blocks transmitted by that node are excluded from the reassembled
bulletin. Upon success, the node whose transmitted code blocks had
been excluded from the reassembled bulletin may be presumed to be
compromised.Code Block Numbers (0 to (Q + k -1))01234567KA 1xxxKA 2xxxKA 3xxxKA 4xxxKA 5xxxKA 6xxxKA 7xxxKA 8xxxThe message format for transmitting the assigned code-blocks by
each DTKA-KA is shown in . Note
that each such message is the payload of a Bundle and that the
authenticity of that payload is nominally protected by a Block
Integrity Block containing a digital signature computed in the private
key of the issuing Key Agent; the message itself contains no
self-authentication material. Reading the figure left to right, we
have: (a) a field indicating the type of this message, namely Bulletin
code block; (b) the bulletin hash as defined in ; (c) the trust model number that provides
trust-table configuration as depicted in ; (d) the code-block numbers (column numbers
in the trust-table) for which code-blocks are available in this code
block message; and, (e) the specified code-blocks from the DTKA-KA.
The identity of the DTKA-KA (KAx) that generated the code blocks must
be available as the source node ID of the DTN bundle that carried this
code block message. KAx is used to validate the signature in the
bundle's Block Integrity Block before the message is delivered to DTKA
by the underlying DTN protocol layer.When a DTKA Entity receives sufficient number of bulletin blocks
from the DTKA Key Agents, it can reconstruct the corresponding
bulletin with its unique Bundle Serial Number (BSN) in the format
depicted in . By maintaining a
historical list of successfully reconstructed BSN values and analysing
for gaps in the BSN historical list, a DTKA Entity can detect
non-receipt of past bulletins. Upon such a detection, the DTKA Entity
must send a request to all the DTKA Key Agents in the format specified
in in order to request
retransmission of the past bulletins for a given BSN value. When such
request is received by a DTKA Key Agent, the DTKA Key Agent must
retransmit its code blocks corresponding to the requested BSN only to
the requesting DTKA Entity in the format shown in . The security for this communication
from the DTKA Key Agents must be similar to the security for the
bulletin broadcast communication. Upon receiving sufficient number of
bulletin blocks for the requested bulletin, the requesting DTKA Entity
may reconstruct the bulletin and verify that the bulletin with the
requested BSN has indeed been received. Thereupon, the DTKA Entity
must update its BSN historical list with the received BSN value.In order to register a new DTKA-KO in the system, DTKA requires the
DTKA-KO with a Node ID (DTKA-KO[Node ID]) to generate a public-private
key pair and preserve the secrecy of its private key. The DTKA-KO[Node
ID] needs to generate an association message of the form (Node ID,
effective-time, public-key), where effective-time specifies the start
time after which the public-key is valid. That is, each bundle sent by
this node is to be authenticated using the node's most recently
effective public key whose effective time is less than the bundle's
creation time. The DTKA-KO[Node ID] must send the association message,
along with a signature on the message using its private key, to the
DTKA-KA as depicted in . Since
DTKA-KA would not have seen the association of the public-key to that
key owner previously, it cannot trust that the message indeed
originated from DTKA-KO[Node ID]. Therefore, for registration
purposes, this initial message from the DTKA-KO[Node ID] to the
DTKA-KA MUST be protected by transmitting it over an independently
(e.g., physically) authenticated channel. The independently
authenticated channel can be realized by physically securing the
access to the DTKA-KA server, using a physical communication medium,
such as a USB dongle, and manually verifying the authenticity of the
communication from the DTKA-KO. The manual verification is a one-time
process for a given Key Owner. When an application domain has more
than one DTKA-KA (KAx), the message from DTKA-KO[Node ID] must be sent
to each DTKA-KA (KAx) in a similarly secure manner.Although the messages to DTKA-KA (KAx) are independently
authenticated, the DTKA-KO[Node ID] must sign the association message
using its private key. The signature is not intended to
cryptographically authenticate the message but only to prove to the
DTKA-KA that the DTKA-KO[Node ID] is indeed in possession of the
private key. This self-signed message by the DTKA-KO is useful to
ensure that the physical courier, which is used to realize the
physically authenticated channel, has not tampered the message sent by
the DTKA-KO to the DTKA-KA. Additionally, the self-signed message is
useful to audit the operations of the DTKA-KA.Each DTKA-KA will insert the received association message into its
next bulletin (refer to ), for
multicast as an out-of-band-authentication (OOBAuth) association: when
registration is received through a physically authenticated channel.
The bulletin will be multicast to all DTKA Entities using the protocol
described in .As an alternative to the use of a physically authenticated channel,
the registration association message may be sent by a trusted
third-party node whose authenticated public key is already registered
and known to all DTKA-KAs, so that the message may be authenticated by
verifying the digital signature (formed using the trusted third-party
node's current private key) in the BIB of the bundle containing the
message. Each DTKA-KA will insert such association requests in its
next bulletin for multicast as an endorsed association by tagging the
corresponding Key Information message in the bulletin as "endorse"
(refer to ). The bulletin will be
multicast to all DTKA Entities using the protocol described in .Manual decisions trigger the key revocation procedure. Every
DTKA-KA in an application domain is assumed to have a human operator
who can trigger the revocation process. When a key is to be revoked,
the human operator will need to authenticate to the respective DTKA-KA
(KAx) server, identify the public-key and Node ID to be revoked, and
instruct that DTKA-KA (KAx) revocation software to schedule a
revocation message. The revocation software in DTKA-KA (KAx) will
multicast a message as shown in . The
process for sending out the code-blocks by all the DTKA-KAs with this
revocation information is described in .When a DTKA-KO[Node ID] has been registered by the DTKA-KA using
the protocol described in , the
DTKA-KO[Node ID] can periodically roll-over to a new public-private
key pair by following the key roll-over protocol described in . The protocol for key roll-over is similar
to the one for key registration except that: (a) the protocol can be
executed using DTN bundles issued by the KO itself without requiring
any independently secured out-of-band communication channels; and, (b)
the old (current) public-key is used to authenticate the association
of the new public-key with the Node ID for that DTKA KO. The DTKA-KO
[Node ID] must send this message to every key agent in its application
domain. Upon accepting the roll-over message from the DTKA-KO[Node
ID], each key agent will schedule the roll-over instruction for
identified Node ID and public-key in its next bulletin as described in
. A DTKA-KO can schedule any
number of future roll-overs but the number of such roll-over schedules
may need to be limited to avoid Denial of Service attacks by
registered nodes -- but this topic is beyond the scope of this
document.When a DTKA-KO[Node ID] is not registered and does not have access
to any out-of-band authentication channel with any DTKA-KA, the
DTKA-KO[Node ID] will need to have access to an out-of-band
authentication channel for a trusted third-party (TTP), which is
registered with the DTKA-KA. Upon receiving the (Node ID, Key,
Effective time) information from the DTKA-KO[Node ID] over the
out-of-band authentication channel, the trusted third-party needs to
relay that information to the DTKA-KA by signing the information under
its authenticated public key. This interaction is depicted in . Upon accepting the endorse message from
the trusted third-party, each key agent will schedule an endorse
instruction for identified Node ID and public-key in its next bulletin
as described in .Each DTKA-KA collects multiple out-of-band-authentication
(OOBAuth), revocation, roll-over and endorse association messages from
different parties by following the protocols described in , , and . Then,
each DTKA-KA forms and sends multicast communications for the code
blocks for its bulletin to all DTKA Key Users as explained in . The DTKA-KUs verify the authenticity
of each code block from all the DTKA-KAs before using the code blocks
to decode the bulletin, which will contains out-of-band key
authentication, key revocation, key roll-over and endorse
instructions. The DTKA-KUs perform these instructions in their
respective local key database. This interaction between the DTKA-KAs
and the DTKA-KUs of an application domain is shown in .After receiving out-of-band-authentication (OOBAuth), roll-over or
endorse information, every DTKA-KU shall have authenticated
public-keys for different Node IDs in its local database. These
authenticated public-keys can be used to authenticate messages
received from the DTKA-KO[Node ID] and to send confidential messages
to the DTKA-KO[Node ID] after the specified effective-time for each
Node ID and public-key pair. This interaction is specified in .DTKA is designed to be a special DTN application that shall perform
key management operations using the services of the Bundle Protocol
and BPSec. DTKA will use BP, which in turn will use BPSec to
authenticate the messages containing the public-keys that are
subsequently to be used by BPSec for securing future communications as
shown in .This document potentially contains IANA considerations depending on
the design choices adopted for future work. But, in its present form,
there are no immediate IANA considerations.Security issues and considerations are discussed through out this
document.