Internet DRAFT - draft-templin-dtnskmreq

draft-templin-dtnskmreq







Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                               S. Burleigh
Expires: August 29, 2015                 JPL, Calif. Inst. Of Technology
                                                       February 25, 2015


         DTN Security Key Management - Requirements and Design
                     draft-templin-dtnskmreq-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 duration of communication opportunities.  This
   document therefore proposes requirements and outlines a design 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 August 29, 2015.

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



Templin & Burleigh       Expires August 29, 2015                [Page 1]

Internet-Draft     DTN Security Key Management Design      February 2015


   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
   2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  DTN Security Key Management Core Requirements . . . . . . . .   4
     3.1.  REQ1: Must Provide Keys When Needed . . . . . . . . . . .   4
     3.2.  REQ2: Must Be Trustworthy . . . . . . . . . . . . . . . .   5
     3.3.  REQ3: No Single Point of Failure  . . . . . . . . . . . .   5
     3.4.  REQ4: Multiple Points of Authority  . . . . . . . . . . .   5
     3.5.  REQ5: No Veto . . . . . . . . . . . . . . . . . . . . . .   5
     3.6.  REQ6: Must Bind Public Key with DTN Node Identity . . . .   5
     3.7.  REQ7: Must Support Secure Bootstrapping of a Node's
           Identity and its Public Key . . . . . . . . . . . . . . .   6
     3.8.  REQ8: Must Support Revocation . . . . . . . . . . . . . .   6
     3.9.  REQ9: Revocations Must Be Delay Tolerant  . . . . . . . .   6
   4.  DTN Security Key Management Design Criteria . . . . . . . . .   6
     4.1.  DC1: Must Perform Timely Key Provisioning . . . . . . . .   6
     4.2.  DC2: Pub/Sub Model  . . . . . . . . . . . . . . . . . . .   6
     4.3.  DC3: Publication Must Be Spread Over Multiple KAs . . . .   7
     4.4.  DC4: Availability and Security  . . . . . . . . . . . . .   7
   5.  Candidate DTN Security Key Management Design  . . . . . . . .   8
   6.  Limitations and Challenges  . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 authentication
   [RFC6257][I-D.irtf-dtnrg-sbsp].  These securing mechanisms (termed
   "Bundle Security Protocol") operate within the constraints imposed by
   various "ciphersuites".  Prominent among these are ciphersuites that



Templin & Burleigh       Expires August 29, 2015                [Page 2]

Internet-Draft     DTN Security Key Management Design      February 2015


   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] establish session keys to be applied across a stream of
   packets.  Instead, per the provisions of these ciphersuites, each
   bundle carries its own secret symmetric key in which the bundle is
   encrypted (in which case the symmetric key is itself encrypted in the
   public key of the receiver) or by which the bundle is signed (in
   which case the symmetric key is itself signed in the private key of
   the sender).

   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 it
   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 will be necessary for many DTN applications, and that
   system must be designed to function in the presence of long delays
   and/or intermittent connectivity.  The system must provide timely
   delivery of new public keys and security-key meta-data even though
   the delay inherent in the system may result in actual conveyance to
   DTN nodes long after transmission.  Moreover the improper operation
   of this system, whether caused by malfunction or by a deliberate
   attack, could have significant impact on the usability of the
   network; the system must therefore be highly resistant to operational
   failure.  In this document, we discuss the problem, provide
   requirements and propose a design for a suitable solution.





Templin & Burleigh       Expires August 29, 2015                [Page 3]

Internet-Draft     DTN Security Key Management Design      February 2015


2.  Discussion

   Traditional automated PKI key management protocols allow for a
   subject (aka "end entity") to create a self-generated public/private
   key pair and then register the public key with a trusted Certificate
   Authority (CA) [RFC4210].  However, in a network based on DTN there
   may be significant delays between the time at which an end entity
   requests another entity's certificate and the time at which the
   requested certificate is delivered.  Also, issues such as the
   publication of a new 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 a topic 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 its 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.  DTN Security Key Management Core Requirements

   A number of fundamental requirements must be satisfied by any
   security key management design for DTN.  The requirements include the
   following:

3.1.  REQ1: Must Provide Keys When Needed

   The practical significance of this requirement is that the DTN
   security key management design must not rely on timely responses to
   queries directed to a Public Key Infrastructure (PKI).  Low-delay
   online access using standard Internet connections (i.e., TCP/IP) may
   never be available.  Even if the query is submitted using some delay-
   tolerant protocol, the opportunity to use the key to encrypt or
   verify data may have ended by the time the key arrives.  In short,
   traditional PKIs are considered incompatible with DTN.



