Delay Tolerant Networking Security Key Management - Problem Statement
draft-templin-dtnskmps-00.txt

Abstract

Delay/Disruption Tolerant Networking (DTN) introduces a network model in which communications may be subject to long delays and/or intermittent connectivity. These challenges render traditional security key management mechanisms infeasible since round trip delays may exceed the operational limitations of the protocol. This document therefore presents a problem statement for security key management in DTNs.

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 13, 2014.

Copyright Notice

Copyright (c) 2014 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 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. Discussion
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

The Delay/Disruption Tolerant Network (DTN) architecture [RFC4838] 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 [RFC5050] 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 [RFC6257][I-D.irtf-dtnrg-sbsp]. 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) [RFC4210].

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) [RFC5996] 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 [I-D.farrell-dtnrg-km][I-D.irtf-dtnrg-sec-overview], and was also highlighted in "A Bundle of Problems" [WOOD08], Section 4.13 and "Security Analysis of DTN Architecture and Bundle Protocol Specification for Space-Based Networks" [IVAN09].

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.

2. Discussion

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) [RFC4210]. 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) [RFC4880]) 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.

3. IANA Considerations

There are no IANA considerations for this document.

4. Security Considerations

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

DTN security considerations are discussed in [RFC6257][I-D.irtf-dtnrg-sbsp].

5. Acknowledgments

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

6. References

6.1. Normative References

6.2. Informative References

Author's Address