Internet DRAFT - draft-templin-dtnskmps
draft-templin-dtnskmps
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational March 12, 2014
Expires: September 13, 2014
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
Templin Expires September 13, 2014 [Page 1]
Internet-Draft DTNSKMPS March 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Templin Expires September 13, 2014 [Page 2]
Internet-Draft DTNSKMPS March 2014
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].
Templin Expires September 13, 2014 [Page 3]
Internet-Draft DTNSKMPS March 2014
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.
Templin Expires September 13, 2014 [Page 4]
Internet-Draft DTNSKMPS March 2014
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
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
6.2. Informative References
[I-D.farrell-dtnrg-km]
Farrell, S., "DTN Key Management Requirements",
draft-farrell-dtnrg-km-00 (work in progress), June 2007.
[I-D.irtf-dtnrg-sbsp]
Birrane, E., "Streamlined Bundle Security Protocol
Specification", draft-irtf-dtnrg-sbsp-00 (work in
progress), July 2013.
[I-D.irtf-dtnrg-sec-overview]
Farrell, S., Symington, S., Weiss, H., and P. Lovell,
"Delay-Tolerant Networking Security Overview",
draft-irtf-dtnrg-sec-overview-06 (work in progress),
Templin Expires September 13, 2014 [Page 5]
Internet-Draft DTNSKMPS March 2014
March 2009.
[IVAN09] Ivancic, W., "Security Analysis of DTN Architecture and
Bundle Protocol Specification for Space-Based Networks",
October 2009.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
May 2011.
[WOOD08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of
Problems", December 2008.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires September 13, 2014 [Page 6]