Templin & Burleigh       Expires August 29, 2015                [Page 4]

Internet-Draft     DTN Security Key Management Design      February 2015


3.2.  REQ2: Must Be Trustworthy

   The design must be based on a trust anchor common to all nodes in the
   DTN network.  A common trust anchor is needed to ensure that all DTN
   nodes will receive public keys from a secured key authority and not
   from an anonymous source.  In particular, DTN nodes cannot simply
   accept public keys directly from one another with no prior trust
   basis.  Otherwise, the network and all devices that use it could be
   compromised.  The trust anchor should store and forward only
   authentic public keys from DTKA Key Authorities in an authentic
   manner so that the unavailability of DTKA Key Authorities will not
   prevent or delay communications between any two DTN nodes.

3.3.  REQ3: No Single Point of Failure

   The design must not introduce a single point of failure; the system
   must not fail in the event that one or more critical infrastructure
   elements are damaged.  In particular, DTN nodes cannot always depend
   on receiving information from any single key authority node, since
   that node may not always be reachable over the network, may be
   subject to failures such as power outages, or may be compromised by
   an attacker.  Much like the way RAID disc arrays operate, the system
   must be resilient to one or more failures.

3.4.  REQ4: Multiple Points of Authority

   The design must not introduce a single point of authority that could
   degrade the entire network if hijacked by an attacker.  In
   particular, DTN nodes must never be forced to trust information
   provided by any single key authority node without corroboration by
   other key authority nodes.

3.5.  REQ5: No Veto

   Correspondingly, the design must never enable any single key
   authority node (possibly hijacked by an attacker) to degrade the
   network by declining to corroborate the information provided by other
   key authority nodes.

3.6.  REQ6: Must Bind Public Key with DTN Node Identity

   This requirement is about the claim for binding a public key with the
   ID of a DTN node.  The key authority must certify the association of
   a public key with an identified DTN node when and only when that
   association is asserted by some entity that the key authority trusts.
   The mechanism by which such assertions are communicated must itself
   be secured.  This requirement is a generic requirement for all secure
   Public Key Infrastructures.



Templin & Burleigh       Expires August 29, 2015                [Page 5]

Internet-Draft     DTN Security Key Management Design      February 2015


3.7.  REQ7: Must Support Secure Bootstrapping of a Node's Identity and
      its Public Key

   The Key Authority must authorize the use of the association between a
   Node's identity and its public key, along with other administrative
   information, in its DTN.  Such association is essentially random and
   cannot be verified in an automated manner.  Thus, the association
   must be verified manually before the Key Authority can approve the
   use of the association in its DTN.

3.8.  REQ8: Must Support Revocation

   The DTN PKI must provide a mechanism that allows Certificate
   Authorities to revoke a certificate even before the certificate
   expires.

3.9.  REQ9: Revocations Must Be Delay Tolerant

   The propagation of information about revocation of issued and valid
   certificates must use DTN only.  DTN certificate revocation must not
   assume the application will employ low-delay communications to verify
   public key certificates as is normal in the terrestrial Internet,
   where the Online Certificate Status Protocol (OCSP) is available to
   verify the absence of a public key in the revocation list in an on-
   demand manner.

4.  DTN Security Key Management Design Criteria

   We believe these core requirements imply several structural
   guidelines on security key management design for DTN.  A candidate
   DTN security key management design can be formulated according to the
   following design criteria:

4.1.  DC1: Must Perform Timely Key Provisioning

   The design must ensure that security keys are put in place before
   they are actually needed.  For example, if a source signs a bundle of
   data using its private key, each DTN node in the path may require
   access to the public key before the bundle arrives.  Otherwise, the
   bundle could be rejected due to security policy.  This means that DTN
   nodes must generate public/private key pairs and assert them to the
   key authority long in advance of when they would actually be needed.

4.2.  DC2: Pub/Sub Model

   The design must be based on a publish/subscribe model instead of an
   online (pull-based, or client/server) directory service, since on-
   demand retrieval from a traditional server is not possible in many



Templin & Burleigh       Expires August 29, 2015                [Page 6]

Internet-Draft     DTN Security Key Management Design      February 2015


   DTN environments due to delays/disruptions.  One alternative is for
   the key authority to publish public key "bulletins" to which all DTN
   nodes subscribe.  The bulletins must reach all DTN nodes in the
   network over the same long-delay links that carry ordinary data
   bundles.  Bulletins therefore must convey keys to be used at some
   point in the future.

