Internet DRAFT - draft-viswanathan-dtn-pkdn
draft-viswanathan-dtn-pkdn
Network Working Group K. Viswanathan
Internet-Draft F. Templin
Intended status: Standards Track Boeing Research & Technology
Expires: September 9, 2016 March 8, 2016
Architecture for a Delay-and-Disruption Tolerant Public-Key Distribution
Network (PKDN)
draft-viswanathan-dtn-pkdn-00.txt
Abstract
Delay/Disruption Tolerant Networking (DTN) introduces a network model
in which communications can be subject to long delays and/or
intermittent connectivity. DTN specifies the use of public-key
cryptography to secure the confidentiality and integrity of messages
in transit. The use of public-key cryptography posits the need for
certification of public keys and revocation of certificates. This
document formally defines the DTN key management problem and then
provides a high-level design solution for delay and disruption
tolerant distribution and revocation of public-key certificates along
with relevant design options and recommendations for design choices.
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 http://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 September 9, 2016.
Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of
Viswanathan & Templin Expires September 9, 2016 [Page 1]
Internet-Draft PKDN March 2016
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. DTN Key Management . . . . . . . . . . . . . . . . . . . . . 6
2.1. The DTN-Key-Management Problem Statement . . . . . . . . 6
2.2. Communication patterns for solving the DTN problem . . . 7
3. PKDN Architecture . . . . . . . . . . . . . . . . . . . . . . 10
3.1. PKDN Architectural elements . . . . . . . . . . . . . . . 11
3.2. Root Key Configuration . . . . . . . . . . . . . . . . . 12
3.3. Distributed Relationship Management . . . . . . . . . . . 12
3.4. PKDN Data Structures . . . . . . . . . . . . . . . . . . 13
3.5. Relationship Service Design . . . . . . . . . . . . . . . 14
3.5.1. Distribution of CRL . . . . . . . . . . . . . . . . . 15
3.6. Reliability and Availability . . . . . . . . . . . . . . 15
3.6.1. Reliability against misconfiguration . . . . . . . . 16
3.6.2. Availability . . . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The interactions in a public-key management system are between: (a)
the sender and the receiver; and, (b) the receiver/sender and a
trusted authority (Certificate Authority or CA). Although there are
public key management systems without any trusted authority, like PGP
and block-chain based certification, revocation of public keys in
such systems are either impossible or complex. The certification
process in such systems usually require many to and fro message
transmissions, which is not suitable for delay and disruption
tolerant conditions. For these reasons, the subsequent discussions
in this document shall assume a trusted authority.
In any public-key cryptographic system, the sender must have an
authentic copy of the receiver's public key for sending confidential
communications. The receiver must have an authentic copy of the
Viswanathan & Templin Expires September 9, 2016 [Page 2]
Internet-Draft PKDN March 2016
sender's public key for receiving authentic communications. Key
management protocols have required the sender/receiver to interact in
near-real-time with the trusted authority to determine if a public
key certificate has not been revoked. Such handshake communications
usually use TCP [RFC0793]. But, near-real-time messaging is not
feasible on DTN. Therefore, terrestrial key management protocols may
not always function as intended on DTN.
The Online Certificate Status Protocol (OCSP) [RFC6960], for example,
requires the receiver of a public key certificate to have on-demand
interactions with a Certification Authority (CA) in order to get the
current status information for the certificate. Three status
responses may be received by the receiver from the CA, namely: good,
revoked, and unknown. The receiver needs to accept good certificates
and reject revoked certificates. The CA sends a response indicating
the unknown state usually when it does not recognize the issuer of
the certificate. In this case, the receiver is expected to interact
on-demand with other CAs for determining if the certificate was
revoked. When the status in the response is good, since the CA does
not remember the receiver's interest in the certificate, the receiver
is required to periodically request the status before every use of
the certificate.
OCSP is a resource intensive protocol. In order to reduce the round-
trip costs for the temporal validation of the certificates,
especially in constrained clients (receivers), a provision in TLS
Extensions (see Section 8) [RFC6066] has been proposed so that the
senders shall send what is called a "stapled Certificate Status" to
the receivers. The stapled Certificate Status is a time-stamped
certificate-status certificate obtained from a trusted authority by
the sender. If the constrained receiver (client) accepts the stapled
Certificate Status, then it need not interact with any CA to
ascertain the temporal validity of the certificate -- thus reducing
communication costs on the receiver side. Although such proposals
are useful when dealing with constrained clients (or receivers of
certificate), they only transfer the burden of certificate-status
queries towards the senders and away from the receivers. Such
mechanisms do not obviate the need for on-demand interactions.
The Secure/Multi-purpose Internet Mail Extensions (S/MIME) [RFC5751]
allows a sender to encapsulate its certificate as a meta-data (in the
message header) for processing an email message. The receiver is
expected to consult with a Certificate Revocation List (CRL) or other
certificate status verification mechanisms to validate the temporal
validity of the certificate. Thus, S/MIME does not obviate the need
for on-demand interactions with remote trusted authorities.
Viswanathan & Templin Expires September 9, 2016 [Page 3]
Internet-Draft PKDN March 2016
As mentioned earlier, on-demand interactions with any party, trusted
or otherwise, is not feasible in the network model for DTN.
Therefore, existing terrestrial key management protocols are not
suitable for DTN. This proposal describes the high-level design
choices for a mechanism, which can satisfy the requirements for DTN
Key Management [I-D.templin-dtnskmreq], that does not require on-
demand interactions with remote parties.
1.1. Related Documents
The following documents provide the necessary context for the high-
level design described in this document.
RFC 4838 [RFC4838] 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 [RFC5050] describes the protocol and message formats for
DTN and is titled, "Bundle Protocol Specification." That document
provides details for the protocol message format for DTN, which is
called as Bundle, along with the description 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.
RFC 6257 [RFC6257] 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 the cipher suite in DTN.
5050bis [I-D.ietf-dtn-bpbis] is an Internet Draft on standards
track that intends to update RFC 5050. It introduces a new
concept called "node ID" and relates it with an existing concept
called "endpoint ID." A DTN endpoint is envisioned to contain one
or more nodes. It also excludes extension blocks defined in RFC
5050 to be external to the primary block, which makes the primary
block immutable by intermediary nodes. Thus, in 5050bis it is
allowed that a node receives the primary block with extension
blocks but without the capability to process the extension blocks.
In the Security Considerations section, 5050bis explicitly
describes end-to-end security using Bundle-Integrity-Block (BIB)
and Bundle-Confidentiality-Block (BCB). It does not specify link-
by-link security considerations to be part of the bundle protocol
Viswanathan & Templin Expires September 9, 2016 [Page 4]
Internet-Draft PKDN March 2016
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 [I-D.ietf-dtn-bpsec] for DTN communication
security is titled, "Streamlined Bundle Security Protocol
Specification (SBSP)." When compared with RFC 6257, it is silent
on concepts such as Security Regions, at-most-once-delivery
option, and cipher suite specification. 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 suitable key management mechanism shall be in place.
The Internet Draft for specifying requirements for DTN Key
Management [I-D.templin-dtnskmreq] 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.
1.2. Terminology
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 [RFC2119]. Lower
case uses of these words are not to be interpreted as carrying
RFC2119 significance.
This draft uses the following terminologies.
Sender
has a public-key certificate. It must pass a message to the
receiver via a validator in order to install its public-key
certificate on the receiver.
Receiver
receives messages from senders via validators and stores the
sender's public-key certificate, if the certificate is valid and
has not been revoked.
Validator
provides store-validate-and-forward service for public-key
certificates from the sender to designated receivers.
Additionally, it pushes revocation updates to the receivers for
Viswanathan & Templin Expires September 9, 2016 [Page 5]
Internet-Draft PKDN March 2016
public-key certificates, which were previously forwarded to the
receivers by that validator.
Client
consumes the services of the validator. Client must include the
logic for sender and receiver. Therefore, a client must be able
to send its certificates to others or receive certificates from
other clients via the validator. The client must be able to
receive revocation updates from validators.
Certificate Revocation Manager (CRM)
is a trust authority that sends signed revocation notices to the
validators so as to revoke public-key certificates.
Public Key Distribution Network (PKDN)
is a strict DTN overlay network that acts as:
1. a store-validate-and-forward communication medium for
communications from the senders to the receiver via the
validators; and,
2. a multicast communication medium for communications from the
CRM to the validators. The communication medium can be
implemented using either DTN multicast communications or
application-level message-propagation networks using recursive
publish-subscribe relationships.
2. DTN Key Management
This section shall introduce the problem statement for DTN Key
Management problem followed by an enumeration of communication-
patterns that can be used for potential solutions and a proposed
solution for the problem that is called a Public-Key Distribution
Network.
2.1. The DTN-Key-Management Problem Statement
The problem of DTN Key Management can be visualized as shown in
Figure 1. The Receiver receives a public key certificate from the
Sender. Since the Sender is not trusted to share timely revocation
information, the Receiver needs to receive timely revocation
information from a Trusted Authority. A basic problem is: (a) how
can the Trusted Authority know when the Receiver needs the revocation
information for a Public-Key Certificate; and, (b) how can periodic
and consistent revocation information be availability in timely and
delay-and-disruption tolerant manner? The second question gains
importance in DTN because the delay and disruption in the
communication path between the Sender and Receiver may not be
Viswanathan & Templin Expires September 9, 2016 [Page 6]
Internet-Draft PKDN March 2016
correlatable with that between the Receiver and the Trusted
Authority. This makes the DTN Key Management problem different from
terrestrial key management systems, where communication paths are
assumed to be uniform, interactive, on-demand, and similar.
+---------+ Revocation +--------+ Public-Key +-------+
| | Information | | Certificate | |
| Trusted |--(disruption/-->|Receiver|<--(disruption/--|Sender |
|Authority| delay) | | delay) | |
+---------+ +--------+ +-------+
Figure 1: DTN Key Management Problem
An analysis of the above problem using CAP theorem [CAP] suggests
that when network partition occurs, due to delay or disruption, the
receiver needs to make a local decision in favour of either
availability of its service for the received message or consistency
of its operations in not accepting revoked certificate, which was
used to provide integrity service to the received message. In other
words, when the Receiver has received the public key certificate but
has not received any revocation information as yet, it needs to vote
in favour of either: (a) availability, by accepting the certificate
without waiting for revocation information; or, (b) consistency, by
waiting for the receipt of revocation information. If it votes in
favour of availability, it risks the use of inconsistent information.
If it votes in favour of consistency, it risks lack of availability
of the public-key for some dependent information processing, which
must be paused. Clearly, in the presence of delay and disruption,
both consistency and availability cannot be achieved.
DTN Key Management solutions must be partition tolerant and provide
trade-off options for their applications between availability and
security consistency. Such a trade-off may be realized in an
application-agnostic manner by aiming for eventual consistency
instead of immediate consistency. Eventual consistency means that
all DTN nodes will eventually reject revoked keys but until such an
eventuality some DTN nodes are allowed to work with stale revocation
information depending on their application security sensitivity.
Immediate consistency is not possible in DTN but is possible in the
terrestrial Internet. The time available for accepting or rejecting
the certificate (and the message) will be decided by the
application's security threshold.
2.2. Communication patterns for solving the DTN problem
As mentioned previously, the two-fold problem of DTN Key Management
Problem is:(a) how can the Trusted Authority know when the Receiver
needs the revocation information for a Public-Key Certificate; and,
Viswanathan & Templin Expires September 9, 2016 [Page 7]
Internet-Draft PKDN March 2016
(b) how can periodic and consistent revocation information be made
available in timely and delay-and-disruption tolerant manner?
Five communication patterns can provide solutions to the first
question (Question a), namely:
Pattern 1: (Request-response) The Receiver informs the Trusted
Authority every time when it needs fresh revocation
information for a certificate by sending a request. The
Trust Authority responds with a fresh status information
for that certificate.
Pattern 2: (Publish-subscribe) The Receiver informs the Trusted
Authority about its interest in a certificate only once,
which is the first time when it needs the revocation
information, by sending a subscription request. The
Trusted Authority responds to the subscription request
with a fresh status information for that certificate and
remembers the subscription request. Whenever there is a
change in status information, the Trusted Authority sends
the updates to the Receiver without having to receive a
request for the same.
Pattern 3: (Blacklist broadcast) The Trusted Authority does not
receive any certificate-specific request from any
Receiver. It periodically broadcasts Certificate
Revocation Lists (CRLs)to all DTN nodes including the
Receiver. If the broadcast mechanism were to be replaced
with a multicast mechanism, then the Receiver will be
expected to register its address with the Trusted
Authority exactly once as a registration process. Note
that the registration process does not reference any
certificate unlike the subscription process in the
previous pattern.
Pattern 4: (White-list broadcast) This communication pattern is
similar to the previous communication pattern except that
the Trusted Authority periodically broadcasts a list of
valid certificates instead of broadcasting a list of
invalidated certificates. This communication pattern is
useful when the number of certified public-keys are less.
Pattern 5: (Publish with proxy subscribe) The Sender sends its
certificate through the Trusted Authority to the
Receiver, who shall accept certificates only from the
Trusted Authority. The Trusted Authority validates the
certificate before forwarding it to the Receiver. The
Trusted Authority subscribes the Receiver for interest in
Viswanathan & Templin Expires September 9, 2016 [Page 8]
Internet-Draft PKDN March 2016
the Sender's certificate so that periodic updates can be
sent in the future for the certificate. Thus, the Sender
acts as a proxy for the Receiver and subscribes the
Receiver for future updates from the Trusted Authority.
Pattern 1 describes the communication style used by terrestrial key
management solutions such as OCSP. The Receiver may receive the
certificate from the Sender every time a security session is
established as is the case in TLS [RFC5246]. Thus, the Receiver may
need to send a request to the Trusted Authority every time a security
session is established. Section 1 discussed why this communication
style is not suitable for DTN.
Pattern 2 has a similar complexity as Pattern 1 for the first round
of communication for a certificate between the Receiver and the
Trusted Authority. The communication complexity greatly eases from
the second round onwards when the Trusted Authority can send updates
to the Receiver without requiring a request. Although this pattern
improves the communication complexity from the second round onwards,
it does not improve communication complexity of the first round of
communications, which is a bottleneck in the DTN settings as
described for Pattern 1 in Section 1.
Patterns 3 and 4 require periodical broadcast/multicast of a list
data structure (CRL or list of valid public keys). The efficiency of
such patterns depend on three factors, namely: the size of the list
of revoked certificates, the number of communication recipients, and
the frequency of communication. If any one of these factor were to
increase, bandwidth utilization will be inefficient because not all
recipients of the communication may be interested in all elements of
the list that they receive. Thus, most recipients will end up
discarding many communications that they receive from the Trusted
Authority. When two or more of the factors were to increase
simultaneously, the communication system may be overloaded and normal
application communications may be affected. Clearly, this solution
is not scalable with the increase in number of recipients.
Additionally, since Pattern 4 uses white-lists and, in public key
management, white-lists grow more frequently than black-lists, the
frequency of communications between the Trusted Authority and the
Receivers will be higher than in Pattern 3. Also, since the
Receivers depend on the Trusted Authority for timely delivery of
white-listed keys, the first communication from the Sender to the
Receiver must strictly happen after the Trusted Authority has sent
the Sender's public key to the Receiver in a white-list
communication. Otherwise, the Sender's communication will have to be
rejected by the Receiver even though the Sender may be in possession
of a registered (or authorized) public key. This calls for increased
out-of-band delay-tolerant synchronization between the Sender and the
Viswanathan & Templin Expires September 9, 2016 [Page 9]
Internet-Draft PKDN March 2016
Receiver. For reasons mentioned above, this document shall not
pursue Patterns 3 and 4.
Pattern 5 requires every Sender to send their public-key certificates
through the Trusted Authority to the Receiver. The Trusted Authority
can be a validator, which is allowed to filter communications with
revoked public-key certificates. Additionally, the validator
remembers the Receiver's interest in order to send periodic
revocation updates for the forwarded public-key certificates. The
rest of this document shall employ this communication pattern.
3. PKDN Architecture
As mentioned in the previous section, this proposal adopts
Communication Pattern 5 for designing Public Key Distribution Network
(PKDN). The elements of PKDN and simplified information flow are
shown in Figure 2. The sender sends its certificate, along with
other information such as receiver's address, to a validator in the
PKDN. The validator forwards valid certificates to the receiver and
sends certificate revocation information to the receiver when such
information is available. In order to make the information flow
practical, addressing, timing, and security meta-data are sent along
with the certificate, validated certificate, and certificate status.
The details of the meta-data shall be described in the rest of this
section.
+----------------------+
|Delay Tolerant Network|
| +-------+ |
| | CRM | |
| +---+---+ |
| | |
| |Delta-CRL |Validated
+------+ | +-----v------+ |Certificate +--------+
| |Certificate| | (PKDN) +-----------------> |
|Sender+----------------> Network of | | |Receiver|
| | | | Validators +-----------------> |
+------+ | +------------+ |Certificate +--------+
+----------------------+Status
Figure 2: Simplified view of PKDN Architecture
Figure 3 presents a simplified communication stack view of the same
PKDN architecture (Figure 2). It does not depict the complete Bundle
Protocol layering architecture for the sake of clarity and brevity --
RFC 5050 [RFC5050] contains the complete Bundle protocol layering
architecture. All architectural elements of PKDN use the Bundle
Viswanathan & Templin Expires September 9, 2016 [Page 10]
Internet-Draft PKDN March 2016
Protocol (BP) layer as their communication interface. Thus, every
PKDN architectural element is a Bundle Protocol Application.
+--------+
+-----------+ | CRM | +-----------+
| | +--------+ | |
| Validator | | BP | | Validator |
+-----------+ +---+----+ +-----------+
| BP +-+ | +--+ BP |
+-----------+ | | | +-----------+
| | |
+--------+ _( +===- | | +----------+
| | ( -+ )-+- -_ | |
| Sender | ( Delay Tolerant _) | Receiver |
+--------+ (_ Network _=- +----------+
| BP +----+ Cloud _) | BP |
+--------+ -=__(__ _-)- +-----+----+
-+- |
| |
+--------------------+
Figure 3: PKDN Architecture: Simplified communication stack view
3.1. PKDN Architectural elements
The architectural elements and their roles are as follows.
1. (Revocation Manager - RM) This element is the revocation
authority for a PKDN. There can be one or more RMs in a PKDN. A
revocation manager has a self-signed public key. The self-signed
public key must be made available securely to all other
architectural entities as an out-of-bound, single-time
configuration.
2. (Sender) The sender of a message with a valid certificate from a
Certificate Authority, which is outside the purview of PKDN.
3. (Receiver) The receiver of a message that has the root-public key
corresponding to the Certificate Authority of the sender.
4. (Validator) It is a logically in-line element between the sender
and the receiver. It must have the root-public key corresponding
to the Certificate Authority of the sender. It verifies the
validity of the sender's certificate and that the certificate has
not been revoked. It also sends revocation periodic updates for
the sender's certificate.
Viswanathan & Templin Expires September 9, 2016 [Page 11]
Internet-Draft PKDN March 2016
Since PKDN does not prescribe any interactions for or with the
sender's Certificate Authority, it is not listed as an architectural
element. But, the sender, receiver, and validator are expected to be
in possession of the root, self-signed certificate of the sender's
certification chain-of-trust.
3.2. Root Key Configuration
Every element of the PKDN architecture must be in possession of the
root, self-signed certificate of the RM's certification chain-of-
trust. Every element of the PKDN architecture, except the RM, must
be in possession of the root, self-signed certificate of the sender's
Certificate Authority's chain of trust. The root, self-signed
certificates must be physically configured in a secure manner on
every architectural element. Therefore, the root, self-signed
certificates are not expected to change or be revoked.
3.3. Distributed Relationship Management
A relationship in PKDN is defined by the tuple: ((sender-certificate-
fingerprint, sender identity, validator identity, receiver identity),
E), where:
1. sender-certificate-fingerprint is a cryptographic hash of the
sender's public key certificate, which is specified to expire at
time CE -- specified in Universal Time (UT);
2. validator identity designates the validator that created this
relationship;
3. receiver identity designates the receiver for which the validator
created this relationship; and,
4. E is a future time, which is specified in Universal Time (UT),
when this relationship must expire such that E is less than or
equal to CE.
The relationship is stored asynchronously by the sender, validator,
and receiver. Validator stores the relationship tuple first. The
receiver and sender store the relationship tuple asynchronously after
receiving a communication from the validator.
Let L be a system-wide constant to indicate the maximum duration for
the validity of a given relationship. Let M be the maximum expected
communication delay in the DTN, over which the PKDN is an overlay.
Then, L >> 3*M: the duration of relationship validity must be much
greater than three times the maximum expected communication delay
anywhere in the DTN. The following expression is a corollary: L/3 >>
Viswanathan & Templin Expires September 9, 2016 [Page 12]
Internet-Draft PKDN March 2016
M. When L is 8 hours, for example, the communication delay, M, must
be less than 2.66 hours. The expiry time for the relationship, E, is
computed as E = (T + L) where T is the time when the relationship was
created by the validator. The sender, receiver, and validator must
asynchronously delete expired relationship tuples. If the validator
receives a revocation notice including a sender-certificate-
fingerprint, which has unexpired relationships, then the validator
must send a revocation notice for that relationship to respective
receivers. The sender can prevent the expiry of a relationship tuple
by sending a fresh relationship request to the corresponding
validator.
Optionally, the sender may have multiple unexpired relationship
tuples with a receiver by sending relationship requests through
multiple validators. The receiver can reject relationships by
sending an unsubscribe message for a specified sender-certificate-
fingerprint to the validator.
3.4. PKDN Data Structures
Relationship are created, revoked, or rejected by asynchronously
passing messages -- we only assume synchronization of clocks in the
PKDN, which is also the assumption in the underlying DTN. The
messages passed along with their formats are as follows.
1. (Relationship request bundle or RRqBundle) is sent by the sender
to the validator. It contains the sender identity, sender
timestamp, sender's public-key certificate, validator identity,
receiver identity, and a signature for the RRqBundle using the
sender's private key corresponding to the sender's public-key
certificate.
2. (Relationship creation bundle or RCBundle) is sent by the
validator to the receiver. It contains the RRqBundle that
triggered the creation of this bundle along with the expiry time
of this relationship (E), validator's public-key certificate, and
a signature for the RCBundle using the validator's private key
corresponding to the validator's public-key certificate.
3. (Relationship creation acknowledgement bundle or RCaBundle) is
sent by the validator to the sender. It contains sender
identity, validator identity, receiver identity, sender time
stamp, sender-certificate-fingerprint, E, validator's public-key
certificate, and a signature on the RCaBundle using the
validator's private key corresponding to the validator's public-
key certificate.
Viswanathan & Templin Expires September 9, 2016 [Page 13]
Internet-Draft PKDN March 2016
4. (Relationship revocation bundle or RRvBundle) is sent by the
validator to the receiver. It contains the sender-certificate-
fingerprint, validator identity, receiver identity, revocation
time stamp, and a signature on the RRvBundle using the
validator's private key.
5. (Relationship rejection bundle or RRjBundle) is sent by the
receiver to the validator. It contains the sender-certificate-
fingerprint, validator identity, receiver identity, receiver's
public-key certificate, rejection time stamp, and a signature for
the RRvBundle using the receiver's private key corresponding to
the receiver's public-key certificate.
6. (Relationship termination notice bundle or RtnBundle) is sent by
the validator to the sender. It contains the sender-certificate-
fingerprint, validator identity, receiver identity, sender
identity, termination time stamp, termination reason (revocation
or rejection), and a signature for the RtnBundle using the
validator's private key corresponding.
The message formats can be serialized using JSON, CBOR, or any other
serialization format that is compatible with the DTN Bundle Protocol.
3.5. Relationship Service Design
The relationship services of PKDN to its clients are as follows.
1. (Relationship creation) When a Validator receives a RRqBundle
from a sender for a receiver, it:
1. verifies the authenticity and validity of sender's
certificate in the RRqBundle;
2. verifies the sender's authentication in the RRqBundle;
3. registers a relationship for the RRqBundle with expiry time
E, as explained in the previous section;
4. constructs and sends a RCBundle to the receiver designated in
RRqBundle; and,
5. constructs and returns a RCaBundle to the sender of the
RRqBundle.
2. (Relationship revocation) When a validator receives a revocation
notice for a sender-certificate-fingerprint from the CRM, it must
construct and send a RRjBundle to all receivers who have a
relationship with that sender-certificate-fingerprint. The
Viswanathan & Templin Expires September 9, 2016 [Page 14]
Internet-Draft PKDN March 2016
validator must construct and send RtnBundle to the corresponding
sender with revocation as the termination reason.
3. (Relationship rejection) The receiver may can unsubscribe its
interest in a sender-certificate-fingerprint by sending a
RRjBundle to the corresponding validator. The validator, in
response, must send a corresponding RtnBundle to the
corresponding sender with rejection as the termination reason.
The specification of L units of time in the design implies that the
sender must send at least one PKDN Bundle after every L units of time
in order to keep its relationship with the receiver. In response to
the relationship initiation from the sender, the receiver can
initiate a relationship with the sender by switching their sender-
receiver roles. Thus, PKDN can support simplex and duplex security
relationships.
3.5.1. Distribution of CRL
The CRM maintains the master copy of the Certificate Revocation List
(CRL) in the system. When a new entry is added to the CRL, the CRM
sends the addition as authenticated delta CRL update messages to all
registered validators. Upon receiving the authenticated delta CRL
messages, the validators must update their local copies of CRL. The
local copies of the CRL are then used by the validators to provide
relationship revocation service to the clients.
The Detla CRL messages from the CRM has the following structure with
two structures: (Delta := list((sender-certificate-fingerprint,CE,
RTS)), Auth := CRM-authenticator), where Delta is a list that has
been added to the master CRL by the CRM and Auth is the digital
signature on Delta by the CRM. The list elements of Delta are
3-tuples such that sender-certificate-fingerprint and CE (certificate
expiry) are as described in Section 3.3 and RTS is the timestamp when
this tuple was added to the master CRL. As with other data-
structures, the message format can be serialized using JSON, CBOR, or
any other serialization format that is compatible with DTN.
3.6. Reliability and Availability
The reliability and availability aspects of PKDN design are discussed
below. The degree of reliability and availability are dependent on
the domain of application of DTN and PKDN. Therefore, generic
discussions are provided in this section for developing DTN and PKDN
with suitable degrees of reliability and availability.
Viswanathan & Templin Expires September 9, 2016 [Page 15]
Internet-Draft PKDN March 2016
3.6.1. Reliability against misconfiguration
Every client must be configured with the network identifier of its
validator. This configuration is not a system wide constant. This
information may be configured statically or dynamically using
discovery protocols or remote administration protocols before the
sender/receiver can join PKDN. It is essential that the configured
validator services are reliable and reachable.
3.6.2. Availability
PKDN has two types of network services, namely those for:
relationship management and distributed CRL management. The
availability of these two network services despite adversarial
presence determines the availability of PKDN. As is the case with
DTN, PKDN will have to rely on the lower layers to provide
availability guarantees despite adversarial interactions.
4. IANA Considerations
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.
5. Security Considerations
Security issues and considerations are discussed through out this
document.
6. References
6.1. Normative References
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
draft-ietf-dtn-bpbis-03 (work in progress), March 2016.
[I-D.ietf-dtn-bpsec]
Birrane, E., Pierce-Mayer, J., and D. Iannicca, "Bundle
Protocol Security Specification", draft-ietf-dtn-bpsec-00
(work in progress), December 2015.
[I-D.templin-dtnskmreq]
Templin, F. and S. Burleigh, "DTN Security Key Management
- Requirements and Design", draft-templin-dtnskmreq-00
(work in progress), February 2015.
Viswanathan & Templin Expires September 9, 2016 [Page 16]
Internet-Draft PKDN March 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <http://www.rfc-editor.org/info/rfc4838>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <http://www.rfc-editor.org/info/rfc5050>.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011,
<http://www.rfc-editor.org/info/rfc6257>.
6.2. Informative References
[CAP] Brewer, E., "CAP twelve years later: How the "rules" have
changed", Feb 2012, <http://ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=6133253>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
Viswanathan & Templin Expires September 9, 2016 [Page 17]
Internet-Draft PKDN March 2016
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
Authors' Addresses
Kapali Viswanathan
Boeing Research & Technology
Unit 501, 5th Floor, Tower D, RMZ Infinity
No 3, Old Madras Rd
Bangalore, KA 560016
IN
Email: kapaleeswaran.viswanathan@boeing.com
Fred L. Templin
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Viswanathan & Templin Expires September 9, 2016 [Page 18]
