Network Working Group                                     K. Viswanathan
Internet-Draft                                                F. Templin
Intended status: Standards Track            Boeing Research & Technology
Expires: February 28, 2016                               August 27, 2015

Architecture for a Delay-and-Disruption Tolerant Public-Key Distribution
                             Network (PKDN)


   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

   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 February 28, 2016.

Copyright Notice

   Copyright (c) 2015 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
   ( in effect on the date of

Viswanathan & Templin   Expires February 28, 2016               [Page 1]

Internet-Draft                    PKDN                       August 2015

   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 . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   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.  Architecture for Public Key Distribution Network (PKDN) . . .  10
     3.1.  Design Choices for Routing Function . . . . . . . . . . .  11
     3.2.  Design Choices for Cache Synchronization  . . . . . . . .  12
     3.3.  Design Choices for Revocation Updates . . . . . . . . . .  13
   4.  Summary of Recommended Design Choices . . . . . . . . . . . .  14
   5.  Future work . . . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Key management protocols, for distribution and revocation of public
   keys on the terrestrial Internet, have required on-demand interactive
   communications, which has been realized using TCP [RFC0793]
   connections.  The interactions in a public-key management system are
   between: (a) the sender (or owner of the public key) and the receiver
   (or user of the public key); and, (b) the receiver and a trusted
   authority (Certificate Authority or CA).  On-demand 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

Viswanathan & Templin   Expires February 28, 2016               [Page 2]

Internet-Draft                    PKDN                       August 2015

   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.

   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.

Viswanathan & Templin   Expires February 28, 2016               [Page 3]

Internet-Draft                    PKDN                       August 2015

      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.

      The Internet Draft [I-D.birrane-dtn-sbsp] for DTN Key Management
      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

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   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 introduces the following terminologies.

   Public Key Distribution Network (PKDN)

Viswanathan & Templin   Expires February 28, 2016               [Page 4]

Internet-Draft                    PKDN                       August 2015

      is an overlay network that can operate on top of DTN.  It is a
      network of trusted authorities that have information about
      temporal validity (revoked or otherwise) of public keys
      certificates.  The objective of PKDN is the distribution of valid
      public-key certificates and revocation of invalidated public-key
      certificates in a secure, delay and disruption-tolerant manner.

   PKDN Bundle
      encapsulates a public-key certificate and can be transported in a
      DTN Bundle.  PKDN bundle may optionally encapsulate one or more
      message payloads (or application data) that are authenticated
      using the public-key in the encapsulated certificate.  The source
      of the PKDN bundle may provide confidentiality to the message
      payloads using the public-key of the intended receiver of the
      message payloads.  The message payloads may be DTN Bundles.

   PKDN Sender
      is the source of a PKDN bundle.  It generates PKDN bundles by
      encapsulating its public-key certificate and using the
      corresponding private key.  It may optionally encapsulate
      authenticated message payloads in the PKDN bundle.  It sends the
      PKDN bundle to a PKDN Router so that the bundle can be forwarded
      to the PKDN Receiver in designated the bundle.

   PKDN Router
      receives a PKDN Bundle from a PKDN Sender, validates it, and
      generates & forwards a Validated PKDN Bundle to the designated
      destination.  Additionally, the PKDN Router records the
      destination's interest in the public-key certificate encapsulated
      in the PKDN Bundle so that it can send periodic status updates to
      the destination.

   Validated PKDN Bundle
      is generated by an authorized PKDN Router after receiving a PKDN
      Bundle that satisfies two conditions, namely: (a) it can be
      authenticated successfully using the encapsulated certificate;
      and, (b) revocation information for the encapsulated certificate
      is not available.  A Validated PKDN Bundle includes the PKDN
      Bundle and a PKDN Bundle Validation Block (PBVB) generated by a
      PKDN Router.  PBVB essentially includes the identity of PKDN
      Router and information for: (a) asserting the temporal validity of
      the public-key certificate encapsulated in the PKDN Bundle; (b)
      the time when the assertion was made; and, (c) message-origin
      authentication for the PKDN Bundle, the assertion of temporal
      validity, and the PKDN Router time.

   PKDN Receiver

Viswanathan & Templin   Expires February 28, 2016               [Page 5]

Internet-Draft                    PKDN                       August 2015

      is the destination designated in the PKDN bundle and the node that
      shall consume the Validated PKDN Bundle.  Upon validating the PKDN
      Bundle and verifying the Validated PKDN Bundle, the PKDN Receiver
      may store the encapsulated public-key certificate locally.  Upon
      accepting the received Validated PKDN Bundle, it may optionally
      respond with an acknowledgement to the PKDN Sender via the PKDN
      Router, from which it received the Validated PKDN Bundle.  The
      acknowledgement may include its own encapsulated public-key
      certificate and message payloads -- this would be the optional
      return path for the messaging.

   Certificate Revocation Manager (CRM)
      is an operationally off-line DTN node that shall maintain the
      System's Certificate Revocation List (CRL) and publish any changes
      to the CRL as Delta-CRLs.  The CRM shall be housed in a physically
      protected location that is easily accessible for authorized and
      trusted human operators, who shall inject CRL updates into the
      CRM.  The CRM, in-turn, shall inject the Delta-CRLs to PKDN
      Routers in the PKDN administered by the human operators.  It is
      important to note that the CRM only propagates revocation
      information but not certificates.  Certificates are propagated by
      the owners of the certificates, namely PKDN Senders.

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

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 link between the Sender and Receiver may not be
   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 links are
   assumed to be uniform, interactive, on-demand, and similar.

Viswanathan & Templin   Expires February 28, 2016               [Page 6]

Internet-Draft                    PKDN                       August 2015

+---------+   Revocation          +--------+   Public-Key          +-------+
|         |   Information         |        |   Certificate         |       |
| Trusted |--(disruption/delay)-->|Receiver|<--(disruption/delay)--|Sender |
|Authority|                       |        |                       |       |
+---------+                       +--------+                       +-------+

                   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,
   (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:

Viswanathan & Templin   Expires February 28, 2016               [Page 7]

Internet-Draft                    PKDN                       August 2015

   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 routes 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
               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.

Viswanathan & Templin   Expires February 28, 2016               [Page 8]

Internet-Draft                    PKDN                       August 2015

   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
   Receiver.  For reasons mentioned above, this document shall not
   pursue Patterns 3 and 4.

   Pattern 5 requires every Sender to route their public-key
   certificates through the Trusted Authority to the Receiver.  The

Viswanathan & Templin   Expires February 28, 2016               [Page 9]

Internet-Draft                    PKDN                       August 2015

   Trusted Authority can be a PKDN Router, which is allowed to filter
   communications with revoked public-key certificates.  Additionally,
   the PKDN Router 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.  Architecture for Public Key Distribution Network (PKDN)

                      |Delay Tolerant Network|
                      |      +-------+       |
                      |      |  CRM  |       |
                      |      +---+---+       |
                      |          |           |
                      |          |Delta-CRL  |Validated
   +------+           |    +-----v------+    |PKDN Bundle +--------+
   | PKDN |PKDN Bundle|    |            +-----------------> PKDN   |
   |Sender+---------------->    PKDN    |    |            |Receiver|
   |      |           |    |            +----------------->        |
   +------+           |    +------------+    |Cert-Status +--------+

         Figure 2: Architecture of Public Key Distribution Network

   As mentioned in the previous section, this proposal adopts
   Communication Pattern 5 for designing Public Key Distribution Network
   (PKDN).  The elements of PKDN are shown in Figure 2.

   a.  An operationally off-line Certificate Revocation Manager (CRM)
       periodically injects timestamped updates to the System's
       Certificate Revocation Lists, called Delta-CRLs, into a few
       routers in the PKDN, which, in turn, shall propagate the updates
       to other routers in the PKDN.  The information in the CRL needs
       to reach PKDN Receivers in part or full.

   b.  PKDN is an overlay network on a Delay Tolerant Network (DTN) that
       is composed of a logical interconnection of PKDN Routers.

   c.  PKDN Senders send PKDN Bundles to PKDN (PKDN Routers) so that the
       PKDN Bundles can be forwarded to PKDN Receivers.

   d.  PKDN Receivers received Validated PKDN Bundles from PKDN and
       install the public key certificates in the PKDN Bundles locally.
       They also received PKDN Status messages from the PKDN

   Within this architectural setting, loosely synchronized PKDN Routers
   perform three basic functions as described below.

Viswanathan & Templin   Expires February 28, 2016              [Page 10]

Internet-Draft                    PKDN                       August 2015

   1.  (Routing) Receive and validate PKDN Bundles from Senders and
       forward Validated PKDN Bundles to Receivers designated in the
       PKDN Bundles.

   2.  (Cache synchronization) Update local CRL cache using
       authenticated and time-stamped CRL updates from authorized PKDN
       nodes.  Such authenticated updates to certificate revocation
       lists shall be called delta-CRLs.  Forward delta-CRLs to other
       PKDN Routers.

   3.  (Revocation updates) PKDN Routers construct and send periodic
       certificate status updates to PKDN Receivers using the local CRL

   The above three basic functions can now be used to enumerate the
   design choices for PKDN.

3.1.  Design Choices for Routing Function

   It was discussed that PKDN is an overlay network of PKDN routers.
   Also, a PKDN Bundle from a PKDN Sender to a PKDN Receiver needs to go
   through at least one PKDN Router.  The following questions lead to
   the design choices for PKDN.

   1.  How many PKDN Routers must there be between any given PKDN Sender
       and PKDN Receiver?  The answers can be one, two, or more.  The
       higher the number of PKDN Routers, the higher will be the routing
       delay.  In order to reduce delay, having only one PKDN Router in
       any given path for a PKDN Bundle is the best design choice.

   2.  How to determine the designated PKDN Router between a given PKDN
       Sender and PKDN Receiver?  Naming of routers is fundamental to
       determining designated PKDN Router between two given
       communication endpoints.  Two types of naming options have been
       considered for DTN [EPDTN], namely: (i) addresses with
       topological information; and, (ii) identifiers without
       topological information.  The design choices for determining the
       designated PKDN Router are: (a) the PKDN Router name for a given
       PKDN Sender is manually configured for every PKDN Sender; (b) the
       PKDN Sender discovers the name of its nearest PKDN Router using a
       broadcast-based discovery protocol; (c) the PKDN Sender uses its
       DTN address to derive the DTN address of its PKDN Router; or, (d)
       the PKDN Sender uses the PKDN Receiver's DTN address to derive
       the DTN address of the PKDN Receiver's PKDN Router.  When DTN
       node addresses with topological encoding are available, Options
       (c) and (d) provide non-interactive PKDN Router determination,
       which will be well suited for delay-and-disruption tolerance.  To
       see how Options (c) and (d) may be designed, lets assume that the

Viswanathan & Templin   Expires February 28, 2016              [Page 11]

Internet-Draft                    PKDN                       August 2015

       address of PKDN Sender has the following encoded region and
       entity information: {region, entity:port} = {,}.  Let the address of the PKDN Receiver
       be: {,}.  The PKDN Router
       for the PKDN Sender could be derived as: {,} and the PKDN Router for the PKDN Receiver could
       be derived as: {,}.  Thus, if such a
       topological encoding were available, network service discovery
       can simply be address-based host discovery.  But, when only DTN
       identifiers (without topological information) are available, only
       design choices (a) and (b) are feasible.  Furthermore, since
       Option (a) is non-interactive while Option (b) is not, Option (a)
       may be better suited when only DTN identifiers are available.

3.2.  Design Choices for Cache Synchronization

   It was specified that the Certificate Revocation Manager (CRM) needs
   to publish Delta-CRLs into the PKDN.  It was also specified that PKDN
   is a network of PKDN Routers (please refer to Figure 2).  Thus, the
   CRM needs to publish its Delta-CRLs to one or more PKDN Routers.  The
   problem is that of synchronization of a distributed cache of CRL
   information, which is a distributed aggregation problem.  A survey of
   decentralized aggregation protocols has been published by Makhloufi
   et. al.  [DAgg].  They identify gossip based, tree based, and hybrid
   aggregation protocols.  Although decentralized aggregation is best
   suited for decentralized DTN, an additional centralized aggregation
   choice (as hub-and-spoke propagation) is identified as a choice.
   Note that the PKDN Senders and Receivers are assumed, without loss of
   generality, to be agnostic of these design choices.  The design
   choices for such a network propagation of Delta-CRLs are as follows.

   1.  (Hub-and-spoke propagation) Every authorized PKDN Router is
       registered with the CRM and the CRM (as the hub) periodically
       sends updates to all registered PKDN Routers (as the spokes)
       using DTN.  The hub-and-spoke propagation is deterministic and
       simple but the load on the CRM is high and the same information
       (Delta-CRL) is carried by multiple DTN Bundles along similar DTN
       paths.  In other words, the hub-and-spoke arrangement is not
       efficient use of the network but simple and deterministic.

   2.  (Depender graph propagation) This model of propagation is
       described by Wright et. al.  [FTCR].  The basic idea is to let a
       few first-level PKDN Routers receive Delta-CRLs from CRM, which
       shall propagate the same to second-level PKDN Routers.  The
       second-level PKDN Routers shall propagate the same to third-level
       PKDN Routers and so on and so forth.  Thus a hierarchy of PKDN
       Routers shall be organized as an Rooted, Directed Acyclic Graph
       (ADAG), with the CRM functioning as the root of the graph.  The

Viswanathan & Templin   Expires February 28, 2016              [Page 12]

Internet-Draft                    PKDN                       August 2015

       number DTN bundles with the same information (Delta-CRL) along
       the same DTN path can be reduced.  Additionally, unlike the hub-
       and-spoke propagation, k-path-redundancy can be realized in the
       PKDN by requiring every PKDN Router to receive Delta-CRL updates
       from k sources (one of the k sources for the first-level PKDN
       Routers must be the CRM.)  The disadvantage of this design choice
       is its design and implementation complexity when compared with
       the hub-and-spoke design choice.

   3.  (Gossip propagation) No security literature has been found, as
       yet, for propagation of CRL information in a dependable manner
       using gossip protocols.  The security property expected out of
       such gossip-based CRL propagation protocols is only a theoretical
       feasibility that each Delta-CRL shall eventually reach all PKDN
       Routers in the PDKN.

   4.  (Hybrid propagation) Uses a combination of tree-based and gossip-
       based propagation.  No security literature has been found, as
       yet, for propagation of CRL information in a dependable manner.
       The security property for such protocols is the same as that
       stated for the Gossip propagation.

   The current recommendation for PKDN Cache Synchronization protocols
   is either: (a) to develop depender-graph propagation mechanisms; (b)
   to design and develop gossip-based propagation mechanisms; or, (c) to
   design and develop hybrid propagation mechanism.  The lead-time for
   developing depender-graph propagation mechanisms may be least among
   the recommendations.  The hub-and-spoke model of propagation is not
   recommended as it is a special case and not useful for a highly
   decentralized application of DTN.

3.3.  Design Choices for Revocation Updates

   The design choice for revocation updates is centered around the
   following questions.  Which PKDN Router needs to send updates to a
   specific PKDN Receiver?  The answers to this question provides the
   following choices:

   1.  (Updates from distributed PKDN Routers) Every PKDN Router that
       generated a Validated PKDN Bundle designated for the specified
       PKDN Receiver. in this case two sub-choices exist as follows:
       either (a) every PKDN Router sends the entire Delta-CRL to the
       PKDN Receiver; or (b) each PKDN Router sends authenticated
       updates only for those certificates that were forwarded to the
       PKDN Receiver by that PKDN Router.  Option (a) generates
       redundant traffic in the DTN as a PKDN Receiver will receive the
       same information from multiple PKDN Routers.  Therefore, it is
       recommended that Option (a) be avoided.  Option (b) conserves

Viswanathan & Templin   Expires February 28, 2016              [Page 13]

Internet-Draft                    PKDN                       August 2015

       bandwidth while avoiding single points of failures in PKDN
       revocation update functionality.  But, Option (b) implies
       increased complexity of design when dealing with PKDN-Receiver
       crash recovery or de-registering a PKDN Receiver's interest in a
       given certificate.

   2.  (Updates from a designated PKDN Router) Every PKDN Receiver
       registers with a designated PKDN Router for receiving updates or
       Delta-CRLs.  This option requires a one-time idempotent
       registration from a PKDN Receiver with a PKDN Router during
       bootstrap.  A local copy of CRL need not be saved by the PKDN
       Receiver.  Whenever the PKDN receiver receives a Delta-CRL from
       the network, it only needs to determine which of the PKDN Sender
       Certificates in its local database have been revoked due to a
       Delta-CRL.  Crash recovery in this option is naturally available
       because PKDN Receivers need not store CRLs and no state needs to
       be stored in the PKDN Routers.  To avoid single point of failures
       in receiving revocation updates, a given PKDN Receiver may
       subscribe to more than one PKDN Router.

   Having a designated PKDN Router for each PKDN Receiver results in a
   stateless system, which will be scalable.  Typically, the design
   choice for designated PKDN Router is valid when the size of Delta-
   CRLs are small enough for resource-constrained PKDN Receivers, such
   as Mars Rovers, to handle.  The maximum reported size of CRLs
   [SizeCRL] on the terrestrial Internet is about 27 Mega Bytes.  The
   size of the Delta-CRLs will be much smaller because the CRLs are
   partitioned into sub-sets using suitably sized windows of time.  In a
   given 24 hour period, the reported [SizeCRLGrowth] maximum number of
   certificates issued by VeriSign Inc. [verisign], during a given year,
   is about 200 certificates or 1% of total number of certified public
   keys for use on the terrestrial Internet.  The Delta-CRL for 200
   certificates will be a maximum of few tens of Kilo Bytes.  Assuming
   that the statistics of certificate revocation is going to be similar
   for DTNs, having a designated PKDN Router for each PKDN Receiver will
   be a good design choice.

4.  Summary of Recommended Design Choices

   The following are the recommended design choices for each function of

   1.  (Routing) Since the state-of-art of DTN only includes endpoint
       identifiers instead of addresses, Option (a) is recommended for
       designating the PKDN Router between a given PDKN Sender and PKDN
       Receiver.  The PKDN Sender shall route all its PKDN Bundles
       through its PKDN Router.  A (certificate-based) chain of trust
       must be in place so that the PKDN Receiver can authenticate the

Viswanathan & Templin   Expires February 28, 2016              [Page 14]

Internet-Draft                    PKDN                       August 2015

       origin of Validated PKDN Bundles.  The design for the key
       management structures for establishing the trust relationship
       between the sender's PKDN Routers and PKDN Receivers shall be
       described in a follow-up Internet Draft.

   2.  (Cache synchronization) The use of depender-graph propagation is
       recommended because the eventual availability of Delta-CRLs at
       all PKDN Routers has been proved [FTCR].  If a gossip or hybrid
       propagation were to be available with similar proof, they will be
       preferred over depender-graph propagation.  This is because
       gossip and hybrid propagation can allow the existence of an
       unplanned PKDN while depender-graph propagation requires a
       planned PKDN.

   3.  (Revocation updates) Assuming small sized Delta-CRLs, which is
       evinced [SizeCRLGrowth] in the terrestrial Internet, a designated
       PKDN Router for every PKDN Receiver is recommended.  The PKDN
       Receiver's PKDN Router shall be designated using the same
       mechanism as the PKDN Sender's PKDN Router was designated --
       Option (a) was recommended above for the Routing function.

5.  Future work

   The feedbacks to this document shall be used to finalize the design
   of PKDN as a key management protocol suite for DTN in a subsequent
   Internet Draft.  Additionally, the detailed protocol, data structure,
   and key hierarchy for PKDN shall be described in the subsequent
   Internet Draft.

6.  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.

7.  Security Considerations

   Security issues and considerations are discussed through out this

8.  References

8.1.  Normative References

              Birrane, E., "Streamlined Bundle Security Protocol
              Specification", draft-birrane-dtn-sbsp-00 (work in
              progress), December 2014.

Viswanathan & Templin   Expires February 28, 2016              [Page 15]

Internet-Draft                    PKDN                       August 2015

              Templin, F. and S. Burleigh, "DTN Security Key Management
              - Requirements and Design", draft-templin-dtnskmreq-00
              (work in progress), February 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [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, <>.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, DOI 10.17487/RFC5050, November
              2007, <>.

   [RFC6257]  Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification", RFC 6257,
              DOI 10.17487/RFC6257, May 2011,

8.2.  Informative References

   [CAP]      Brewer, E., "CAP twelve years later: How the "rules" have
              changed", Feb 2012, <

   [DAgg]     Makhloufi, R., Bonnet, G., Doyen, G., and D. Gaiti,
              "Decentralized Aggregation Protocols in Peer-to-Peer
              Networks: A Survey", March 2010,

   [EPDTN]    Clare, L., Burleigh, S., and K. Scott, "Endpoint naming
              for space delay / Disruption Tolerant Networking", March
              2010, <

   [FTCR]     Rebecca, N., Lincoln, P., and J. Millen, "Efficient Fault-
              Tolerant Certificate Revocation", Jun 2000,

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,

Viswanathan & Templin   Expires February 28, 2016              [Page 16]

Internet-Draft                    PKDN                       August 2015

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [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, <>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [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,

   [SizeCRL]  Raytheon Websense, "Digging Into Certificate Revocation
              Lists", July 2013,

              Walleck, D., Li, Y., and S. Xu, "Empirical Analysis of
              Certificate Revocation Lists", 2008,

              Wikipedia Inc, "Wikipedia entry for Verisign Inc", August
              2015, <>.

Authors' Addresses

   Kapali Viswanathan
   Boeing Research & Technology
   Unit 501, 5th Floor, Tower D, RMZ Infinity
   No 3, Old Madras Rd
   Bangalore, KA  560016


Viswanathan & Templin   Expires February 28, 2016              [Page 17]

Internet-Draft                    PKDN                       August 2015

   Fred L. Templin
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124


Viswanathan & Templin   Expires February 28, 2016              [Page 18]