4.3.  DC3: Publication Must Be Spread Over Multiple KAs

   The key management system's responsibility for distributing key
   information bulletins must be spread across multiple Key Authority
   Nodes (KAs); a monolithic bulletin generated by a single KA would
   violate requirements 3, 4, and 5.  The cooperating KA nodes must
   publish fractionated data that can be aggregated to reconstitute the
   original bulletin; it must never be possible for the compromise of
   any single KA to result in reception of an inauthentic bulletin.
   Specifically, the KAs must agree on a bulletin through control
   message exchanges, after which each KA publishes a few overlapping
   fragments of the bulletin instead of the full bulletin.  Each DTN
   node then receives the fragments and reassembles them into a complete
   bulletin.  In this way, it is OK if one or more of the KAs fails
   because the fragments are overlapping and DTN nodes will be able to
   reconstruct the full bulletin.  It is also OK if one or more of the
   KAs has been hacked, because the integrity of the bulletin will be
   ensured by the consensus agreement of all KAs.  However, at least a
   few non-compromised KAs (functioning as trust anchors) must be
   present and reachable for the system to survive with assured
   integrity.

4.4.  DC4: Availability and Security

   Like all other critical infrastructure elements, the key management
   system must be maintained as highly available and hardened against
   compromise.  The latter requirement may require strong physical
   security, e.g., secured data centers, hardened mobile platforms, etc.
   This is no different than for other core network services such as the
   Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP)
   and many others.  As in all other networking operations, nodes depend
   on at least occasional contact with critical infrastructure.  Where
   fully ad-hoc networks are needed, dynamic key distribution may not be
   feasible.  In that case, permanent Pre-Placed Keys (PPK) and/or
   limited-scope pairwise key exchanges may be the only solution
   alternatives.








Templin & Burleigh       Expires August 29, 2015                [Page 7]

Internet-Draft     DTN Security Key Management Design      February 2015


5.  Candidate DTN Security Key Management Design

   We anticipate a security model for DTN that is based on ephemeral
   secret keys included on a per-bundle basis, i.e., in a similar manner
   as for S/MIME.  That is, the symmetric keys used to secure DTN bundle
   traffic should normally be single-use (ephemeral) keys carried in
   individual bundles rather than persistent session keys.  DTN nodes
   use public/private key pairs to encrypt/decrypt or sign/verify the
   ephemeral keys.  The ephemeral keys are used to decrypt/authenticate
   bundle data efficiently.

   In the design, DTN node public keys are registered with a Key
   Management System (KMS) that serves as the trust anchor for all
   secured DTN transactions.  The KMS is organized as a group of N Key
   Authority (KA) nodes that act in an inter-dependent fashion to
   distribute public keys to all DTN nodes.

   Each DTN node generates its own public/private key pair and registers
   the public key with the KMS.  The KMS in turn issues key assertions
   and revocations in periodic bulletins sent via multicast
   transmissions to all DTN nodes.  The keys are designated for use at
   some time in the future, since delays/disruptions may preclude
   immediate delivery.

   Each KA node in the KMS has all current public key information for
   the DTN, but for each bulletin publication it sends only a subset of
   blocks (or "fragments") of the entire bulletin.  Each bulletin is
   erasure-coded for Forward Error Correction (FEC) in case some
   fragments are lost, corrupted, or deemed untrustworthy.  The
   resulting parity blocks for error detection are also included in the
   publication.  Receivers then reassemble the bulletin from the union
   of fragments and parity blocks received, i.e., even if some fragments
   are lost, and extract time-tagged public keys from the bulletin.

   In subsequent operation, the public key that a node uses to encrypt
   or sign an outbound bundle will be selected based on bundle creation
   time.  The node must ensure that when it creates a bundle it is using
   a key that other nodes have been informed of.  This means that each
   DTN node must cache keys for sufficiently long times to account for
   delays in the path.

   DTN nodes must therefore keep track of all recently-received public
   keys for each potential peer node in the DTN.  A DTN node that
   receives a bundle then uses the newest key that is no younger than
   the bundle creation time to verify or decrypt the ephemeral key
   included with the bundle.





Templin & Burleigh       Expires August 29, 2015                [Page 8]

Internet-Draft     DTN Security Key Management Design      February 2015


   Since multiple keys are retained at each node with different creation
   times, there is no need to synchronize key transmission and
   reception; the receiving node has the appropriate key in place long
   before the bundle arrives.

   Additionally, no information in the key distribution system is kept
   secret - it's all public information.  The point of the KMS is to
   provide a critical infrastructure trust basis so that DTN nodes can
   tell whether a prospective correspondent is authorized to use the
   public key it claims.

   Security is then based on the DTN node's trust relationship with the
   KMS.  As a result, all public keys are distributed securely.  The KMS
   service is automated, with potential human intervention for
   revocation.  No multi-message exchanges over long-delay links are
   needed (i.e., as for services such as the Internet Key Exchange (IKE)
   protocol), since ephemeral keys are used instead of session keys.
   The system also provides no single point of failure or compromise.

