Delay Tolerant Networking Security Key Management

The Delay/Disruption Tolerant Network (DTN) architecture introduces a data communications concept in which "bundles" of data are exchanged in store-and-forward fashion between endpoints that may be separated by long-delay or intermittently-connected paths. The Bundle Protocol Specification provides the bundle message format and operations, including convergence layer transmission, fragmentation and custody transfer. Each bundle further may include extensions, among which may be security parameters designed to ensure confidentiality, integrity and authorization . These securing mechanisms, terms "Bundle Security Protocol", operate within the constraints imposed by various "ciphersuites". Prominent among these are ciphersuites that rely on public/private key pairs where the public key is used to encrypt data and verify signatures while the private key is used to decrypt data and sign messages. Like any other public/private key system, however, Delay Tolerant Networks require some form of Public Key Infrastructure (PKI) to ensure that private key holders are properly authorized to use them as attested by a trusted Certificate Authority (CA) . Public key cryptography in DTNs may be in some ways simpler than in traditional Internet security approaches. In particular, some BSP ciphersuites impose no need for peers to establish a long-term secret "symmetric" session key to be applied across a stream of bundles in the way that protocols such as the Internet Key Exchange (IKE) establishes a session key to be applied across a stream of packets. Instead, per the provisions of these ciphersuites, each bundle carries its own secret symmetric key encrypted by the receiver's public key and used only once by the receiver to decrypt the bundle and verify its integrity. This means that no inter-bundle security state is necessary, but comes at the penalty of transmission overhead for the carriage of a separate secret key for each bundle. While the operation of the DTN securing mechanisms themselves can be applied independently of the key management scheme, in their current incarnation they can only be used with pre-placed irrevocable keys since there are no published mechanisms for automated security key management. On the surface, the use of standard PKI mechanisms would seem to be a natural fit, but traditional methods are not appropriate for long-delay and/or disrupted paths. This issue has prompted earlier IRTF investigations into an automated key management scheme for DTN , and was also highlighted in "A Bundle of Problems" , Section 4.13 and "Security Analysis of DTN Architecture and Bundle Protocol Specification for Space-Based Networks" . Therefore, an automated system for the publication and revocation of public keys, certificates and Certificate Revocation Lists (CRLs) will be necessary for many DTN applications, and must be designed to function in the presence of long delays and/or intermittent connectivity. The system should provide timely publication of new public keys even though the delay inherent in the system may result in actual conveyance to DTN nodes at some time in the future. In this document, we discuss the problem and highlight the need for a suitable solution.

Traditional automated PKI key management protocols allow for subjects (aka "end entities") to create self-generated public/private key pairs and then register the public key with a trusted Certificate Authority (CA) . However, these protocols expect a very short turnaround time from the point at which an end entity is granted a certificate until it is able to prove to the CA that it can sign a message using its private key. Also, issues such as the publication of a new CA key pair can result in communication failures if end entities do not discover the new public key until some time after the old public key is deprecated. Alternatives such as a "web of trust" (e.g., via Pretty Good Privacy (PGP) ) may have application in some DTNs, but this is for further study. An old adage that also needs to be addressed is whether there is a "one-size-fits-all" solution. DTNs may come in various shapes and sizes, and various approaches may be better suited to some DTNs than others. More specifically, in the future there may not be one "DTN" in the same way that there is one public Internet. But rather, there may be many DTNs for public or private use - each with their own operational capabilities and constraints. There will likely be ways to accomplish public key publication in the presence of long delays and/or disruptions, since keys can be published to take effect at some point in the future. However, timely certificate revocation may be infeasible due to the long delays inherent in many DTNs. DTN subjects therefore must be vigilant in ascertaining the degree to which long-delay correspondents can be trusted. These and many more issues must be carefully considered in any design.

There are no IANA considerations for this document.

Key management is a crucial aspect of DTN security, and must be fully addressed in any solution proposal. DTN security considerations are discussed in .

Security key management has been discussed broadly in DTN mailing list discussions as well as in many of the documents cited in this publication.