6.  Limitations and Challenges

   The candidate KMS design requires a scalable, reliable multicast
   capability.  The DTN Bundle Protocol (BP) reliably delivers bundles
   to one or more recipients based on convergence layer protocols such
   as TCP and LTP.  Reliable delivery in the BP is "hop-by-hop", where
   each hop needs to receive data reliably from the previous hop to
   ensure that end-to-end delivery is reliable.  Scalable reliable
   multicast delivery is also based on hop-by-hop convergence layers,
   but large-scale reliable multicast is an end-to-end consideration
   that is not dealt with well in the Internet and needs to be better
   understood in the DTN context.

   Security of the KMS is a fundamental requirement for service
   integrity.  Just as for core Internet services (e.g., the DNS, DHCP,
   etc.), the KMS must be protected against network-based and physical
   security attacks.  The system design is resilient to one or more
   elements being compromised, but bringing down all nodes essentially
   brings down the DTN.  History has proven that services of this nature
   in the public Internet can be protected against comprehensive
   destruction, but measures must be taken to ensure network and
   physical security.

   Another measure that may be considered in this context is KMS
   confederation.  The KAs of a "local" KMS might forward bulletins to
   the KAs of another KMS as well as to the local node populations they
   serve.  Such a structure would tend to make the KMS not only more
   durable but also more scalable.




Templin & Burleigh       Expires August 29, 2015                [Page 9]

Internet-Draft     DTN Security Key Management Design      February 2015


   Nodes that (re)enter the DTN after a long time away can present a
   challenging bootstrapping situation.  Sometimes DTN nodes can go
   offline for extended periods of time (days/weeks/months), which would
   essentially bring the same consideration as for a new DTN node
   entering service for the first time.  Upon (re)entering the DTN, the
   node has to publish its public key via the KMS.  This "first contact"
   trust establishment is crucial to the security of the entire system,
   i.e., ,there needs to be a way for the new DTN node to trust the KMS,
   and for the KMS to validate the identity of the DTN node.  In effect,
   a trusted entity (a node or a human) must somehow "vouch" for the new
   node.

   DTN KMS services in fixed networks are not a problem, since the DTN
   topology does not change.  On the other hand, Mobile Ad-hoc Networks
   (MANETs) typically show up in Unmanned Aerial Vehicle (UAV) networks,
   tactical military networks, etc.  In that case, portions of the DTN
   may become detached from the rest of the DTN and re-attach at a
   different point of the DTN at a later time.  This is more of a
   routing issue than a KMS issue, but routing aspects (especially in
   MANETs where there is no critical infrastructure) need to be
   understood.

   Scaling considerations in terms of the size of the public key
   database must be analyzed on a per-DTN basis.  For example, it may
   not be necessary for all DTN nodes to receive the public keys of all
   other DTN nodes since only a subset of all public keys may ever be
   needed.  This is the same scaling consideration that motivated the
   design of the public Internet Domain Name System (DNS), when
   maintenance and distribution of a single, central repository at the
   SRI Network Information Center (SRI-NIC) became too unwieldy to
   maintain as the Internet grew exponentially.

7.  IANA Considerations

   There are no IANA considerations for this document.

8.  Security Considerations

   This document is entirely about security aspects of key management as
   a crucial component of DTN security; hence, security considerations
   appear throughout the document.

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







Templin & Burleigh       Expires August 29, 2015               [Page 10]

Internet-Draft     DTN Security Key Management Design      February 2015


9.  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.  The candidate design discussed here is based on the
   original ideas of Scott Burleigh from NASA/JPL.  Kapaleeswaran
   Viswanathan provided valuable review input.

10.  References

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

10.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-01 (work in
              progress), May 2014.

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



Templin & Burleigh       Expires August 29, 2015               [Page 11]

Internet-Draft     DTN Security Key Management Design      February 2015


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

Authors' Addresses

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

   Email: fltemplin@acm.org


   Scott Burleigh
   JPL, Calif. Inst. Of Technology
   4800 Oak Grove Dr.
   Pasadena, CA  91109-8099
   USA

   Phone: +1 818 393 3353
   Email: Scott.Burleigh@jpl.nasa.gov


















Templin & Burleigh       Expires August 29, 2015               [Page 12]